Date: Thu, 10 Apr 2003 11:15:11 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: freebsd-hackers@FreeBSD.org Subject: Single IP host and IPsec tunnel mode experience Message-ID: <20030410161511.GA25681@madman.celabo.org>
next in thread | raw e-mail | index | archive | help
Hello, In relation to a project that I'm working on, I played around with configuring a host with a single public IP address using IPsec tunnel mode. To illustrate, +----------------+ | FooCorp LAN | +----------+ 10.3.14.0/24 | | +------+---------+ | | | | | eth0 10.3.14.95/24 T + u router1 (FreeBSD) n + n | eth1 223.223.223.223 e | l | l +------------+------------+ e | The Internet | d | *shudder* | | Here there be tigers | | +------------+------------+ | | | | | | eth0 173.173.173.173 | +------------+-------------+ | | server1 (FreeBSD) | +----+ World's Only Secure Host | | Really, Trust Me | +--------------------------+ When users on FooCorp LAN access `server1', the packets should be encapsulated in ESP, with no NAT funny stuff. `server1' will actually `see' packets in the 10.3.14.0/24 network. This is (apparently) easily described by these setkey policies: [NOTE: We are not using IP-in-IP encapsulation here. No gif(4) interfaces. There doesn't seem to be a way to express the same thing using gif(4) interfaces.] router1 spdadd 10.3.14.0/24 173.173.173.173 any -P out esp/tunnel/223.223.223.223-173.173.173.173/require; spdadd 173.173.173.173 10.3.14.0/24 any -P in esp/tunnel/173.173.173.173-223.223.223.223/require; server1 spdadd 10.3.14.0/24 173.173.173.173 any -P in esp/tunnel/223.223.223.223-173.173.173.173/require; spdadd 173.173.173.173 10.3.14.0/24 any -P out esp/tunnel/173.173.173.173-223.223.223.223/require; However, this does not work :-) Outbound packets are encapsulated as expected, i.e. packets leave `router1' looking like this: +----------------------------+ |IP Header | | Src: 223.223.223.223 | external IP header | Dst: 173.173.173.173 | +----------------------------+ |ESP Header | +----------------------------+ |IP Header | | Src: 10.3.14.1 | internal IP header | Dst: 173.173.173.173 | +----------------------------+ |Upper layers (TCP/UDP/...) | +----------------------------+ but they are dropped by `server1', and the `inbound packets violated process security policy' counter is incremented. If one relaxes the inbound policies given above by changing `require' to `use', then the packets are no longer dropped and everything works as (I) expected. Packets in both directions are properly encapsulated. However, `use' is not the policy desired, of course :-) The fact that `use' works, and `require' does not leads me to believe that when a packet is received and processed in tunnel mode, that the de-encapsulated packet (the internal one) is AGAIN matched against the SPD, causing the `violated process security policy'. So, KAME/IPsec experts ... have I gone atray with my configuration? Or is this simply not doable within the KAME framework? Or is this a bug (assuming my theory that packets are matched against the SPD again after de-encapsulation is correct)? Cheers, -- Jacques A. Vidrine <nectar@celabo.org> http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030410161511.GA25681>