[ale] VPN+wireless is *really* slow

[Keith R. Watson]

At 08:17 AM 3/17/2003 -0700, you wrote:
>"Keith R. Watson" <keith.watson at gtri.gatech.edu> writes:
>
> > At 08:43 PM 3/15/2003 -0700, you wrote:
> > >Hi folks,
> > >
> > >I've finally taught my Linux firewall and my WinXP box to talk to each
> > >other via IPsec over a wifi connection. Due to M$ idiocy, this
> > >involves tunnelling PPP in an L2TP tunnel which is in turn being piped
> > >through an IPsec tunnel; all this, as you might imagine, lends a whole
> > >new meaning to the phrase "configuration nightmare". What fun. Only
> > >took five days to get it right. But boy, when it started working I
> > >just about jumped out of my pants.
> > >
> > >However, I have a problem. My favorite thing to do with the XP box is
> > >to fire up VNCviewer and use my Linux boxen remotely. But here I am
> > >screwed, it seems. If I run the IPsec tunnel over a 10baseT
> > >connection, or if I run wifi with no IPsec, VNC works fine. But if I
> > >run my VNC session over IPsec+wifi, VNCviewer just sits there forever
> > >saying, "Please wait, initial screen loading." Tcpdump reveals that
> > >only a tiny fraction of the expected VNC traffic is actually leaving
> > >the server (which, incidentaly, lives on my 10baseT LAN behind the
> > >IPsec<-->wireless firewall).
> > >
> > >I suspect this has something to do with MTUs and/or fragmentation, but
> > >I could be wrong, and my clue supply has run out. Any help?
> > >
> > >Thanks,
> > >
> > >-- Joe Knapka
> >
> > Joe,
> >
> > I've done some testing on the interaction of MTU and VPN traffic. Try
> > lowering your MTU to 1000. If the problem clears up then you have an
> > MTU/VPN conflict. If not then the problem lies elsewhere.
>
>Thanks, Keith.
>
>Setting the MTU to 800 on the VNC server box made everything work.
>The VNC server is running on a Slack 8.1 box with a stock kernel,
>and *every* packet that come out of that box has the "Don't Fragment"
>bit set. I wonder why that would be?
>
>Thanks,
>
>-- Joe Knapka

Joe,

A VPN uses an encrypted data stream. It is the equivalent of digitally 
signing each packet. If a packet is fragmented it looks as if it was 
tampered with. This would be like the checksum of downloaded code not 
matching the checksum posted on the source site.

There are many things you can do to a packet that require information to be 
added to the header. Once the data in the packet plus the header exceed the 
MTU of the network the packet will be fragmented.

I first noticed this problem when trying to connect to an HTTPS:// URL over 
a VPN. I could pull up any HTTP:// URL but an HTTPS:// would hang. I could 
map to SMB shares but I couldn't transfer any files greater than about 1K 
in size. Lowering the MTU solved the problem.

Lowering the MTU lowers the efficiency of network transfers because the 
ratio of data size to header size has gone down. Maximum efficiency is 
achieved by setting MTU to the largest size that doesn't cause packet 
fragmentation.

keith
-------------

Keith R. Watson                        GTRI/ITD
Systems Support Specialist III         Georgia Tech Research Institute
keith.watson at gtri.gatech.edu           Atlanta, GA  30332-0816
404-894-0836

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale