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 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