Thanks. Right my bad. I'm so used to IPV4 :\ Ok I'll try a any any rule. but how do you test that to see if it works.

There is an issue with the leases being displayed as well: https://redmine.pfsense.org/issues/7413

Hey, thanks for your replies, I'm solving another priority right know, so I'll take a little more time to try it again! Pretty soon I'll be back here!!! Thanks

@bimmerdriver: It could also be that your ISP only gives /56 prefix, regardless of what you request. It obviously does. As I said I got DIFFERENT PDs each try, but they all were /56. At least now I know what caused the issue.

Good stuff.

I suspected CP early on and unchecked the "Enable Captive Portal" box in the config, clicked save, it didn't fix it. Rebooted, still didn't fix… it wasn't until much later that I realized that the checkbox doesn't seem to do anything. Once I clicked save and left the page assuming it accepted the setting, coming back to that page showed it was checked as enabled again. I tried a few times to just disable it and every time the box was left checked. Finally I just deleted the captive portal and everything IPv6 lit up as expected.

me too.  NPT not nornal work now.. 2.3.3-RELEASE-p1 (amd64) built on Thu Mar 09 07:17:41 CST 2017 FreeBSD 10.3-RELEASE-p17

Unless you want to test how devices behave (better said, how much broken they are) on an IPv6-only network, then no, absolutely NOT.

My original issue is resolved.  But if you really wanted to know: WAN: DHCPv4 and DHCPv6 client LAN: Static IPv4, Tracking WAN IPv6 You've seen the DHCPv6 configuration in the screenshots above (I changed the From to :0001).

@mbouchonnet: Hello, Actually, I restarted the computer, tried in "rescue mode" (the computer boot with a live cd ubuntu), managed to get ipv6 running and it worked. And when I restarted pfsense it worked too (i tried 2 or 3 times before to restart pfsense) so i suspect there was something weird witch the block that the rescue mode repaired. Hi! I am trying it as well, but my pfSense only gets a /128 as stated in the console. What did you do in rescue mode? I want to do it as quick as possible to have a low downtime… Regards

I think the OP's problem is the same as reported here: https://forum.pfsense.org/index.php?topic=126828.0 If so and it is 2.4 the OP is using, then it's fixed and a snapshot update will solve his issues.

@marjohn56: Good. Would you like to roll back the patches and apply the consolidated pair and see if it's OK. I can then comment on that PR that at least one person has tested it and it's OK. 2.4.0-BETA (amd64) built on Wed Mar 15 18:17:17 CDT 2017 FreeBSD 11.0-RELEASE-p8 Redmine #7330 / PR #3515. Tested 5 sec. unplug then insert of WAN side. Result OK. Thanks again.

Well, the first thing I tried is to change the MTU size of the bridge. Which seems not possible. So I digged into radvd to do it manually. Because PATH mtu is used with ICMP the problem arises. The IPv6 client tells the webserver: My MTU is 1500 (received from radvd). So the Webserver tries to sent packages with MTU size 1500. Which is a problem because the PPPoe(WAN) interface is only 1492. After I changed radvd to tell the IPv6 clients to use MTU 1492, alle websites are reachable again.

The default route should be dropped immediately on WAN flap That's what my test showed, when the router life time dropped to 0.  Perhaps someone can try a similar test with 2.4.

If you only have IPv6 or want to use fe80::1:1, You could also ssh to the link-local address and use an ssh forward and load up localhost:443