My clients stopped getting IPV6 when I replaced the router. I restored the previous config so everything should be the same but the clients do not get an address. They did prior. WAN and LAN have IPV6 and I can ping IPV6 addresses from within pfSense but obviously not from a client.

@thehammer86: Ok.  I figured I might have to create some rules and static routes.  Just wondering why I couldn't select a different gateway for one particular interface. That's not the way routers work.  You have traffic coming in via the various interfaces and the rules determine where it goes.

One other thing I've noticed is that the default route entries get reversed: Before reboot: $ ip -6 route 2607:fea8:abcd:ef00::/64 dev eth0  proto kernel  metric 256  expires 86385sec pref medium fd48:1a37:2160::/64 dev eth0  proto kernel  metric 256  expires 86385sec pref medium fd48:1a37:2160:3::/64 dev vlan3  proto kernel  metric 256  expires 86391sec pref medium fe80::/64 dev eth0  proto kernel  metric 256  pref medium fe80::/64 dev vlan3  proto kernel  metric 256  pref medium default via fe80::1:1 dev eth0  proto ra  metric 1024  expires 45sec hoplimit 64 pref medium default via fe80::216:17ff:fea7:f2d3 dev vlan3  proto ra  metric 1024  expires 51sec hoplimit 64 pref medium After: $ ip -6 route 2607:fea8:abcd:ef00::/64 dev eth0  proto kernel  metric 256  expires 86387sec pref medium fd48:1a37:2160::/64 dev eth0  proto kernel  metric 256  expires 86387sec pref medium fd48:1a37:2160:3::/64 dev vlan3  proto kernel  metric 256  expires 86387sec pref medium fe80::/64 dev eth0  proto kernel  metric 256  pref medium fe80::/64 dev vlan3  proto kernel  metric 256  pref medium default via fe80::216:17ff:fea7:f2d3 dev vlan3  proto ra  metric 1024  expires 47sec hoplimit 64 pref medium default via fe80::1:1 dev eth0  proto ra  metric 1024  expires 47sec hoplimit 64 pref medium

That works…  About time.  Got a little tired of seeing my IPV4 address getting passed instead of the IPV6 address. So now that that is solved and working, anyone want to talk about what idiots the ISPs are for not just assigning static /48s on the WAN?  Or anything static... I feel like this is a case of the ISPs working really hard to invent a problem so they can charge to solve it.

And boom goes the dynamite. Thanks man! It turns out Suricata was blocking some part of the communication. Basically the UDPv6 Checksum rule started hitting for whatever reason. I've disabled the rule entirely and all is good. Again, thank you for your time and effort.

Take a look at your dhcpc6 log file. When I used a bridge interface with ipv6 there were issues that caused my local clients to lose access on ipv6 and my log file showed the client failing to recognize the bridge interface I would recommend not using a bridge. These are old bugs that aren't getting worked on.

Thanks for the help.  I've disabled IPV6 on the second WAN and things are running smoothly now.  ATT has some work to do on their side and pfSense doesn't support two DHCP6, so there is no point trying to wrestle with it.

I have IPV6 working with Comcast Business in pfSense. Try setting DHCPv6 Prefix Delegation size = /56. My recollection is that I couldn't get it to work until I set that value. I got that from a post on how to configure pfSense for Comcast Business, but can't remember where I saw it. I don't think it was here. Also, I don't have use IPV4 connectivity as parent interface checked, but I'm not sure that makes any difference.

D'oh! I bet you're right. My stupid mistake!

I'm using assisted. The strange thing is that other iphones that connect do not seem to have this issue, only mine.

@marjohn56: Under system->advanced->networking, save the DUID. In WAN dhcp6c settings, select do not allow release. Those are the only things that can be done, they were added to help with the same issue you are having for Sky users, but they apply to any ISP using dhcp6 for IPv6. You will never completely secure the IPv6 address/prefix but those two do make a big difference, failing that you'd need to use an ISP such as Zen, where they do give statics. By the way, they were added in 2.4, i did not back port them so if you don't see them, you'd need to update to 2.4. Very helpful, thanks!

@doktornotor: Seeing that code snippet, I'd hazard to say if that config box vanished from the GUI, noone would notice in next 50 years. Yeah quite a few cobwebs have been spun over the last 13 years. A fun thing I like to do is run the following command in the /src directory find . \( -name "*.inc" -o -name "*.php" \) | xargs grep -En "(XXX|TODO|FIXME)" Some real gems in there…  :P

@pox: Thank you both. I don't like that the ubiquiti don't have a web interface, and that I have to download a management software. I bought a D-Link DAP-2610. Just for the record: with the D-Link AP everything works as expected. Never again TP-Link.

Thanks. I have my network setup to use the native IPV6 address from my ISP. The WAN interface IPV6 is set to DHCP6 and the LAN interface IPV6 is set to Track Interface (WAN). I got that from an article on how to configure pfSense to use Comcast native IPV6. Everything seems to work the same as when I had the Comcast modem doing the routing. Only problem is the iOS devices. If I understand correctly, your method has pfSense doing the IPV6 assignment and you defined static IPV6 addresses for all the devices. Right? If I were to go down that road, what would I use for an IPV6 prefix? Something I make up? Something based on the Comcast native IPV6 prefix?

You would do it exactly like you do with IPv4, but using IPv6. In IPv6 you generally will have a routed prefix. You would use that instead of RFC1918. Example: You are routed this prefix: 2001:db8:4b56::/48 You assign: VLAN100: 2001:db8:4b56:64::/64 VLAN101: 2001:db8:4b56:65::/64 VLAN102: 2001:db8:4b56:66::/64 VLAN103: 2001:db8:4b56:67::/64 On VLAN 100-103 you would: Pass anything to any local assets they need, like DNS servers Reject anything to This Firewall Reject anything to 2001:db8:4b56::/48 (and possibly more if you are using any ULA addresses locally, etc.) Pass anything to any It can be beneficial to use an alias for the block destination. You could add 2001:db8:4b56::/48, fc00::/7, etc to it. Yes, there is added responsibility to identify local addresses that need protection without the perceived convenience of just blocking RFC1918. But this responsibility is no different than having routed, public subnets in IPv4. If you are careful in your planning, such as setting all VLANs to use the same DNS server addresses, you might even be able to get away with defining an interface group and using one set of rules for them all.

I'm somewhat surprised that the pfsense routers supplied by netgate don't use the enterprise format. Because dhcp6c does not support it.

@pmisch: @masterzen: … (this is something I find strange, I thought there would have been an interconnexion network outside of our /48) On the WAN side of the PFSense router, I have setup 2001:XXXX:YYYY::2/48. I added an IPv6 gateway to 2001:XXXX:YYYY::1. From the pfsense shell I can ping: the CPE LAN (2001:XXXX:YYYY::1) the CPE WAN ( 2001:XXXX:ZZZZ::371/126) but I can't ping the other side of their point-to-point net (nor access any IPv6 site). From an exterior IPv6 host, I can ping everything except our pfsense WAN, note: when capturing the traffic on the WAN I don't see anything coming in). They assured me that from their CPE they can ping anywhere including our pfsense WAN. Our WAN firewall allows ICMPv6 (echo rep, echo req, router adv, router sol, neighbor sol, neighbor adv). We double-checked our config and their CPE config of the LAN side. I'm out of clue about what I have done wrong in the config, my gut feeling is that there is something wrong in their CPE configuration, but it's hard to tell from outside. Any idea of what can be wrong and how we can further troubleshoot ? Thanks! Masterzen. First 2001:XXXX:ZZZZ::371/126 is outside of 2001:XXXX:YYYY::/48. I don't understand your confusion. My confusion is that they put our attributed /48 on the CPE LAN. I thought that for proper interconnection you had to do either a point-to-point network (ie a dedicated /126 or /64 outside of the /48) or use a /64 from the attributed /48. The 2001:XXXX:ZZZZ::370/126 address is their interconnection between their upstream routers and their CPE, not our pfsense and their CPE. @pmisch: Secondly: from your description the error seems to lie outside of your realm. I'm quite sure that your provider's setup is faulty. Yes, I'm quite positive it's not our setup, but they seem to think otherwise… I have asked them to capture packets at different points on the CPE to see where packets are dropped but they don't seem to want to do it :(