Date: Thu, 30 Nov 2000 07:00:09 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: itojun@iijlab.net Cc: Dominick LaTrappe <seraf@2600.COM>, freebsd-net@freebsd.org, 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: <200011301500.eAUF0Ol40955@cwsys.cwsent.com> In-Reply-To: Your message of "Thu, 30 Nov 2000 15:40:09 %2B0900." <20718.975566409@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20718.975566409@coconut.itojun.org>, itojun@iijlab.net writes: > >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! ;-) > > basically, the problem is not that simple. > - relationship between packet filters and tunelling > some people would like to filter before decapsulation, > some would like to do it after decapsulation > - relationship between filters and encryption/authentication > ditto. some wants to filter before decryption, > some wants to filter after decryption. > - NAT and filters > - NAT and IPsec > they are fundamentally unfriendly, I believe. > > there are couple of ways to make it better: > - enhance packet filters so that we can differentiate between multiple > filtering points (make it possible to specify "this filter should > be applied here"). > - integrate all packet-filter-like mechanism into one. make ipsec > processing invoked via packet filter. this still leaves question > regarding to NAT and some other mechanisms. Could we just borrow a something from the pipsecd model? Pipsecd uses a tun device to present itself to system. A network that is associated via a pipsecd IPSec tunnel is defined in the routing table to route packets through the tun interface. Once packets enter the tun interface pipsecd encapsulates them and spits them out through the external interface. Packets coming back in go in reverse order. E.g., tun0 input ----> IPNAT/IPF/IPFW (out on tun0) ----> tun0 output ----> pipsecd ----> xl0 input ----> IPNAT/IPF/IPFW (out on xl0) ----> xl0 output ----> Internet ----> xl0 input ----> IPNAT/IPF/IPFW (in on xl0) ----> xl0 output ----> pipsecd ----> tun0 input ----> IPNAT/IPF/IPFW (in on tun0) ----> tun0 output Now all I need to do is add entries to my routing table defining the remote pipsecd gateway as a router for packets destined for a the specified networks. In the above example I perform NAT to translate my ARPA addresses at home not only to the outside world but also to my pipsecd gateway at work, so packets destined for my employers network get encapsulated and are NATted twice. NAT works in this double NAT situation, however IP Filter's FTP proxy does not, but considering what the packets have to go through to get there I'm happy without the FTP proxy in this case. I have placed my network at home directly on my employers network at one time using an IP alias on my pipsecd/NAT box at work with an IP Filter bimap, however I got all of the broadcasts from my employers routers as well. Without the bimap my network at home is further insulated from my employer's network mitigating my personal exposure in case of anything unfortunate happening there. My point being that what I've described above is extremely flexible. All in all, this approach has been quite successful for me. > > again, there's no clear solution. some change may make you happy > while it makes others unhappy. > > itojun@kame I suppose a simple IP over IP tunnel over the IPSec tunnel implemented using ip-tun from the ports collection might add the extra interface on which to build another packet filter on, similar to the pipsecd approach I described above. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC 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?200011301500.eAUF0Ol40955>