[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] MTU, link-mtu and tun-mtu


  • Subject: Re: [Openvpn-users] MTU, link-mtu and tun-mtu
  • From: Mathias Sundman <mathias@xxxxxxxxxx>
  • Date: Sun, 23 Oct 2005 11:51:58 +0200 (CEST)

On Sat, 22 Oct 2005, Phillip Vandry wrote:

After the tunnel was up, looking at the resulting MTU on the tun0
interface, I found it to be 1419. This is in line with what I expected:
several dozen bytes less than the link MTU. However, in testing, I
found that I could not pass packets larger than 1395 bytes (IP
datagram size). By sniffing, I found that 1395 byte payloads
resulted in 1357 byte encrypted packets. So far, so good. But add
one byte to the payload, to 1396, and the result was 1465, and
that's too big.

Did OpenVPN miscalculate its overhead? If it calculated an MTU for the
tun0 interface (tun-mtu) of 1419 when I specified a link-mtu of 1460, I
would have thought that meant that all payloads up to 1419 bytes
should fit inside the link-mtu I specified, 1460. It shounds like it
should have calculated 1395 as the tun-mtu.

I don't know the exact details of this so I'll let someone else like James comment on this but my first guess is that there is a missunderstanding somewhere about what sizes that is to be refered. If it is "data payload size", IP packet size, ethernet frame size and so on. For example when pinging with a specific size I believe it's the data payload size you specify not the resulting IP packet size and so on. This often leads to false conclusions about what MTU to specify. But again, I don't know the details by head, I just think there is a logical explaination to what you are seeing rather than a bug in the software.


I have another question, also related to the MTU. When used in server
mode (multiple clients on a single tun interface), the tunnel
interface on the server can only have one MTU, of course. Am I
stuck using the lowest MTU of all of the clients? I guess yes. Is
there a workaround for this, or must I use OpenVPN the old way
(one interface and one daemon per tunnel) if I want the tunnels to
have different MTUs?

Correct, this is a limitation of the current design that all clients have to use the same MTU, fragment and mssfix values and they can't be changed after the server has been started.


The only way you can workaround this without going back to the old PtP mode is setting up "groups" of users that can live with the same MTU settings and run multiple instances of OpenVPN in server mode on your server. You will of cource need one UDP/TCP port and tun/tap interface per instance, but it's still better that going back to PtP mode in most cases.

//Mathias

--
_____________________________________________________________
Mathias Sundman                  (^)   ASCII Ribbon Campaign
OpenVPN GUI for Windows           X    NO HTML/RTF in e-mail
http://openvpn.se/               / \   NO Word docs in e-mail

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users