dropping small packets (ping with 96 to 111 data bytes)

[Jesse Reynolds]

Hello

I'm new to OpenVPN. I've set it up on a Mac running 10.5.8 at work,
and my Mac at home running 10.6.1. I've installed Tunnelblick 3.0 b16
at both ends and have manually configured the openvpn.conf server file
on the server at work.

Everything works, however some small packets get dropped. I've
isolated this to packets of around 100 bytes in length.

I have a repeatable test case using ping with packets of different
sizes. Anything between a data size of 96 and 111 bytes inclusive get
dropped. Apackets smaller and larger all work fine (even up to 2000
bytes). If I enable LZO compression then this 'drop window' goes down
by one byte, so it's from 95 to 110 inclusive.

This manifests in some DNS requests never coming back, being unable to
ssh into some machines at work, and intermittent FTP failures (timeout
before any data is transferred).

I've used tcpdump on the tun0 and en interfaces at both ends, and I
can see the ICMP reply packets coming back on my local wifi en1
interface, but they never make it to the tun0 interface when the
packets are in this drop window in length.

This feels like a bug in openvpn, or possibly the tun driver? Any
ideas anyone?

Thank you
Jesse

[jkbull...gmail.com]

Thanks for the detailed description of the problem. Here are some
thoughts:

Are the packets dropped in both directions or only one? It sounds like
they are being dropped on the Snow Leopard machine and not on the
Leopard machine; is that correct? If there's any way you can test with
10.5.8 on both ends to verify that it is a problem only on Snow
Leopard, that would help a lot.

tun/tap has not been tested extensively on Snow Leopard; I don't know
about OpenVPN.

You might also want to try tap instead of tun. Tap seems to have its
own problems, but maybe at least they'd be different.

(There is a known bug in Tunnelblick 3.0b18 on Snow Leopard when using
"Set nameserver", but you're using 3.0b16. The bug should be patched
in the next day or two.)

[Jesse Reynolds]

Hi there

And thanks for the quick reply!

Yes the packets are being dropped on the snow leopard side. They do
the full round trip except for the very last stage of coming out of
openvpn and onto the tun0 interface. (I can send the tcpdump output
via private mail if you like.)

I don't think tap will work with openvpn server on a mac? So I think
I'm stuck with tun unless I install linux or solaris on a spare mac at
work.

I'll try 10.5.8 at home and see how we go.

Cheers
Jesse

[Jesse Reynolds]

OK I've just tried on a 10.5.8 iMac at home. The exact same problem is
happening, including seeing the UDP vpn reply packet coming in on en1
but it not emerging from the tun0 interface. I just installed
Tunnelblick 3.0b16 on this mac, it's never had tun/tap or Tunnelblick
or any vpn software on it.

So:

ping -s 94 <ip> - works
ping -s 95 <ip> - works (icmp packet size: 103 bytes, vpn udp packet
size: 157 bytes)
ping -s 96 <ip> - fails (icmp packet size: 104 bytes, vpn udp packet
size: 165 bytes)
ping -s 97 <ip> - fails
...
ping -s 110 <ip> - fails
ping -s 111 <ip> - fails (icmp packet size: 119 bytes, vpn udp packet
size: 173 bytes)
ping -s 112 <ip> - works (icmp packet size: 119 bytes, vpn udp packet
size: 181 bytes)
ping -s 113 <ip> - works


Any other thoughts? :-) Is there a way to get some debug output from
the tun driver perhaps?

Cheers
Jesse

[Jesse Reynolds]

This is happening on a Linux client as well. My workmate says:

"i'm getting exactly the same problem on
openvpn-2.1-0.32.rc15.fc11.x86_64 (fedora core).
i wonder if using tcp instead of udp would make a difference?"

So I imagine this rules out the tun device driver on the Mac, and
Tunnelblick! Perhaps I'll repost this to the openvpn users list.

I wonder if the router at work is doing something strange to the UDP
packets that it's sending to to the client that causes openvpn to drop
them.

Jesse


2009/9/30 Jesse Reynolds <jessedr...@gmail.com>:

--

Jesse Reynolds
Carbon Planet Limited - http://www.carbonplanet.com/
Virtual Artists Pty Ltd - http://www.va.com.au/

[jkbull...gmail.com]

Thanks for the updates. Note that Tunnelblick 3.0b16 has OpenVPN
2.1_rc19, not _rc15.

I think you're right about the router (or even the OpenVPN server);
maybe the client OpenVPN considers the packets to be malformed and is
dropping them. Maybe turning up the --verb level in the client OpenVPN
would point to that.

If this was a more widespread problem, I would think we'd have heard
more about it. And for a client on a different platform to have the
same problem with the same OpenVPN server -- sounds like the problem
is there.

On Sep 30, 6:23 am, Jesse Reynolds <jessedreyno...@gmail.com> wrote:
> This is happening on a Linux client as well. My workmate says:
>
> "i'm getting exactly the same problem on
> openvpn-2.1-0.32.rc15.fc11.x86_64 (fedora core).
> i wonder if using tcp instead of udp would make a difference?"
>
> So I imagine this rules out the tun device driver on the Mac, and
> Tunnelblick! Perhaps I'll repost this to the openvpn users list.
>
> I wonder if the router at work is doing something strange to the UDP
> packets that it's sending to to the client that causes openvpn to drop
> them.
>
> Jesse
>

> 2009/9/30 Jesse Reynolds <jessedreyno...@gmail.com>:

>   Carbon Planet Limited -http://www.carbonplanet.com/