Normally these kinds of problems are MTU related, but since big pings are
working, it may be more than that.
I would try running tcpdump on both the tun/tap device and the device which
links to the internet so that you see packets before and after they pass
through openvpn, and before and after they transit the internet, and maybe
even run openvpn at --verb 9. Very often you can debug these kinds of
problems by analyzing tcpdump output. If a UDP packet goes into openvpn but
doesn't come out on the tun/tap interface, then it is usually a firewall problem.
If a UDP packet comes out of openvpn but is not received by the remote peer,
then it is probably an MTU or router problem. If a packet never appears as
incoming on a tun/tap interface, then you are probably missing a route on the
server, or do not have IP forwarding enabled. Raising or lower --udp-mtu can
sometimes help. Disabling path MTU discovery is also something to try:
"--mtu-disc no". If you are tunneling over a tap device (--dev tap), be sure
to use --tun-mtu-extra 64.
Usually it boils down to a router/firewall in the path that is incorrectly
configured or is explicitly blocking certain kinds of packets. Since big
pings are working that is less likely in this case. The current development
version of OpenVPN (
http://openvpn.sourceforge.net/beta/openvpn-22.214.171.124.tar.gz ) can do IP
fragmentation internally, fixing problems where routers in the path are not
handling fragmentation correctly. If you try this, you will need to build
with the --enable-mtu-dynamic configure option, then use the --mtu-dynamic
option to select the maximum fragment size. For example --mtu-dynamic 500 500
will transparently fragment packets sent between peers to be no larger than
Perhaps the problem is application-specific? You mention that a particular
client application hangs. Do other apps hang as well? Try an FTP transfer of
a file > 100000 bytes (without using openvpn compression) in both directions.
If that fails, it's probably a more general problem with the network path to C.
If the FTP test succeeds, then there may be a specific kind of communication
which your client application is attempting which is not being forwarded over
the tunnel. Examples of such kinds of communications include multicast or
non-IPv4 protocols, which require ethernet bridging to work successfully.
OpenVPN has a lot of features to work around these kinds of problems, but you
will need to further narrow down where the problem is occurring.
£ukasz <oxcart@...> said:
> I have a strange problem with running openvpn tunnel, but i'm not sure
> it is openvpn specific.
> I want to use my tunnel for communication between client and server
> instances of some kind of terminal aplication(OTC Terminal).
> I have 3 machines...
> A - it's router at network where the server of this application is
> B - my router at home
> C - router at network where clients instances should run.
> Tunnel beetween A and B works perfectly... this two networks/cities
> are very close... but ping from A to B is 10ms greater then from A to
> (Only one tunnel is up, because I use B only for testing.)
> C is located in another part of my country... configuration of router C
> is the same as B, i can start client application on terminals in C
> network but after loging into server, and choosing some options from
> menu client hangs, connection is ok... but nothing happens.
> Ping works ok... large - 10000, even 15000.
> Do you have any idea what can be wrong?
> Thanks for help.
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> Openvpn-users mailing list