"Presumably, i need to set up routing on each interface to the gateway for the tunnel?" No.. Why would you think that?  Your just attaching a network to pfsense, just like a ipv4 network..  Pfsense will be the gateway to the clients on that network. Pfsense knows what its default gateway is for wan, and it knows what it is for ipv6 via your tunnel you setup - you would not setup a gateway on an interface unless it was a wan connection.

Normally the other router would announce itself. If it's possible to use it from that subnet it must already be there.

@bigtfromaz: It's a shame that Cox, with billions of subnets at their disposal, won't supply a static one to the account.  HE is doing it for free. Cox is a typical ISP. HE is not a typical ISP. If HE offered residential internet service, I would pay more for it.

Phew… After a long battle with the DC... I obtained a second /64 routed and carried over the existing WAN address. I assigned it to the LAN and to devices. All is good! Thanks!!

@thehammer86: Just looking for clarification on the optimical MTU for the HE 6in4 tunnel interface in pfSense.  I have a DSL connection so I would think that I would need to drop the MTU at the HE side config from 1480 to 1472.  Would I also set the HENETv6 interface in pfSense to 1472 as well? If your IPv4 MTU is 1492, then your 6in4 is 1472, You can set it on the interface in pfSense and then also set it on https://tunnelbroker.net/ under the advanced tab of the affected tunnel.

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.