Date: Fri, 26 Oct 2001 08:37:37 -0700 (PDT) From: Mike Harding <mvh@ix.netcom.com> To: vita@fio.cz Cc: stable@freebsd.org Subject: Re: IPFW/IPSEC/NAT interaction issues with 4.4, Bug ??? Message-ID: <20011026153737.34F4513456@netcom1.netcom.com> In-Reply-To: <XFMail.20011026124838.vita@fio.cz> References: <XFMail.20011026124838.vita@fio.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
I think unfortunately that there isn't a good approach to integrated NAT/IPSEC/IPF(W) because the IPSEC isn't really integrated with the firewall/nat. You could, however, do a mutant version of NATD that worked on the inside interface fairly easily I think... NATing the traffic on the inside interface. We have to solve the same problem ourselves, I would be interested in a working and documented way to get NAT, IPSEC and IPF(W) all playing together nicely. In the short term it is probably easier to add a separate NAT box/router. The ideal scenario would be Internet -> NAT(1) -> IPF(1) -> ipsec -> NAT(2) -> IPF(2) -> inside and inside -> IPF(1)-> NAT(1) -> ipsec -> IPF(2) -> NAT(2) -> Internet but I think that NAT(2), IPF(2) doesn't exist (packet is just accepted, skipping NAT) for input, and IPF(1), NAT(1) don't exist for output.. I think that the actual output goes inside -> ipsec -> IPF -> NAT -> Internet so you can't NAT before ipsec. Note that this is a just a quick look - I haven't heavily analyzed the stack to make sure that this is 100. My proposal was to use 'virtual' interfaces to allow multiple NAT/IPF passes, where you reinject the ipsec output somewhere else, but somebody from KAME really disliked this. - Mike H. X-Envelope-From: vita@fio.cz X-Priority: 3 (Normal) Date: Fri, 26 Oct 2001 12:48:38 +0200 (CEST) Organization: FIO holding From: vita@fio.cz X-SpamBouncer: 1.4 (8/24/01) X-SBClass: OK On 26-Oct-2001 Mike Harding wrote: > > This is a feature - if you don't do this, you can't tell decapsulated > traffic from raw traffic. That was the old config. If you have a > router, you can filter on the inside interface. I suggested inserting > the traffic on a fake interface so you could do more interesting > things like NAT, better filtering, etc, but some KAME folk seemed to > get very upset about this, although I couldn't follow the reasoning... > > - Mike H. Do you mean that "because firewall can't tell decapsulated traffic from raw traffic, firewall is skipped for decapsulated packets" ? Yes, I can filter on the inside interface, but what about NAT? natd must run on the outside interface. I see only one solution for my configuration - skip nat divert for packets outgoing from 10/8 net and they should be esp ecapsulated and configure the opposite host to process packets going back with a 10.x.x.x destination address some way. But if I want to communnicate by esp with a host which I can't configure I'm lost because it will not like my packets from 10/8 net. vita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011026153737.34F4513456>