Date: Mon, 29 Oct 2001 14:57:08 +0100 (CET) From: vita@fio.cz To: stable@freebsd.org Subject: Re: IPFW/IPSEC/NAT interaction issues with 4.4, Bug ??? Message-ID: <XFMail.20011029145603.vita@fio.cz> In-Reply-To: <20011026153737.34F4513456@netcom1.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26-Oct-2001 Mike Harding wrote: > > 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. In previous versions IPFW/NAT/IPSEC worked fine together. Does anybody know why these changes were made and can explain this concept? > 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. I'm not sure - dst address of packet which should be deNATed is address of gateway - such packet never reaches 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. There is a way how to call NAT before ipsec: when packet before NAT doesn't match ipsec policy for encapsulation. In this case scenario is first call of ip_output ipsec(packet not changed) -> firewall -> NAT ( implies second call of ip_output ) second call of ip_output ipsec (packet is encapsulated) -> firewall -> internet so I can do what I need - send packet from 10/8 net, NAT it and then encapsulate by ipsec. But answer is lost on gateway because decapsulated packet is not deNATed. BTW current output scenario implies that packet can by encapsulated several times if DIVERT, TEE or DUMMYNET is used on output interface. Is it OK? Or using of these features with IPSEC is bad confgiuration? 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?XFMail.20011029145603.vita>