AWS with Large DNS queries: MTU Jumbo Frames -- Wireguard vs OpenVPN timeouts

Pritunl Pritunl VPN
1

So we’re setup on AWS ec2 instances offering clients both OpenVPN and Wireguard through the native Pritunl client. AWS states that most network traffic will by default flow using jumbo frames, showing a bunch of exceptions when this would not be the case.

We’ve tried different configs of DNS servers, but our latest config is to have the the PT servers setup to use DNS Server: 169.254.169.253 and have “Enabled VPN Client DNS Mapping” to force traffic through pritunl-dns.

Based on the AWS Docs linked above, I would assume jumbo frames are used between the AWS DNS servers and the ec2 instance. I was hoping that some process on the VPN server would handle splitting up large packets, but we seem to be getting random timeouts.

The issues we have are with large DNS UDP packets. A specific example might be: dig txt cnn.com. This returns a huge 3716 byte response.

Under Wireguard, the response are received by the client, mostly reliably. It would sometimes get delayed, but only on very rare occasions would it timeout.

Under OpenVPN - it’s more a hit/miss. We see timeouts or delays about half the time.

I have played around with MTU settings and followed all the MTU debugging guidance from the PT docs, but still can’t find a 100% reliable fix. We also see this in the server logs every so often:
read UDPv4 [EMSGSIZE Path-MTU=1500]: Message too long (fd=5,code=90)

Any suggestions on what to look at next?

2

The Pritunl DNS server will handle communicating over TCP when the MTU is exceeded. Check for ;; SERVER: 10.140.0.1#53(10.140.0.1) (TCP) in the dig response. This is likely an issue with Path MTU discovery. Run the MTU commands in the client debugging documentation and find the largest MTU that doesn’t fragment then check 1 size larger and verify it returns message too long. There should not be any MTU sizes that don’t either ping or return message too long. If there is lower the connection MTU in the Pritunl server settings.

3

So I did these tests and I get different results depending on if I use OVPN or Wireguard. Tests done on a Mac with Pritunl client:

Wireguard: 1392 (adapter mtu shows 1420)
OVPN: 1410 (adapter mtu shows 1500)

Which value should I use?

What’s odd, is when I do the ping tests, I get timeouts to the first couple of packets, then I see replies. Almost as if there is a delay before the packet state gets updated somewhere.

4

If there are no path MTU discovery errors the connection MTU should be left empty. The ping should either return message too long or a successful ping. If there is a range where it does not work the MTU should be lowered. If it is working there is no need to change the MTU.

5

I’m not getting path MTU discovery errors doing the ping test. I either see:

  1. Timeouts
  2. Message too long
  3. Ping Reply’s.
6

If it’s a complex routing configuration it may be an issue with ICMP redirects but the ping would likely show redirect host. This would typically cause timeouts, routing delays and slow performance. It may not get logged on the client if it occurs on the server with a NAT configuration. Run the commands below on both the client and server. If it’s disabled try enabling it. It could also be an asymmetric routing issue if there are other routers involved. These issues would only be relevant if it is happening for some of the routes, the traffic on the VPN virtual network to the Pritunl server would not be effected.

sudo sysctl net.ipv4.conf.all.accept_redirects
sudo sysctl net.ipv4.conf.default.accept_redirects

sudo sysctl -w net.ipv4.conf.all.accept_redirects=1
sudo sysctl -w net.ipv4.conf.default.accept_redirects=1
7

There is nothing complex here. It’s standard 10/8 NAT routing from client to AWS VPC.

Also, we have no other issues. Just large DNS records (TXT > ~1500 bytes in this case) that timeout.

The problem is apparent whether “VPN Client DNS Mapping” = ENABLED (to use built in PT-DNS) or when using VPC DNS directly without the local DNS server running.

Setting the MTU to 1392 seems to reliable solve the issue for both clients connect using OVPN or WG. Not sure what performance impact lowering the MTU will have, but planning on making this change to our production VPN servers in the next day or two to see.

Before making the MTU switch, I did notice while doing a Wireshark on the client side that there was no UDP DNS packet with the

.... ..1. .... .... = Truncated: Message is truncated

flag set, which you would expect if the DNS server could not get the response out within the MTU size. I’m guessing that the DNS server thinks it can get the message through but that response is not making it for some reason and that is why there is no retry using TCP.

Again, the MTU override solves this problem – oddly, the packet arrives as a reassembled UDP packet, but at least its complete and doesn’t time out! :slight_smile:

8

It can also be path MTU discovery on the server side networks. If you are blocking ICMP between the Pritunl server and other servers including the DNS server it can cause issues.