This sounds like Redmine #5297.

I've developed a fix, which is in recent 2.2.5-DEVELOPMENT snapshots. If this solves the problem, please comment on the bug to reference this thread and say your problem is fixed.

Get /48 from HE and move on. The idea of splitting /64 is completely broken.

@modem.over:

Its not in 2.3-ALPHA  yet.  Will keep an eye out.

I think the big push on 2.3 right now is the web UI more than anything… I would imagine it will come sometime after that's all taken care of.

@awebster:

Sounds like there is another device on your LAN segment that is wanting to be a router.

Indeed. radvd is telling SharkBit that another device is advertising a DNSSL local domain and O bit that are different to those being advertised by pfSense.

If pfSense is the gateway, the announcements from the other device (whatever has the link local address of fe80::feb5:8fc9) should be disabled.

upon further testing, this is unrelated to ipv6.  It looks like it has to do with stable table tracking.

Well, enjoy breaking your IPv6 by blocking ICMP. Not really sure what to say.l

Ok turns out this is an actual bug!

https://redmine.pfsense.org/issues/5258

If you suffer from this, System -> Advanced > Firewall/NAT and Disable reply-to rules (tick the box).
Not sure what multi WAN ipv6 users can do to fix it.

I'm less convinced that the problem is on the comcast configuratoin part if anymore.
I noticed from the firewall logs that most of my ipv6 traffic is simply being blocked when this occurs, and if i attempt to reload the filter rules a handful of times, it eventually starts working.

I did run into a problem with there appeared to be some race condition where my ipv6 rules wren't being applied so maybe it's related to that.

I'm getting centurylink fiber pulled next tuesday, and they use 6rd, so I'm not going to bother digging into the current problem and see what happens when the centurylink connection is up.

May be @ hutnik. However, thanks!

I will add a little followup to this.

After some experimentation, I've determined that the DHCP leases file in /var/dhcpd/var/db has to be manually edited or deleted if you decide to make the prefix delegation mask shorter at any point, for instance if you go from a /64 prefix delegation size to a /60.

This is because the leases file contains previously allocated leases, and despite the fact that the client is asking for shorter mask (/60 for instance), continues to hand out the same subnet (/64) as it had previously.

Thanks,
–Andrew

So this is where your doing it?  See pic

On your CLIENT do an ipconfig /all.. what does it show for dns for the openvpn connection?

So for example I connect to one of my vps running openvpn..  Now can you do a query via vpn, do a traceroute do you go down the tunnel to get to the dns you provided?

vpndns.png
vpndns.png_thumb
dnsonvpnclient.png
dnsonvpnclient.png_thumb
dnsqueryandtrace.png
dnsqueryandtrace.png_thumb

Ok, little follow-up.

It looks like it's not possible (at all) to actually specify which address is advertised in a RA. I assume the host directly uses the source address of the RA

To speed up failover, one can hack the pfSense code which generates the actual radvd config and set MinRtrAdvInterval 3, MaxRtrAdvInterval 5 and, for the ::/0 route add AdvRouteLifetime 5. This reduces failover time to around 10 seconds - but I'm not sure if it is generally a good idea to mess with these values.

The fastest option (in terms of failover) seems to be actually not to use SLAAC in the first place, but to manually configure IPv6 on each host - to be able to specify the desired CARP IP as default gateway…

Does this make sense?

PS: Oh, just found this read: https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/

Yes, I already worked around the multiple P2 issue with a config edit and both come up successfully.

Tomorrow I'm going to try setting the network on the ASA side of the IPv6 P2 to ::/0 instead of the LAN address…

Doesn't revert anywhere here, as already noted. And no need to be clicking Save either.

Indeed it is. It comes enabled by default these days I thought. I never had to turn it on.

You can't use overlapping prefixes on the WAN and LAN side of your pfSense box ([PREFIX]:a300::/64 is a subset of [PREFIX]:a300::/56).

I am running ipv6 on 2.2.4 without any issues.  But I use a tunnel from Hurricane Electric, FREE, STABLE, FAST - WORKS!! Easy to setup and you get a /48 from them.  If you ask me most of the isp are not quite ready for ipv6..

This way doesn't matter!

And you can even setup PTR for your ipv6 addresses..  Does your isp let you do that ;)