This is a known issue with radvd.  The bug is fixed in the next release of pfSense (2.4.2).  It only happens on ARM hardware like the SG-3100.  Here is the bug report and documentation of the upcoming fix from the pfSense Redmine bug site:  https://redmine.pfsense.org/issues/8022#change-35066.

Bill

@virgiliomi:

@marjohn56:

You might be able to get away with trying managed only on dhcpv6, set up a static assignment for his device, then add a firewall rule to block that address from the internet…

Worth a try...

This is probably the best solution… and should work as long as the prefix from your ISP doesn't change.

One slight issue, pretty sure some or all Android devices won't play though as they rely on on SLAC, but that's not a showstopper, they will still run on v4.

I have multi-WAN and HE.net tunnels on 2.4 here and it all works fine.

Perhaps you missed a step, such as assigning/enabling the GIF interface?

Like I said its bad design to not use a transit.

Perhaps I used the wrong expression.  I took your description as requiring public IPv6 addresses on the WAN side of the firewall.  I do have one that's completely different from what my /56 contains.  However, that public address is not used in routing my /56 to me.  It also has a /128 prefix.  Netstat -r shows a link local address that's not on my firewall for the default route.  With IPv6, routing is normally done using the link local address, so not having a public IPv6 address on my WAN interface would not break anything.  All that IPv6 address does is allow connection to my firewall from elsewhere.  This contrasts with IPv4, where a routed IP address is necessary, except with point to point links.

Thank you.

@Derelict:

No idea. NATs are bad.

Yeah, I know.  But when you're using someone else's network, you have no choice.

Hi,

Yes, I did. It was even the one that made me access via ssh in pfsense and look at the squid conf and process.
From what I saw in sockstat -6l squid is not even listening on ipv6. Maybe it has not even been compiled for IPv6 support. In the squid conf the listen is also only in IPv4.

The squid in transparent mode is not redirecting the IPv6 traffic to it. From what I realized only IPv4 traffic is working.

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!