Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Nov 2000 01:17:56 -0500 (EST)
From:      Dominick LaTrappe <seraf@2600.COM>
To:        freebsd-net@freebsd.org
Cc:        Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Gerhard Sittig <Gerhard.Sittig@gmx.net>
Subject:   Re: filtering ipsec traffic (fwd)
Message-ID:  <Pine.NEB.4.21.0011292359200.29728-100000@phalse.2600.com>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.4.21.0011292359200.29728-100000>