From owner-freebsd-net Wed Nov 29 22:18: 0 2000 Delivered-To: freebsd-net@freebsd.org Received: from phalse.2600.com (phalse.2600.COM [216.66.24.2]) by hub.freebsd.org (Postfix) with ESMTP id CEC7837B402 for ; Wed, 29 Nov 2000 22:17:57 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by phalse.2600.com (8.8.8/8.8.8) with ESMTP id BAA00198; Thu, 30 Nov 2000 01:17:56 -0500 (EST) Date: Thu, 30 Nov 2000 01:17:56 -0500 (EST) From: Dominick LaTrappe To: freebsd-net@freebsd.org Cc: Cy Schubert - ITSD Open Systems Group , Gerhard Sittig Subject: Re: filtering ipsec traffic (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm moving this thread from freebsd-security to freebsd-net, because this is where it belongs. Rather than forwarding a message, I'm going to re-state what we've been talking about as succinctly as possible. With KAME IPsec in transport mode, and packet filtering (ipfilter or ipfw), on FreeBSD 4, packets seem to be processed like: INPUT -> filters -> ipsec -> rest of ip stack rest of ipstack -> ipsec -> filters -> OUTPUT In this configuration, the transport-layer protocol appears to the filters as ESP(50) or AH(51). As such, the filters perform no inspection of the underlying transport's parameters -- such as TCP port or ICMP message type -- because they are encrypted, and/or because they are 'hidden' behind the AH header. This is a significant limitation. IIRC, the OpenBSD and FreeS/WAN implementations of IPsec present the same limitation to outside packet filters (ipfilter or ipchains), but compensate with their own packet-filtering options, which apply to a pre-IPsec'd (outbound) or de-IPsec'd (inbound) packet. KAME provides no such packet filtering. The only solution right now is to make each packet pass through two interfaces, once in its IPsec'd state, and once not, and perform packet filtering on both. This is natural with pipsecd or KAME tunnel mode, but not in KAME transport mode. The order of packet processing cannot just be changed to fix this, because NAT is part of filtering, and NAT has to happen before IPsec (other reasons anyone?). Perhaps two passes of packet filtering (pre-IPsec and post-IPsec) are appropriate as an option...? Or perhaps KAME transport mode just has this inherent limitation...? Help! ;-) ||| Dominick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message