|
|
Okay, I've managed to walk two clients through changing the MTU on their
VPN adapter from 1500 to 1300, but am not sure that it has really solved
these symptoms.
Don't know if this is a useful diagnostic, but I attempted to ping both a
VPN client and www.yahoo.com from my machine here, trying to find the
largest PING packet (using -l <size>) that would get past the barrier. Do
these numbers look good?
VPN client expected-mtu:1300 max-sendable-buffer:1258
Yahoo.com expected-mtu:1500 max-sendable-buffer:1472
-----Original Message-----
From: openvpn-users-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:openvpn-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of James
Yonan
Sent: Wednesday, September 17, 2003 4:49 AM
To: Mathias Sundman
Cc: openvpn-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Openvpn-users] [DIAG] Connection appears to work but is not
useful
Mathias Sundman <Mathias.Sundman@xxxxxxxxxx> said:
>
> > I've been trying to setup a VPN between the local network here and a
few
> > roaming co-workers. The VPN went initially went up with no problems
but
> I'm
> > finding it fairly difficult to use and I'm not sure even whether it's
> > OpenVPN's fault; I just don't have the tools to test things.
> >
> > I am able to ping across with no problems, and the other machine shows
up
> on
> > my network neighborhood with no problems.
> >
> > However, the VPN was going to be used primarily for database protocols
> and,
> > while I am able to establish a database connection (most of the time)
> across
> > the gateway and do very simple queries, if I launch the full database
> > application it waits for about a minute before crashing out with
> "Database
> > connection unexpectedly closed". Database protocol uses TCP. With a
> window
> > open to the verb9 statuses, I see about a second of heavy activity
after
> > which the packets drop down to their previous once-every-other-second
> rate.
>
> It sounds to me very much like a MTU problem. I had similar problems
> when I was using VTUN to bridge ethernets. I solved it by using linux
> TCP MSS adjusting to all bridged tcp sessions using the following
> command:
>
> iptables -A FORWARD -i br0 -o br0 -p tcp --tcp-flags SYN,RST SYN -j
TCPMSS
> --set-mss 1400
>
> I think you have to use an even lower mss value with openvpn, as it
> has an even larger overhead than vtun (as default).
>
> You could also try adjusting the MTU with the build-in parameters
> in openvpn.
Yes, I would agree that the problem seems to be MTU related.
MTU problems often occur when you are trying to encapsulate one protocol
into
another and the network is not able to deal with the resulting packet size
increase. IP networks have a capability called "Path MTU Discovery" that
is
designed to fix this problem, but it is often broken due to the way that
firewalls are commonly configured. In order for Path MTU Discovery to
work,
routers and firewalls need to forward certain kinds of ICMP messages.
Luckily, there are several workarounds to MTU problems in OpenVPN.
On Windows, you can lower the TAP-Win32 MTU by going to the adapter
advanced
properties.
On Linux you must match this MTU by using a --tun-mtu option.
You can use the --mtu-dynamic option to have OpenVPN fragment packets
internally (less efficient than other options, intended as a last resort).
OpenVPN 1.5-beta8 will have a new feature --fixmss which does the same
magic
as the iptables command above, but is cross-platform across OpenVPN's
platform
space.
BTW, if you need to debug a VPN connection use tcpdump on *nix or WinDump
on
Windows.
James
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
|