IPsec VPN Tunnel with overlapping subnets.

[cmateam]

Hi,

Has anyone setup two PAN FW point to point that connect with the same subnets on each side.  The reason for the same subnets is that we have our production network behind FW-A and a co-location network that mirrors our production network behind FW-B.  This is for disaster recovery and quick turn on of machines in the event of a disaster, etc.

I have the tunnel setup between two FWs, but I am having difficulty in getting NAT & Routing working appropriately to communicate with each other.  Unfortunately I am not at work to post screen shots of my setup at the moment, but wanted to see if someone could give some insight as to how to set this up.  I have followed the document here: - but have not had any success.  I am trying to NAT a pool of addresses to another pool on the other side. For example: Our Trust network is a 192.168.0.0/16 - I want to NAT these addresses through 10.168.0.0/16 to the other side of the tunnel and reverse the NAT to be directed to the same 192.168.0.0/16 address.

I've tried assigning IP address ranges to each tunnel, and using the NAT rule to NAT the 192.168.0.0/16 destined for 10.168.0.0/16 to a 10.250.0.0/16 translated at the source.  I think this all works, but my routes don't seem to work, and don't know what the route would be.  I tried both the 10.168.0.0/16 and the 10.250.0.0/16 destination to the tunnel interface.  Neither seem to get it working.

I tried same tunnel designators (tunnel.10) for example on the same side as well as the 10.250.0.0/16 and a 10.251.0.0/15 on both local tunnel address (FW-A), as well as on the far end tunnel (FW-B)

I can post more tomorrow, but NATing this way isn't really explained in the above document, and there really is no explanation for the 10.2.1.0/24 network in the same document, so I am unsure how that all fits into this. Also I don't understand the ike-to-gw route rule either.  I tried adding this with no luck.

Can anyone help?  I'm somewhat in need of getting this project setup and am completely confused.  I wish there was a clearer, more up to date document regarding this. Surely others are doing this as well? Thanks in advance.

[cmateam]

No one has this type of setup?

[panman]

I guess its not very clear what you are trying to accomplish with your proposed subnetting architecture.....why would you want you use overlapping subnets at Site A and Site B for a IPSec VPN? That just introduces routing complexity by introducing the NAT requirement, and then also having to resolve DNS at Site xx for the opposite Site xy to the NAT'd ranges.

It really depends on what you need the design to do. It almost sounds like you are trying to design a "mirrored" co-lo architecture, which is a bit beyond using a simple IPSec VPN for the inter-site routing. If you are planning to operate your Active Directory and VMWare infrastructure, for example, across geographically disparate datacenters then that would involve extending your Layer 2 networks using some type of routing technology like Cisco's DCI...

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_493718.html

[cmateam]

Josh,

Thanks for your response and thoughts.  The idea is to mirror our network in our primary location (Site A), to our second location (Site B).  Initially we are just replicating machines to this location using Veeam (our backup tool).  The idea would be that in the event of failure we could turn on one of the backup/replications on Site B without having to reconfigure networking information.  We would also be turning on some VM's in that location within the same IP space as well. Hope that makes a little bit more sense.

After your comments, and talking with an associate last evening about this, I'm leaning towards using a different subnet(s) for Site B just for the sake of routing/NAT overhead of management and packet data being sent over the tunnel.  I know Veeam has a great feature that you can reconfigure networking within the backup/replicate settings so if we need to turn on, on Site B, we would not have to reconfigure anything and it would automatically be registered in DNS on a domain controller at that location as an address change. 

Unfortunately I've not had much time to research this, and the little time that I've had to look, it doesn't seem there is much information as to what people are doing in this type of scenario.

Are you running anything similar to this?  I don't think the Cisco option is viable at the moment, as we are a small shop. Thanks for your response Josh.

[panman]

...well we are working on a hot site co-lo effort based on Cisco's OTV using Nexus 7000s, with 1Gig dark fiber as the co-lo circuit....so Im not sure if I can offer much advise for your type of senario. For a small shop, your DR project might be something to involve a 3rd party consultant if your business requirements need it to absolutely work.

What I can tell you from what I have concluded through budget research efforts for our company's DR model, is that basically DR sites and co-location is not a defined thing that you can grab a standard design template off a Google search and deploy it, because the business requirements in each given situation will dictate what the design will be (ei, simple data backup site, cold/warm/hot site) and how much you can spend on it. Most businesses will need to take small steps, one at a time, to reach a desired DR model.

Given that, one will probably find an industry trend that small businesses typically will limit DR efforts to doing data replication, log shipping via a IPSec VPN for example. Mostly, you will find that WAN bandwidth to a co-location/DR site will dictate what type of DR model you build out and how much a company is willing to spend on it. A DR design such as a cold site that stores replicated gigabytes of data, or maybe some backups of production VMs, will require decent bandwidth itself, with offline replication often happening during off hours depending on your technology. You'll find that an IPSec VPN will very quickly saturate for what you are trying to build out.

Any more significant design than a very basic cold site such as I described, will most likely require a dedicated WAN medium or private circuit to the co-location for feasibility of the technology involved....and once you get into purchased bandwidth/WAN circuits, whatever medium you choose to use, the coin dropped on these efforts start quickly start sky rocketing and at that point your business may as well implement a decent, [more]expensive solution. Thus, you'll find that larger business and enterprises with expensive data to protect are are the ones spending dollars on DR and co-lo cold/warm/hot sites or farming out the DR model's physical infrastructure to a cloud computing service or third party.

Hope that helps.

[cmateam]

Josh,

Thanks for your input and help in thinking through this stuff.  We decided to use separate IP ranges at Site-B to help with the design and complexities of what we are trying to do.  Especially when only a handful (if that) will be live on the other side, and all others will be replicated over the tunnel. We will reproduce our site-A network on the other side incase site-A goes away completely we can turn up replicas/backups on the otherside as if networks never changed.  Hope that make sense.  Thanks for your input.