We've successfully launched our first OpenVPN + openswan solution into
production tonight. We've seen some interesting behavior on the wire
tonight that I thought I would share with the list.
We anticipated that we would have some difficulty with fragmentation.
The OpenVPN fragment setting is 1400 and the openswan overridemtu
setting was also 1400. We started to see lots of requests for
fragmentation so I set to work trying to find optimal MTU settings.
Unfortunately, the testers have gone home so I don't have final
information but what I learned was interesting.
It appears that OpenVPN likes an MTU 10 bytes smaller than openswan
(using 3DES and SHA1 - a gather other algorithms would change this
number). We are currently set to 1400 and 1410 respectively.
It was far more challenging trying to match up the physical interfaces.
I set my OpenVPN client to its maximal do not fragment ping (1382 bytes)
and kept trying to lower the MTU on the VPN gateway physical interface.
I assumed that when the MTU dropped below the OpenVPN MTU, I see
failures but that did not occur. In fact, I only saw very small packets
- typically under 400 bytes. It made me wonder if OpenVPN didn't have a
horrible fragmentation problem and fragmented everything but the timing
wasn't right. I'd send a 1410 byte packet every second but I'd see a
399 byte packet go out ever second.
I am wondering if this is compression at work. If so, that's quite an
impressive reduction. Of course, the ping packet is probably simply
text but that's still impressive -- better than I thought it would be.