Sucess :) In the event someone else comes across this here is what I did :) Assign an IPv6 address to your pfSense WAN. For me, I added an IP address to the virtual interface on my Router. Make sure you can ping an ipv6 address from the WAN interface using Diagnostics > Ping. interface ve 10 ip address 155.x.x.1 255.255.255.240 ipv6 address 2607:x:x:8200::1/64 ipv6 enable Create a static route on your router to you pfSense WAN IP. ipv6 route 2607:x:x:8201::/64 2607:x:x:8200::2 Assign the gateway IP to your pfSense LAN without a gateway. You should now be able to ping an ipv6 address from your LAN interface using Diagnostics > Ping. Setup DHCPv6 (if you are using it) and RA. Set any firewall rules that are needed for the outside world to communicate with your LAN side server You should be able to speak to the internet and back to your LAN side server :)

@hda: (Your ISP-box must delegate-on-request with use of its DHCP6-server, to pfSense) Not if they're static. They actually seem to be part of some bigger net block anyway. Just need to add a static route to send it to the other device in that case.

Don't manually modify anything. Either disable logging of default block rules, which will disable that logging, or uncheck "Allow IPv6" so your floating rule can match and block without logging.

Or just use the resolver. It's not that I need 256 /64s here at the house but I can easily see myself needing more than 16. The whole point of IPv6 is to never worry about it again. There are enough /56 networks to give every person on earth 10.1 million of them (in general, not counting reserved space etc (2^56 / population of earth @ wolframalpha)). It's a non-issue. Just get a /56.

THX! The Problem was an impropper configuration of the IPV6-LAN-Interface. I just forgot to set an vIP and different IP's for the two pfSense. So both of the DHCP gave their very best to provide even more adresses that the other one. As I fixed that the battle stopped and now this is working fine

I'm bridging because the way my house is set up I have APs in different spots around the house, I need seamless transition from one AP to the next and if you change network ports I change networks.  A bridge lets it be one flat network between the three 802.11ac points so as devices transition as they move throughout the house network connectivity doesn't go goofy. VPN clients will disconnect, etc if I change underlying networks. This is the way I've done it since early 1999 or so, and if it wasn't broke not in a hurry to fix it but Is there another method besides bridging that will allow me to continue a flat network on each port?  Based on my knowledge I have to create four subnets and have four different DHCP ranges and this causes issues.  I'd prefer to have a single device that does both my network switching & internet firewall/routing. I'd prefer not to step it down to a single LAN as my connectivity via wifi sucks without distributed hot spots, and also to be honest what I'm doing was handled just fine by my lower performance router i replaced because of my update to faster internet.  It's not that I'm having trouble distributing the IPV6, I'm not getting one and DHCLIENT6 is not running.  It'd be one thing to me if I was getting an IPV6 on my WAN port, but I'm not even getting that.  If I do get that, my IPV4 stack crashes and requires a reboot to recover.    The WAN port isn't bridged in anyway, its' off by itself. My Network Diagram of the physical layer. [image: b89hWe3.png] Based on everything I've read about the way TWC works for IPV6 is they give you a /64, so that's what I was going with. Screen shots of my extremely basic configuration (checkboxes checked) is here http://imgur.com/a/EyljQ

@hda: Hi David, great to read from you again :) <github.com pfsense="" commit="" ec0643f7f1537ab6a18ed05fc015ecba598fcffc="">does yield, but from head on: From 682d280755ee7bd2140dca84b5ee21659a4ae580 Mon Sep 17 00:00:00 2001 From: David Wood <david@xxxx.org.uk>Date: Thu, 24 Dec 2015 05:50:16 +0000 Subject: [PATCH 1/8] Make ppp-ipv6 the only way interface_dhcpv6_configure() is called on PPP interfaces ... snipped</david@xxxx.org.uk> And following code content is very different from your last patch (4th)  ;)</github.com> For some reason, System Patches chooses to use the .patch GitHub URL, which gives all the history including the many code snippets I later reversed. If it used the .diff GitHub URL, that produces a flat patch with no history, which is really what you want. In this case, I suggest using https://github.com/pfsense/pfsense/commit/ec0643f7f1537ab6a18ed05fc015ecba598fcffc.diff as the URL.

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.