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

That /48 is 65536 /64s.  You normally configure the router to use one of those for each LAN or VLAN.  This is done in pfSense on the LAN tab in IPv6 Prefix ID.  Normally, it's 0, for a single LAN, but you'd choose another for other LANs/VLANs.  One deficiency I've noticed with pfSense is that it only accepts values between 0 & ff, which will only cover a /56 block for 256 networks.  So, most of that /48 will be wasted, unless you use a different router that properly supports a /48.  Of course, I don't think most users will have more than 256 LANs/VLANs.  ;)

Prefix ID's are assigned and all internal VLAN interfaces have and address with their assigned prefixes.

Thanks for all replies! I contacted my service provider and they suggested a workaround that actually worked  :) The /64 network that they provide apparently has some issues and they suggested to ditch it and just get /128 address from the dynamic pool. After that reconfiguration I do not receive RA from them any longer and the rest of configuration worked like a champ.

Thanks again for your input.

So I'll want to use this for a few days to confirm, but ..
It appears that manually setting the DNS servers in the RDNSS settings fixes this.
Entering Google's DNS -> works
Entering one Google and the pfSense's IPv6 LAN address -> works
Leaving it blank -> broke
Entering only pfSense's IPv6 LAN address -> broke

Troubleshooting suggestions welcome ..

@workingman:

Quick question for you though.  Have you modified the interfaces.inc like https://forum.pfsense.org/index.php?topic=64175.0 or did it just work?

I did with no modifications. Just enabled all from the gui.