1
Virtual private networks / ICMPv6 packet too big packets lost with IPv6 VPN NAT
« on: March 20, 2024, 01:15:31 am »
Hi!
I am running OPNsense 24.1.3_1. I have configured Wireguard VPN (both IPv4 and IPv6) with the help of these excellent guides:
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
https://schnerring.net/blog/opnsense-baseline-guide-with-vpn-guest-and-vlan-support/
Notably I've configured IPv6 outbound NAT to hide my IP and used normalization rules to set the Max mss to 1360 for Wireguard.
As far as I can tell everything works - I get 10/10 on test-ipv6.com and my VPN provider shows that I am using their IPv6 IP.
However, I was curious to see how path MTU discovery worked with the normalization rules since I read PMTUD is very important for IPv6. I also know that NAT for IPv6 is not advised, but changing your IP is one part of the privacy toolkit according to sites like Proton etc.
I used these commands to test PMTUD while performing a packet capture on the VPN and LAN interfaces for IPV6-ICMP:
I saw this in the packet capture on the outgoing VPN interface (the source and destination IP are the same - the outgoing VPN interface's IP address):
The "packet too big" packet never leaves the LAN interface and the device I tested from never receives it.
Therefore it seems that outbound IPv6 NAT causes the outgoing VPN interface's IP address to respond to itself with packet too big, and the packet is not propagated to the original sending device.
Is this a bug? Or an unfortunate side effect of outbound IPv6 NAT?
Is there something I can configure to let the ICMPv6 "packet too big" packet propagate back to the original sending host?
Thanks.
I am running OPNsense 24.1.3_1. I have configured Wireguard VPN (both IPv4 and IPv6) with the help of these excellent guides:
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
https://schnerring.net/blog/opnsense-baseline-guide-with-vpn-guest-and-vlan-support/
Notably I've configured IPv6 outbound NAT to hide my IP and used normalization rules to set the Max mss to 1360 for Wireguard.
As far as I can tell everything works - I get 10/10 on test-ipv6.com and my VPN provider shows that I am using their IPv6 IP.
However, I was curious to see how path MTU discovery worked with the normalization rules since I read PMTUD is very important for IPv6. I also know that NAT for IPv6 is not advised, but changing your IP is one part of the privacy toolkit according to sites like Proton etc.
I used these commands to test PMTUD while performing a packet capture on the VPN and LAN interfaces for IPV6-ICMP:
Code: [Select]
ping -M do -s 1400 -6 www.google.com
Code: [Select]
traceroute -6 www.google.com --mtu
I saw this in the packet capture on the outgoing VPN interface (the source and destination IP are the same - the outgoing VPN interface's IP address):
Code: [Select]
length 1284: fcw:x::y:z > fcw:x::y:z: ICMP6, packet too big, mtu 1420, length 1240
The "packet too big" packet never leaves the LAN interface and the device I tested from never receives it.
Therefore it seems that outbound IPv6 NAT causes the outgoing VPN interface's IP address to respond to itself with packet too big, and the packet is not propagated to the original sending device.
Is this a bug? Or an unfortunate side effect of outbound IPv6 NAT?
Is there something I can configure to let the ICMPv6 "packet too big" packet propagate back to the original sending host?
Thanks.