NAT over IPSec VPN



  • I have done this on some other firewalls (Sonicwall, Netscreen, Cisco) but wanted to know if this could be done with PFSense. Basically , I want to do an edge-edge VPN but NAT not route the traffic. The reason I want to NAT is because some of the sites may have the same IP range and I do not have control of those networks. We are setting up an RDP cluster for a handful of companies that need access to our system via RDP and only ours. So I just need like a hub/spoke type VPN to allow incoming RDP (3389) traffic from the tunnel. However, if the clients networks overlap I will have an issue with routing obviously.

    I couldnt find anything pertaining to it specifically, I was thinking I could test it with the Advanced NAT outbound option , and thought I would ask here while I went off and tried to test myself.

    Thanks



  • For now that’s only possible if you separate the NAT and IPsec to two separate systems, which a lot of people do. One system can do NAT, another IPsec. The underlying OS can’t support anything else.





  • Apparently NAT before IPsec works with pf+OpenBSD and (iirc) ipfw+FreeBSD, but not pf+FreeBSD, hence the problem with pfSense …



  • just came across this entry: http://blog.pfsense.org/?p=592

    does this mean we could get nat over ipsec?



  • @miloman:

    just came across this entry: http://blog.pfsense.org/?p=592

    does this mean we could get nat over ipsec?

    no.



  • @miloman:

    just came across this entry: http://blog.pfsense.org/?p=592
    does this mean we could get nat over ipsec?

    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.

    Here is the gist, from an old (2009) discussion on this subject:

    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



  • @cmb:

    For now that’s only possible if you separate the NAT and IPsec to two separate systems, which a lot of people do. One system can do NAT, another IPsec. The underlying OS can’t support anything else.

    Could anyone explain to me how this works?



  • Does anyone know of another open source firewall that can do this?  I know Endian can(that is what I’m currently using to make this work), but honestly I can’t stand it so I’m looking for a different one.

    Also if anyone is curious, my idea is to use pfsense as my main firewall then setup endian or something else as a virtual server to handle the nat and ipsec.  So in pfsense I will have a static route for the vpn endpoint route to the endian firewall which will then nat the traffic and send over the vpn.  This way I don’t have to add any extra hardware or interfaces in my current setup.(if that made sense, it is more difficult to explain than I thought)



  • My idea did not work, endian doesn’t play nice when it’s not the main firewall.


Locked
 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy