And I'm not going to have an answer on that Do you thinks that what I wrote could work ?

Pretty sure that's just log spam because the sysctl is set after radvd starts. Is everything working and it's just something you noticed?

Yep… time to give this some testing when I get home tonight!!

You can change it in /etc/inc/services.inc Ugly fix but it works. See my other threads about this…

How exactly do you have the router advertisements tab setup on pfSense? For the lines you show in rc.conf, it would attempt to configure itself via SLAAC, which would only be active in Assisted or Unmanaged modes on the RA tab. For FreeBSD to use DHCPv6 it requires some extra config depending on the DHCPv6 client in use.

@razzfazz: OK, so what does your routing table look like afterwards? Edit: Never mind, looks like it's not treated as a local segment: Destination                      Gateway                      Flags      Netif Expire 2601:x:y:a::/64              link#2                        U          igb0 <--- local segment for this interfaces 2601:x:y:b::/64              bc:5f:f4:xx:yy:zz            US        igb0 <--- manually added route Are you sure the :2c: prefix your provider gives you is intended for the WAN side, not the LAN side? I.e., you can't just use an address from the :1: prefix on the WAN interface? Using a non-local gateway seems like a very non-standard (and arguably broken) configuration. Is this what your provider tells everyone to use, or is this something specific to your particular setup? This is an OVH & Hetzner type setup, ie. "standard" for all. I'm also hitting this same problem, and an issue to use IPv6 with pfSense… else I'll have to consider the HE tunnel mechanism ;(

@awebster: With CARP, you will need additional rules to make this work. Typically, create an alias which contains VIP+WAN IP for each firewall, then use that alias in firewall rules, for example to allow ping. Something like this… I am happy to say that the issue is now fixed! It turns out the main problem was with ISP. They have assigned wrong /48 to the routing. As soon as they gave me the correct block IPv6 came to life in the network behind pfsense. Thanks to you awebster i was able to pin point the issue and confront my ISP by running traceroute and ping from outside through an online website. I tried everything from inside and did not even think of testing it from outside. Also thanks to the pointer about alias of VIP+WAN IP for rules. That actually solved the Ping issue from outside into client node.

Track Interface does the following… Sets RA type to Assisted Enables DHCPv6 with an address range of ::1000 to ::2000 The assisted RA type means that a device will use SLAAC if it is able to use it. Nearly all IPv6 devices use SLAAC, but some may not be able to, or might be configured to specifically use DHCPv6. For devices that only support DHCPv6 or are configured to only use DHCPv6, they will get an address from the DHCPv6 server within the address range. It has been said that in pfSense 2.3, interfaces that use the Track Interface setting will be allowed to customize RA and DHCPv6 settings. That capability is not yet present in the beta version, though. There is no doubt that there are some tricky circumstances surrounding the ability to allow that, especially with a prefix that can change at a moment's notice from your ISP.

@johnpoz: you shouldn't be getting a /128 on your pi…  The smallest prefix with ipv6 is /64..  And its not just linux that works that way its every OS there is that can work with IPv6.. anything other /64 is going to break all kinds of shit from working correctly.. I dusted off my raspberry pi over the weekend, and installed latest NOOBS + raspbian, sure enough it comes up with /128 in addition to /64. The /128 is the address assigned by the DHCP server; the /64, I guess it is deciding thru SLAAC on its own because of RA.  I have some android clients on the network, so need SLAAC too. radvd on pfsense 2.2.4 is set to Assisted, with the RA Subnet set to WWWW:XXXX:YYYY:ZZZZ::/64 Win2K8 DHCP server is handing out IPs in WWWW:XXXX:YYYY:ZZZZ::/64 Resolv.conf on PI ends up with Domain Controller IPv4+IPv6 IP as well as pfSense IPv6 IP, not ideal since it doesn't have any knowledge of the domain.  Strange that it ended up with the pfSense IPv6 IP because the DNS Servers entry is blank in the RA config tab. eth0      Link encap:Ethernet  HWaddr b8:27:eb:35:53:31            inet addr:10.2.95.18  Bcast:10.2.95.255  Mask:255.255.254.0           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:fcef:f7d6:12c3:f393/64 Scope:Global           inet6 addr: fe80::bd6c:2ed5:a452:1eff/64 Scope:Link           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:c439:ca13:15f5:31a9/128 Scope:Global           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:80378 errors:0 dropped:5856 overruns:0 frame:0           TX packets:4106 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:6121679 (5.8 MiB)  TX bytes:662612 (647.0 KiB) wlan0    Link encap:Ethernet  HWaddr 34:08:04:a0:5d:3d            inet addr:10.2.95.20  Bcast:10.2.95.255  Mask:255.255.254.0           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:927a:28a4:a3e3:73f8/128 Scope:Global           inet6 addr: fe80::b69e:3850:a1d0:6935/64 Scope:Link           inet6 addr: WWWW:XXXX:YYYY:ZZZZ:d9d4:1377:f075:8c05/64 Scope:Global           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:315611 errors:0 dropped:17236 overruns:0 frame:0           TX packets:325 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:121355585 (115.7 MiB)  TX bytes:63491 (62.0 KiB)

@Vetal: So, on VPS, VPN tunnel (tun mode) is VPS end: prefix_64:8000::1/64 pfSense end: prefix_64:8000::2/64 LAN: prefix_64:8000::1001/116 DHCPv6, Router Advertisements - Managed So far, so good, everything is pingable within VPS <=> pfSense world. … ... I am testing similar setup, trying to follow https://community.openvpn.net/openvpn/wiki/IPv6 - the only sample I found so far. gateway is getting IPv6, I can ping VPS eth0 but not outside. From prefix_64:8000::1 icmp_seq=1 Destination unreachable: Administratively prohibited. net.ipv6.conf.all.forwarding is enabled. Would you mind sharing your openvpn config files?

I am told this the way IPv6 can legitimately operate. there is no problem setting up route manually in Linux on the same network: https://clients.inceptionhosting.com/knowledgebase.php?action=displayarticle&id=8 The FreeBSD variant of Linux ip commnds route add -inet6 -net prefix_48::/48 -interface vtnet0 route add -inet6 -prefixlen 0 default prefix_48::1 produces virtually the same routing table as DHCP6 (probably via routing advertisement) created one but there is no IPv6 connectivity. Update: on Little Happy Cloud CentOS 6 static IPv6 configuration looks like: cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=nnn.nnn.nnn.XXX GATEWAY=nnn.nnn.nnn.1 NETMASK=255.255.255.0 IPV6INIT=yes IPV6_AUTOCONF=no IPV6_DEFAULTGW=prefix_48::1 IPV6ADDR=prefix_48:XXXX::X/64 Could anyone explain how to configure pfSense to achieve the same configuration?

Just curious, what hardware are you running comcast connected pfsense on?

While it is possible for IPv6 to talk to IPv4 (in theory) using special addresses, the reverse isn't true. You'd need a full proxy to take the requests from the IPv4 host and then issue new IPv6 requests out from the proxy itself.

Hi! Ive updated [https://redmine.pfsense.org/issues/4470](https://redmine.pfsense.org/issues/4470) after Iv seen progress with one option now available in GUI. Is there any takers, this would be huge step up to RA configurability. I would do it myself, really, but my coding skills are ermmmm well I have almost none :)

@jimp: Time to call the ISP and hope you reach someone with IPv6 experience… argll They are good but not that good… in fact not good but nice. Thanks a lot for yours lights, I'm quite relief, it's not my fault. :D I keep you inform. Librement, ryoanji

Not really. With IPv6 it's quite a bit different and geared toward privacy. You might get lucky and spot the host by its MAC address in the NDP table or catch it in the DHCPv6 leases if it didn't use SLAAC. Otherwise you have to check the client.

@David_W: Android does not support DHCPv6 and, despite many requests, the engineer responsible for this issue at Google seems implacably opposed to adding DHCPv6 support. You need to use SLAAC. If someone really needs DHCPV6 on android there is a nice client aviable on google play https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client It works fine on my Z1 compact (5.01 lolipop). Root required of course.