Date: Wed, 21 Mar 2001 08:36:57 -0800 (PST) From: Mike Harding <mvh@ix.netcom.com> To: freebsd-security@freebsd.org Subject: IPSEC/VPN/NAT and filtering Message-ID: <20010321163657.D0333113CB1@netcom1.netcom.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010321163657.D0333113CB1>