On 2009-09-19, Joachim Schipper <[email protected]> wrote: > On Sat, Sep 19, 2009 at 05:52:29PM +0200, Toni Mueller wrote: >> Hi, >> >> thank you for your answer! >> >> On Sat, 19.09.2009 at 12:11:43 +0000, Stuart Henderson >> <[email protected]> wrote: >> > SADB entries are not normal routing table entries, they take priority. >> >> This is what I suspected. But even given those IPSEC semantics (they >> are documented where, please?), the 172.22/16 network lies on the LAN
rfc2401 5.1.1 is probably the most relevant, rfc3884 touches on it a bit. >> and not on the WAN side of things. I also don't see how traffic from >> different locations would be able to reach the LAN, if it weren't, and, providing there's _some_ route for the traffic so it can be passed up he stack towards ipsec, the normal IP routing table, including connected interfaces, is absolutely irrelevant, you have to completely forget about it for any traffic which matches an SADB entry. >> most confusingly, although I forgot to mention this in my earlier >> posts, DHCP works. I can make the gateway a DHCP server, and it can >> deal out leases to the LAN, but it cannot answer a ping, nor an NTP or >> DNS packet. This leads to the idea that the operating system already >> knows how to route packets correctly, and therefore, I suspected the >> observed behaviour to be a bug. > > All of this is not surprising. If the "IPsec route" (SA flow) overrides > normal routing table stuff, as Stuart pointed out, the "LAN side" > doesn't mean anything - the IPsec route 0.0.0.0/0 matches your traffic, > so it goes through the tunnel. (If it didn't match, the normal routing > table would be consulted next, and it would properly use the LAN > interface.) > > DHCP uses raw sockets, and bypasses all routing tables. yes, exactly.
