Date: Fri, 30 Jul 2004 18:06:45 +1000 From: "Peter Sandilands" <peter@sandilands.vu> To: "Nickolay A. Kritsky" <nkritsky@star-sw.com>, <freebsd-net@freebsd.org> Subject: RE: ipsec packet filtering Message-ID: <IOEHIPOKAPPDDMNJNKKGCEPPCFAA.peter@sandilands.vu> In-Reply-To: <652582171.20040730075831@star-sw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?IOEHIPOKAPPDDMNJNKKGCEPPCFAA.peter>