[Openswan Users] Where did routes go with Openswan 2.6.31?

[Michael H. Warfield]

On Mon, 2011-03-14 at 11:16 -0400, Michael H. Warfield wrote: 
> On Mon, 2011-03-14 at 09:45 -0500, Greg Scott wrote: 
> > Ø  That's a problem with Windows, and most likely the bug around the number of routes with 
> > 
> > Ø  non-default MTU routes incrementing but never decrementing.  Over time, this caused Windows 
> > 
> > Ø  machines to become unresponsive over the network.
> > 
> >  
> > 
> > No. This behavior was different. I was apparently advertising the
> > default MTU size of 1500. So Windows believed me and sent 1500 byte
> > packets over the tunnel to the other end of the RDP session. But with
> > the IPSEC overhead, the highest I could support was 1440 or something
> > like that. Somewhere along the line those 1500 byte packets would get
> > fragmented and then never reconnected back together on the other end.
> > So the RDP tunnel would crash. This happened to lots of PCs. Not all,
> > but lots. The first workaround was to reduce the MTU size in one of
> > the offending PCs. This worked, but of course only for that PC. The
> > best workaround we could come up with at the time was to just lower
> > the MTU size I advertised. Thus the updown script. 
> > 
> >  
> > 
> > So now, with no traditional looking routes over the tunnel, what am I
> > advertising for MTU and will some apps that send large packets break
> > as before?

> Now THAT sounds like a PMTU discovery problem.  Are you blocking ICMP
> packets at some point, like a firewall?  If so, that's your real
> problem, and it's a very common mistake made in firewall configurations.
> You can not block all ICMP or things exactly like this will fail.  It
> will even fail with PPP (or PPPOE) links in the middle of routes.
> Anywhere the MTU is reduced will trigger this if the ICMP error return
> "HOST_UNREACH" "WOULD_FRAGMENT" is blocked from getting back to the
> sender.

> It's not that they are fragmented along the way, it's just the opposite.
> PMTU discovery works by sending a large packet (well, starts with the
> local MTU) with the "DF" (Don't Fragment) flag set.  If it gets an ICMP
> error back, it reduces its effective MTU and tries again.  If it doesn't
> get an error, it assumes the packet got there and sticks with that MTU.
> If you block that ICMP, the connection breaks by timing out when the
> packets are dropped and the error ignored because the error never gets
> to the sender.

> This is not an Openswan problem at all.  This is most likely a firewall
> configuration error at some point somewhere, IMHO.

I should have added...  There are tools on both Windows and Linux to
test for this including traceroute --mtu and tracepath.  More
information here:

http://packetlife.net/blog/2008/aug/18/path-mtu-discovery/

> > -          Greg
> 
> Regards,
> Mike

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20110314/03a1b2c4/attachment.bin