Receiving packets larger than 1500 bytes

[tangomega 0]

Hi,

 

I'm having an interesting issue with my VPN connection. My connection is working properly and I'm able to get a decent speed (10 mbps) but the CPU of my router is working heavily when the traffic approches 10 mbps.

 

My Setup

 

VPN Client :

Ubuntu Server 13.04

With: OpenVPN 2.2.1 x86_64-linux-gnu [sSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [iPv6 payload 20110424-2 (2.2RC2)] built on Feb 13 2013

 

Router

Cisco 1811

 

The issue

I noticed that the CPU of my router is spiking when "a lot" of traffic is going through the vpn connection. In addition, I receive these syslog from my router:

 

257: Severity "Warning" in [192.168.XX.XX: 214: Jul 29 15:01:46: %IP_VFR-4-FRAG_TABLE_OVERFLOW: FastEthernet0: the fragment table has reached its maximum threshold 64]

 

After some research I realized that the packets I receive from the AirVPN gateway are oversize: they are 1517 bytes long (I sniffed my WAN interface to determine this). Bigger than MTU packets explain the CPU spikes and the syslog warning that I receive: my router's cpu cannot reassemble ip packets fast enough. 

 

Just to be clear: the layer 3 payload is of size 1517 bytes. In total the actual size of the data on wire is 1514 + 71 bytes.

 

What I tried

Clearly there is some sort of issue with the OpenVPN connection. I searched around and I tried different combinaison of the "mssfix" and "fragment XXXX" (I tried fragment 1400) but I'm unable to receive packets smaller than MTU.

 

Does anyone has any tip on this sort of issue?

Thanks for your help

 

 

[Staff 10014]

Hello,

 

CPU load is normal. Routers CPU do not have built-in AES commands and their processing power is low, if compared to nowadays desktop and laptop computers. The limit for a typical consumer's router CPU to encrypt and decrypt on the fly AES-256-CBC is 7-10 Mbit/s total throughput (AES-256-CBC is the cipher of our OpenVPN Data Channel).

 

Some fragmentation may be perfectly normal, as long as it does not impact performance. Since you already reach the maximum theoretical throughput peak allowed by your router processor, you probably have nothing to worry about.

 

Kind regards

[tangomega 0]

Its not my router that starts the connection to your vpn gateway: my ubuntu server handles that. My router's cpu is not affected by any encryption or decryption as it only sees garbage data going through, it's only the virtual-reassembly process that eats up all the cpu power.

 

I noticed that I tend to receive fragmented packets mostly for P2P traffic and not for standard http traffic. I tried multiple servers and I'm having the same issue. I'm using the recommended config for openvpn (Direct, protocol UDP, port 443)

 

I would agree on the "some fragmentation" but in this case it seems systematic...

 

Regards

[tangomega 0]

I forgot to mention: the cisco 1811 is not a consumer routeur, if this router is having trouble, I'm guessing that a typical consumer router would just burn right there...

[Staff 10014]

@tangomega

 

Ok, it was wrongly understood that OpenVPN was running in a DD-WRT router. Our fault, you were very clear in your description.

 

Your idea on how to fix the issue is just fine, please see also here:

 

http://wandin.net/dotclear/index.php?post/2009/01/08/OpenVPN-MTU-Size

 

http://openvpn.net/archive/openvpn-users/2004-11/msg00044.html

 

Alternatively, just connect over TCP, but this might not be the ideal solution due to performance hit.

 

Kind regards

[tangomega 0]

Thanks for your great support: its great to see a business that cares about their customers

 

I tried to play a little bit more with mss-fix and fragment but whenever I apply the fragment command the traffic won't go through the tunnel. 

 

http://openvpn.net/archive/openvpn-users/2005-05/msg00385.html

http://openvpn.net/index.php/open-source/faq.html

 

From the doc:

Probably. It's best to change the mssfix parameter rather than directly changing the MTU of the TUN/TAP adapter. For example:

You could also combine this with:

Probably. It's best to change the mssfix parameter rather than directly changing the MTU of the TUN/TAP adapter. For example:

 

mssfix 1200

You could also combine this with:

 

fragment 1200

Note however that fragment will exact a performance penalty.

Common values to try for mssfix/fragment: 1200, 1300, or 1400.

Note that while mssfix only needs to be specified on one side of the connection, fragment should be specified on both.

 

It seems like the fragment directive has to match on both the client and server configuration. For now I'll fallback to a TCP connection but this kinda sucks... 

 

FYI:

1. I know that another user of AirVPN that also uses a cisco 1811 has the same issue when using transmissionbt 

 

2. Here is the result of the mtu-test:

NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1557,1557] remote->local=[1557,1557]