OPNsense Forum

Archive => 20.1 Legacy Series => Topic started by: CosmicRay on May 07, 2020, 02:42:40 AM

Title: Improper handling of packet fragmentation
Post by: CosmicRay on May 07, 2020, 02:42:40 AM
Hello,

While troubleshooting an issue with slow TCP startup, I did some tests from a Linux box using tracepath and ping -Mdo.  None of these tests made it past the openvpn box.  The route out is over a Wireguard VPN with a MTU of 1420. 

Regular pings work.

tcpdump from opnsense on the wireguard interface showed:

19:39:01.863080 IP (tos 0x0, ttl 64, id 7009, offset 0, flags [none], proto ICMP (1), length 56)
    x.x.x.x > x.x.x.x: ICMP 8.8.8.8 unreachable - need to frag (mtu 1420), length 36
   IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 1500)
    x.x.x.x.56499 > 8.8.8.8.44444: UDP, length 1472

However, this packet never made it back out the LAN interface.

If I add a normalization rule for "do not fragment" on the Wireguard interface, then the tracepath proceeds normally; however, it also fails to detect that the path MTU is less than 1500, which no doubt will result in a mess of fragmented packets.

Is there any solution here?
Title: Re: Improper handling of packet fragmentation
Post by: Maurice on May 07, 2020, 07:28:42 PM
Did you assign the Wireguard interface?
Title: Re: Improper handling of packet fragmentation
Post by: CosmicRay on May 07, 2020, 08:06:00 PM
Yes.  Interface assigned, gateway assigned, and a standard NAT and route.

I wonder if part of the challenge here is that the VPN provider here assigns a /32, so both the from and to address on the ICMP packet are the same, and to the firewall it might look as if it originated on the firewall itself?