No, unfortunately not. It is a long-standing issue with pf and FreeBSD and it seems that the only way to solve it would be for FreeBSD to "fork" pf and add "inside NAT" to pf.
NAT before IPsec on FreeBSD:
Need of ipsec vpns beetween RFC1918 colliding networks is pretty usual these days, so has anyone considered working
in this area ?
On Mon, Oct 19, 2009 at 9:18 AM, Eric Masson wrote:
> OpenBSD has support for this kind of setup since last January :
>
http://undeadly.org/cgi?action=article&sid=20090127205841> The commit :
>
http://marc.info/?l=openbsd-cvs&m=123246256228242&w=2>
> >From what I've understood, pf, depending on version in FreeBSD, could
> already support natting on enc interfaces.
>
> The missing part seems to be laying at the IKE daemon level.
I think you should send this email to ipsec-tool mailing list!
Basically the daemon should be modified for this and FreeBSD
is not the owner of such code.
AFAIK, there is not limitation to allow this in the IPSec stack.
So it is purely a daemon perspective to instrument the stack for this.
---------------------------------------------
> I'm not sure that pf & ipsec stack already support this feature. Maybe
> bz@ or vanhu@ will shed a light on this point.
This is a way to do that, but it needs some stuff on both kernel and
userland to be implemented that way.
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.
Then, you just write your NAT rules to move local/remote traffic
endpoints to distinct networks, and IPsec (both in kernel and
userland) will just have to deal with those NATed networks.
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.....
---------------------------------------------
> 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.....
Basically they make aware the daemon and the firewall of the nat.
Actually it is more 'user-friendly' to configure though clumsy since you have
to do keep the same information in two places, firewall nat rules and the ipsec
daemon.
You just tell instrument the daemon to inject one 'normal'(out) SA's
match traffic coming from your local network and one SA for incoming
traffic from remote network with the natted network address.
This all is because pf(4) cannot do 'incoming nat' by default.
---------------------------------------------
> 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.
---------------------------------------------
Bjoern A. Zeeb-2
Oct 20, 2009; 9:00pm
Re: IPSec, nat on enc device
On Tue, 20 Oct 2009, Eric Masson wrote:
> vanhu <[hidden email]> 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.
... [show rest of quote]
I only had a quick look at the commit message being on the road.
I think OpenBSD 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 (admittingly 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
pfSense Forum
