I'm working on the Disaster Recovery (DR) network. Here is the requirement:
- The DR and Production network have same IP address; it is to simplified server configuration when disaster occurs.
- All remote is link via VPN IPSec tunnel through the Internet using PIX device at both end
- How are we going to do when remotes want access to both DR and Product networks? (Take note, Production network cannot be down)
- At the DR we are using Cisco router with FireWall+VPN IOS and all remotes use PIX.
Is it alright to create another tunnel at the remote side with the same destination IP address, if not how am I do it?
How should the routing go about? PIX is not intelligent to do complicated routing at the remote end.
I have also attached a diagram to help you to understand what the setup is like.
Thanks a lot.
One solution to this might be to present the servers in your DR site as different addresses to the remote site and then NAT then back to the correct addresses at the DR site. That way you could define a different VPN tunnel for the DR site.
We know that by providing a different network IP range is the easy way to resolve this issue. However, restoring back the Applications to the original respective servers just like Product state will be most easy for my application team. This is because of the hard coded application and some un-forecast issue that may arise.
That why we need to have the same IP address at two different sites.
The other way is to do it manually, e.g. remove the VPN IPsec tunnel for one remote site connect to Production site and re-configure the VPN IPsec tunnel connects to DR site. Then repeat this to all the remote sites. But this will impact the live operation to the Production site.
Thanks and regards,
I may not have explained myself very well, apologies.
I wasn't suggesting you change the server IP addresses in your DR site. You can leave them with the same addresses as you have in production and then if you need DR you can simply switch across.
But i'm also assuming that while production is up and running only your application team would need to get to the servers and not your user base. If this is the case you can present the servers in your DR as different address to your app teams so they can access the servers whilst production is still up and running.
Have i misunderstood your requirements ?
Sorry I may not have explained myself very well on this, my apologies.
We need both (Production and DR) to run concurrently, is there a way for this to work?
Remote users at DR Vlan will only access to DR and remote users at other Vlan will only access to Production site.
Thanks and regards,
I think i understand now and if so it should be relatively straightforward. To be able to build 2 separate VPN tunnels you need to be able to distinguish on something unique. The destination IP addresses are the same but the source IP addresses are not so this would do ie.
access-list 101 permit ip 192.168.200.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list 102 permit IP 192.168.201.0 255.255.255.0 192.168.1.0 255.255.255.0
Use the above access-lists as your crypto map access-lists and then the remote pix will be able to distinguish between the 2.
Note, if you are natting the source IP addreses of 192.168.200.0/24 and 192.168.201.0/24 to the same source IP you would need to have 2 separate IP addresses so you can distinguish between them in your crypto maps.
Does this make sense ?
Why don't you try to use IPSEC/GRE tunnel with your routers then implement dynamic routing. Something like EIGRP. Set a higher delay on the GRE tunnel that faces the DR site so all traffic will go to the primary site. When the tunnel fails, the EIGRP route will disappear as well then traffic will be routed to the DR site. I don't know if I'm getting it correctly.
Oh please disregard my suggestion. I misunderstood the situation. LOL
Jon's suggestion is pretty cool.
That is cool. I will try this
Btw will the remote PIX allow me to create 2 VPN IPSec tunnels and both distination IP address are the same?
Thanks and regards,
Yes it will as long as your source IP addresses are different and in this case they are.