PfSense box has IPv6 connectivity, clients can't get to internet for IPv6 connectivity (using a tunnel broker)

[Eelt]

Background
I recently switched ISPs from a Cable company that had IPv6 to a FTTH ISP that is IPv4 only. While not really necessary, I thought it’d still be nice to have IPv6 connectivity over a tunnel broker. I’m using Route48 since I couldn’t register for Hurricane Electric without getting a 500 after filling in all the account details, and Route48 seems to work… to the pfSense box.

Issue
The issue I’m having is that clients are unable to reach the open IPv6 internet. Traceroutes show they’re indeed hitting the pfSense box, (I’m using Stateless DHCP on pfSense with main DHCPv6 server off) they appear to be learning correctly the addressing and the default gateway.

Details
Route48 has given me a /48 of 2a06:a004:/48, my intention is to use the last for hex digits of the MAC address of my router/default gateway for each subnet. So 2a06:a004::bea0/64 is supposed to be the subnet for my homelab, and if I can get this working 2a06:a004:****:bea8/64 will be for the main home network.

This appears to be correctly configured so far:

The WireGuard tunnel and Gateway are online, and appear to be working in pfSense:

The “WAN6” interface, is using the tunnel, and is configured as what Route48 recommends, with their GW ending in ::1 and using :0000: for the /64:

The regular WAN interface has IPv6 disabled (only IPv4).

Next up, I made the Firewall rules pretty wide to allow the IPv6 traffic to pass through. I also had my host ping CloudFlare’s IPv6 DNS (2606:4700:4700::1111) while taking the FW rule screenshots.

WireGuard FW rules:

WAN6 FW Rules:

LAN FW Rules:

To prove that the pfSense box has IPv6 connectivity, I’ve done some tests. Note that I’m using the LAN interface, which means that the addressing should be the same as what clients see in the LAN network, and not the address of my WG tunnel endpoint.

Traceroute:

Ping:

Also: SSHing into pfSense and doing a dig with CloudFlare’s IPv6 DNS address works fine:

On the client we can see that addressing seems fine:

Routing also seems fine (link-local of router should be fine?) However, Pings and traceroutes to CloudFlare’s IPv6 DNS fail. Traceroute does show we’re able to hit the default gateway though:

So my question here is, what did I do wrong? Everything seems fine to me, FW shouldn’t be blocking IPv6 traffic? Seems like there’s some sort of issue with pfSense forwarding IPv6 traffic from clients on the LAN interface to the WAN6 WireGuard tunnel interface? pfSense seems to have full IPv6 connectivity, even when using the addressing from the LAN interface it seems… So I’m at a bit of a loss on this one. Hopefully someone here can spot what I’ve done wrong.

[Eelt]

Okay, I think I found the root cause of the issue now, and I shouldn’t be surprised considering that there’s a tunnel at play: It’s MTU.

I tried pinging using MTU discovery and setting the size to ping to CloudFlare’s IPv6 DNS.

$ ping -s 1500 -M do -6 2606:4700:4700::1111 -c 1
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1500 data bytes
ping: local error: message too long, mtu: 1500
^C
--- 2606:4700:4700::1111 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

1500, going through the WireGuard tunnel, is obviously too big. Without any configuration tweaks, dropping the size of the ping down to 1452 I did manage to get it working. 1452 is the largest MTU that I can get with the pings going through the WG tunnel properly!

$ ping -s 1452 -M do -6 2606:4700:4700::1111 -c 1
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1460 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=58 time=11.7 ms
^C
--- 2606:4700:4700::1111 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 11.708/11.708/11.708/0.000 ms

I’m not sure how pfSense doesn’t have a problem communicating through the tunnel since I didn’t recall configuring MTU anywhere, but I now have to figure out how to get the clients to know that IPv6 traffic has to cap out at 1452 instead of 1500.

[Novasty]

1452 is the standard MTU size for PPPoE.

[Eelt]

Yes, my ISP uses PPPoE. My confusion comes from what MTUs/MSS on what interfaces should be set to get my IPv6 traffic working properly on network clients, considering that my ISP is using PPPoE, plus I’m using tunnelling IPv6 traffic inside an IPv4 WireGuard session.