[Solved] No traffic after handshake with IPv6 Wireguard

[sammyrose]

I'm preparing to migrate much of my network from IPv4 to IPv6 since CGNAT is coming to my uplink. As part of this, I'm attempting to migrate my Wireguard service to IPv6.

My provider gives me a /48 prefix currently, and these will change periodically. So far I've configured opnsense for this, and it's working well. Using assisted routing, DHCP and SLAAC are working well with prefixed GAs and will be tolerant of changing prefixes.

For Wireguard, I've attempted to set this up with a LA so that I don't have to go changing configs every time my GA prefix changes. I've assigned a random /64 LA to the Wireguard interface instance, and configured the peers within this network. I've then added firewall rules to allow the incoming connection.

The server configuration is configured for tunnel fd2d:aaaa:bbbb:cccc::1/64 on the appropriate port.

The peer configuration looks like this:

Code: [Select]

[Interface]
Address = fd2d:aaaa:bbbb:cccc::10/128
PrivateKey = public_key
DNS = fd2d:aaaa:bbbb:cccc::1

[Peer]
PublicKey = public_key
Endpoint = my.domain.name:51280
AllowedIPs = ::/0
On bringing up this on the client, the handshake is successful via IPv6, and I can see the handshake in the opnsense GUI.

After that, I get no application traffic flow despite observing the UDP packets traversing in both directions on each side of the connection via tcpdump.

For example, when attempting a simple ping, I observe packets leaving the source and arriving on destination without any echo response being sent. This happens regardless of which side I'm sending the echo requests. It almost seems like the packets are being dropped by Wireguard itself.

Note, I have not yet configured any NAT as I only intent to use the VPN to access servers on my internal network.

I'm puzzled about what's happening and what my next steps should be. Any help would be greatly appreciated.

[Monviech (Cedrik)]

Have you created a Firewall rule in "Wireguard (Group)" to allow IPv6 traffic?

For troubleshooting, create an Any Any rule in that Zone, and then ping the Wireguard ULA of the OPNsense from the Wireguard ULA of the Client, and the other way around.

[sammyrose]

The "Wireguard (Group)" firewall interface was empty. My rules were instead in my "WG" interface which is assigned for WireGuard. No matter, I created any-any ICMP rules in both "WG" and "WireGuard (Group)" firewall interfaces. After the handshake, the same problem persisted. I did not get a response to the echo request despite observing traversing packets with tcpdump.

It strikes me as odd that both the client and server are doing the same thing. Both appear to receive the echo request, but then neither appear to send an echo reply. Could this be something to do with the LA network block chosen? I know LAs aren't routed... could that be stopping packets from being handed from Wireguard to the encapsulating interface?

[Monviech (Cedrik)]

No I have created Wireguard tunnels with ULAs before and they were working.

GUA and ULA work over Wireguard, LLA not.

Just as sanity check, you did add fd2d:aaaa:bbbb:cccc::10/128 to the wireguard peer on the OPNsense side, too?

[sammyrose]

Just as sanity check, you did add fd2d:aaaa:bbbb:cccc::10/128 to the wireguard peer on the OPNsense side, too?

Sure have.

Any other ideas I can try?

[bimbar]

Isn't the usual port 51820, not 51280?

[sammyrose]

Isn't the usual port 51820, not 51280?

Maybe . I'm running on a different port entirely, just noted that for the example.

[sammyrose]

I was able to solve this issue.

It appears the problem was the wireguard configuration (which was reused from ipv4). Once I removed configurations and started again, the tunnel began to function.

Interestingly after that, I ran into another problem where IPv6 tunnels occasionally swapped to IPv4 upon connection and stopped functioning. I ended up separating the dynamic DNS between IPv4 and IPv6 which resolved this problem.

So take-away lesson, don't reuse Wireguard configurations after they're configured.