IPSec, nat on enc device

Bjoern A. Zeeb bz at FreeBSD.org
Tue Oct 20 18:00:08 UTC 2009


On Tue, 20 Oct 2009, Eric Masson wrote:

Good evening,

> vanhu <vanhu at FreeBSD.org> writes:
>
> 'Lut Yvan,
>
>> Another way to have this feature is to implement what we call "NAT
>> before VPN": you can configure your kernel (or do it for specific NAT
>> rules if you want to do a more flexible implementation) to do NAT
>> process before doing IPsec stuff.
>
> I've used it last week on a 8.0.2 F200. The major drawback is that an
> existing nat ruleset must be adapted (nomap rules for vpn networks that
> dont need nat) and that it can cause issues when activated
> (a reverse proxy located on a machine behind a bidirectionnal map woes
> when nat before vpn is activated, that's why I have to setup another box
> for natted vpns...)
>
>> OpenBSD's way of doing things seems interesting while reading very
>> quickly your link, I'll have to take some more time to really see
>> exactly what they are doing.....
>
> I agree with Ermal that duplicating nat information in pf and isakmpd is
> suboptimal and probably error-prone, but it seems to me that it's less
> intrusive than altering the ip stack.

I only had a quick look at the commit message being on the road.

I think Open seems to move further and further in the direction to be
an operating system around pf, rather than pf being a firewall
implementation for the OS, in some areas.  That kind of worries me -
also for further code sharing wrt to pf(4).

What I said before and will repeat is that if you want to use NAT and
VPN you want to do inside NAT (addmittingly handling the local machine
is a different story). I have done that years ago with ipfw. Then your
SA works on the NAT IP. I used it to avoid formerly RFC1918 address
collisions by NATing to an unrouted public IP for just the VPNs.
THe NAT IP will not be bound to any interface at all.

There is a reason major vendors have been doing inside and outside NAT
for ages now.  That pf cannot do that is bad and a design problem there.
The "commit Theo calls me insane for"  moves into the direction of
fixing that but when I talked to OpenBSD people at EuroBSDCon they said
something along the lines of "it's not entirely there yet and still
disabled because there are a few things that would work entirely as
expected".

There is abosultely no need to change the IP stack to accomplish that.


If you want to do it with pf + enc + NAT you can actually do that even
without patches but a bad ugly not to publish hack, that you will most
likely only want to do if you control all endpoints:
you add two policies: one with your internal network and one with your
NAT IP on both sides. racoon , configured correctly, will negotiate the
SA and share it for the tunnel endpoints for both policies.
The remote destination will never see a packet with a src of your
internal IPs but it will have a policy for it - else negotiation would
fail.  You may need to assure that no packets travel your way with the
1st, internal, policy in the firewall.

What I see with the OpenBSD change is that their hack does nothing but
get rid of the 1st policy for the internal network on the peer. Not
sure if they still need it locally or if they hacked the stack for
that; from what I see FreeBSD would have to do that.

/bz

-- 
Bjoern A. Zeeb         It will not break if you know what you are doing.


More information about the freebsd-net mailing list