Date: Sat, 14 Apr 2001 07:58:43 -0400 From: "David Erickson" <erickson@mddsg.com> To: <freebsd-security@freebsd.org> Subject: Re: IPSEC/VPN/NAT and filtering Message-ID: <001a01c0c4da$40f0a040$1902a8c0@mddsg.com> References: <20010321163657.D0333113CB1@netcom1.netcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I do not know about your particular situation however. I am doing NAT'd IPSec all the time to work with a Checkpoint Firewall. You just have to configure the firewall to accept NAT'd connections in v4.1 sp1 and in sp3 the support is even better. Dave ----- Original Message ----- From: "Mike Harding" <mvh@ix.netcom.com> To: <freebsd-security@freebsd.org> Sent: Wednesday, March 21, 2001 12:36 PM Subject: IPSEC/VPN/NAT and filtering > > It's possible to use IPSEC on a box with NAT, but you don't want to > NAT the ipsec tunnel. What worked for me was to create an ESP tunnel > and then route traffic to the remote net to lo0. It then gets > encapsulated and sent out the external interface. NAT is not invoked > because the traffic no longer looks like your internal network. > > IPSEC does _not_ play happy with packed filters on the same > box... here's an extract from a recent e-mail to kris... > > I would like to see all of this fixed and working, I'll write a > handbook entry and do coding as well.... > > - Mike Harding > > (extracted from a letter to kris...) > > I have seen your name on a few exchanges and you seem to be a likely > person to discuss this with. The issue is using IPSEC and ipfilter > (or ipfw) together on the same box. I think I have a relatively > simple way to deal with getting this to work properly. > > The current problem is that if you use ESP tunnel mode, or transport > mode for that matter, the KAME code rewrites the packet contents, and > then requeues the packet for further routing. See line 398 in > esp_input.c for -STABLE. It does NOT change the interface, so you > can't tell this packet from one that comes in via the hardware device. > Apparently there is a bit flipped indicating that this is a ipsec'd > packet, but the current packet filters don't appear to take advantage > of it. > > My modest proposal would be to have a sysctl variable to indicate an > alternate interface to reinject the decrypted packets (like a local > loopback, the default or maybe a new one, lo1). Then you know that > anything coming in that interface was inserted by the KAME stack and > you can apply filtering to it. This would allow firewall and IPSEC > gateway functionality to be put into the same box. > > You can use the 'gif' device for tunnelling, but we are trying to > interoperate with a cisco box (politics). There is also pipsecd, > which would work, but there is no IKE daemon for it. > > I think we will work around this by putting another packet filter in > front of the IPSEC box, but this would be very useful in general I > think... > > How does this proposal sound? I know the OpenBSD folk put some effort > into getting ipfilter and IPSEC to 'play nice'... it would be a shame > to have to use 2 boxes or switch OSes to support this. > > I am willing to write a section in the handbook on this once I have it > set up correctly, a box with NAT, VPN, and ipfilter (and alternately > IPFW). > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001a01c0c4da$40f0a040$1902a8c0>