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

[Michael H. Warfield]

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.

> -          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/3c0892e2/attachment.bin