Re: IPSEC/VPN/NAT and filtering

From: Cy Schubert - ITSD Open Systems Group (
Date: 04/16/01

From: Cy Schubert - ITSD Open Systems Group <>
To: "David Erickson" <>
Date: Mon, 16 Apr 2001 11:00:58 -0700

In message <001a01c0c4da$40f0a040$>, "David Erickson"
> 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

Wouldn't that depend on whether you're using tunnel v.s. transport mode

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Internet:
Open Systems Group, ITSD, ISTA
Province of BC

> ----- Original Message -----
> From: "Mike Harding" <>
> To: <>
> 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
> > with "unsubscribe freebsd-security" in the body of the message
> >
> To Unsubscribe: send mail to
> with "unsubscribe freebsd-security" in the body of the message

To Unsubscribe: send mail to
with "unsubscribe freebsd-security" in the body of the message