PfSense IPSec with overlapping networks



  • I have to connect two networks that overlap. So I have 192.168.1.0/24 networks on both sides of a IPSec VPN that need to be able to communicate.

    Some will say: change the addressing on one of the sides. Well, yes, I know that will do it; that will be the easy way but let us suppose that I can't. So we still are at the beginning: can this get done?

    On my side (call it Side A) I have pfSense 2.1 and on the remote side (call it Side B) I have a cisco router. I have already used the new NAT/BINAT option of pf 2.1 and it works beatifully.

    Just to make a test I have setup a lab where the local (Site A) addressing scheme is not overlapping like 192.168.0.0/24 and configured BINAT over 10.1.1.0/24 in pfSense. Traffic from this LAB site A looks, from Side's B point of view, as if it were coming from 10.1.1.0/24. I can ping from LAB side A to any host of side B (ping 192.168.1.1 for example) and it works; pfSense new NAT before IPSec does its job and translales my local 192.168.0.x->10.1.1.1->192.168.1.1. Site B receives traffic from 10.1.1.1 NOT from 192.168.0.1. So far so good.

    The counter is also true, I can ping from side B to a host in LAB side A (ping 10.1.1.1 for example) and I get replies. BINAT now does the opposite 192.168.1.1->10.1.1.1->192.168.0.1.

    So I already have half of the job done. But to be able to use this with the original 192.168.1.x network I need that traffic received from Side B be 'source translated' so that it looks like it is coming from a diferent (non overlapping) network, say 10.1.90.0/24. This could be achieved by modifiying Site B cisco router configuration adding a simple outbound nat but, sadly, I cannot modify anything there.

    So I need a mecanism in pfSense to convert the SOURCE address of the traffic from 192.168.1.x to 10.1.90.x and here is where I stop: I do not know how to do this.

    The state map of such a conversion when pinging 10.1.1.1 from the corresponding host in Side B should be (for traffic sent by site B and entering the pfSense system) as follow:

    192.168.1.1(address of site B sending host)->10.1.90.1(translated address for site B host)->10.1.1.1->192.168.1.1

    This means that pfSense must receive the IPSec traffic from 192.168.1.1 to 10.1.1.1, deNAT it with BINAT to 192.168.1.1 (leaving a 192.168.1.1->192.168.1.1 packet?) and then some other NAT enter in the game and change the problematic source address into the new one thus having a final packet from 10.1.90.1->192.168.1.1.

    As we can see if this 'secondary' NAT enter the game AFTER the IPSec BINAT we will have a temporary packet from 192.168.1.1 to 192.168.1.1 so this may pose a big issue and may lend it undeliverable. To avoid this the source nat change should occur before the binat happen so that the incoming traffic to 10.1.1.1 should get converted from 192.168.1.1->10.1.90.1 and then the binat mecanism do its job.

    Has anyone tried/done this? Can this be done with the lastest pfSense version?

    Thanks to all for reading so far.

    Regards.



  • Nobody?


  • Rebel Alliance Developer Netgate

    The NAT must be done on the client side before it leaves. The other router can never see the address.

    In the case of the LANs overlapping, both sides must do the NAT so they appear to be on different subnets. You can't do all of the NAT on one side in both directions.

    Save yourself a ton of time and headaches, just bite the bullet and renumber the side you have more control of now.



  • Hi jimp. Thanks for taking the time to write an answer. It is a big tap in the back to get someone reply. :D

    This document http://www.cisco.com/en/US/products/ps5855/products_configuration_example09186a0080a0ece4.shtml shows that, in the cisco world, this can be done. I was hoping that in the pfSense world this could be done too. It is a matter of playing with the inside and outside addresses. With the new enhancement of version 2.1 we manage the inside part of the packet. Now we need to, somehow, manage the outside part to close the circle.

    I hoped that the 1:1 nat will do the job but I am afraid that it is not designed for that function or I am not fully understading how it works but my tries with it have failed miserably. I suppose it all depends on the order of operation of the full chain of routing, natting, cyphering and so on. If there were a place to hook on that nat substitution may we be able to get on it.

    Sometimes changing IP addressing is not an option. It would be great if the gurus that fully understand how pfSense work would shed some light on this and may they could find a way to achieve this because there are many cases where you get overlapping networks.

    Looks like not this time anyway.

    Thanks for your time.



  • Hi Jim,

    On page 433 in the IPsec chapter of the 2.1 draft document, it says "if [the network option] is unchecked, the clients will attempt to send all of their traffic, including Internet traffic, across the tunnel".

    Assuming I am ok handling the Internet traffic, wouldn't this bypass any conflicting ip address issues as described in this thread?

    –jason

    @jimp:

    The NAT must be done on the client side before it leaves. The other router can never see the address.

    In the case of the LANs overlapping, both sides must do the NAT so they appear to be on different subnets. You can't do all of the NAT on one side in both directions.

    Save yourself a ton of time and headaches, just bite the bullet and renumber the side you have more control of now.


Log in to reply