From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 09:15:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E707237B401 for ; Thu, 10 Apr 2003 09:15:13 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D05D243F85 for ; Thu, 10 Apr 2003 09:15:12 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 5BFE8A2 for ; Thu, 10 Apr 2003 11:15:12 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id AA31678C43; Thu, 10 Apr 2003 11:15:11 -0500 (CDT) Date: Thu, 10 Apr 2003 11:15:11 -0500 From: "Jacques A. Vidrine" To: freebsd-hackers@FreeBSD.org Message-ID: <20030410161511.GA25681@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 Subject: Single IP host and IPsec tunnel mode experience X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2003 16:15:14 -0000 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 http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se