[Openswan Users] Where did routes go with Openswan 2.6.31?
Michael H. Warfield
mhw at WittsEnd.com
Mon Mar 14 11:37:27 EDT 2011
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
> 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
> > - Greg
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
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/users/attachments/20110314/03a1b2c4/attachment.bin
More information about the Users