From owner-freebsd-net@FreeBSD.ORG Fri Jul 30 08:07:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A437516A4CE for ; Fri, 30 Jul 2004 08:07:06 +0000 (GMT) Received: from gizmo07ps.bigpond.com (gizmo07ps.bigpond.com [144.140.71.42]) by mx1.FreeBSD.org (Postfix) with SMTP id EC22843D31 for ; Fri, 30 Jul 2004 08:07:03 +0000 (GMT) (envelope-from peter@sandilands.vu) Received: (qmail 12562 invoked from network); 30 Jul 2004 08:07:02 -0000 Received: from unknown (HELO psmam06.bigpond.com) (144.135.25.84) by gizmo07ps.bigpond.com with SMTP; 30 Jul 2004 08:07:02 -0000 Received: from cpe-144-136-114-229.nsw.bigpond.net.au ([144.136.114.229]) by psmam06.bigpond.com(MAM REL_3_4_2a 116/18174712) with SMTP id 18174712; Fri, 30 Jul 2004 18:07:02 +1000 From: "Peter Sandilands" To: "Nickolay A. Kritsky" , Date: Fri, 30 Jul 2004 18:06:45 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <652582171.20040730075831@star-sw.com> Subject: RE: ipsec packet filtering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: peter@sandilands.vu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2004 08:07:06 -0000 > From searching the archives this looks like an old issue, but I > still can't understand something. > AFAIU, now the ipfw + ipsec interoperation looks like this: > input: encrypted packet comes to system. It is not checked against > ipfw rules. Rules are applied to decrypted payload packet. Not true. Encrypted packet is passed thru IPFW an an ESP packet. It is then not processed any further by IPFW > output: packet is going to leave the system encrypted by > ipsec. The > packet itself is not checked by firewall, but, after > encryption, the > resulting ESP packet is run against ipfw rules. Correct. But it can be checked on the way into the gateway - on the inbound i/f > I am sorry, but I still cannot understand the reasons for such > strange, ugly behaviour. Does anybody knows the reasons > for that and what chances are that we ever get fully-functional ipfw code > checking _every_ packet on the stack. The default action is to assume that packets arriving thru a tunnel are trusted. But by adding the following option to the kernel conf file you can get the processing path I think you are asking for?? options IPSEC_FILTERGIF (documented in LINT) This then causes the decrypted packet to be passed thru IPFW again. Be aware this has significant consequences for where you do NAT in the ruleset and requires very careful crafting of the IPFW rules Pete