[Openswan Users] VPN connection established but ...

[TheCajun]

> 75.161.95.208 -  - 108.163.158
> 75.161.95
> 
> > On 12/11/2012 15:19, TheCajun wrote:
> > > Perhaps a little more background is necessary.  I had a negear at home which
> > > was providing a successful  vpn connection to my office (both ways).
> > > Due to a project requirement, I need to get software vpn working.  I
> > > took my netgear out of the picture, reconfigured my network and now I
> > > have openswan working.  It works 100% from left to right (openswan at
> > > home to netgear at office), but from right to left (netgear at office to
> > > openswan at home) the commands tend to lose packets.  A command output will
> > > start but stop before completion (will not responded to any key press).
> > > Some times after many minutes it will complete the output. Other times
> > > it times out or something like that.  For instance, a ls command on
> > > directory with little in it will complete, but ls -l command will not.
> > >
> > That definitely sounds like an MTU issue -- small packets get through, but large ones do not.  If you trace the ESP packets on both ends you'll likely be seeing the larger ones dropped.  (ping -s will be helpful in generating some appropriate size packets).


Well I changed th mtu on the linux machine at home (one running openswan)
to 576 and it appears to have fixed the problem.  So now my question is. 
Why did everything work with the netgear vpn with the default mtu of
1500?  And, why does it work with default of 1500 from home to office
and not from office to home using openswan?

Thank you very much.  This has been a puzzle for me and I spent many
days on this.

> 
> I successfully ping from both directions with ping -s 4096 <ip_address>
> > 
> > >> On 11/10/2012 12:22 PM, Durwin wrote:
> > >>> I can also ssh back to the left, and if I enter a command with
> > >>> very little output it works.
> > >>
> > >> Is the MTU of your connection properly set on both sides?  ICMP messages blocked?  Perhaps the left side needs to fragment to fit through a small MTU pathway but it doesn't know that.  Or there is a black hole router along the path.
> > >>
> > >> I also had a dumb ISP once with a proprietary link that had a smaller MTU than Ethernet -- yet they also blocked ICMP type 3 messages so I wasn't getting error messages... packets were just disappearing.
> > >>
> > >> Just a thought.
> > >> _______________________________________________
> > >> Users at lists.openswan.org
> > >> https://lists.openswan.org/mailman/listinfo/users
> > >> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> > >> Building and Integrating Virtual Private Networks with Openswan:
> > >> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> > >
> > > _______________________________________________
> > > Users at lists.openswan.org
> > > https://lists.openswan.org/mailman/listinfo/users
> > > Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> > > Building and Integrating Virtual Private Networks with Openswan:
> > > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> > >
> 
> -- 
> reality.sys corrupted. universe halted. reboot (y/n)?
> 
> TheCajun <thecajun at nmia.com>
> 
> _______________________________________________
> Users at lists.openswan.org
> https://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

-- 
reality.sys corrupted. universe halted. reboot (y/n)?

TheCajun <thecajun at nmia.com>