Company A & B merged. Company A has Server Farm as 10.2.0.0/22 address space. Company B has Server Farm as 10.3.1.0/24 space. However Company B's remote Sites fall within the 10.2.0.0/22 space. Company A & B are connected using VPN tunnel. Company B's remote site use this VPN tunnel (remote site >>mpls >> company B rtr >> firewall).
Short term goal is to have Company B's remote site access A's Server Farm (traffic will only be flowing from remote sites to Servers and never in reverse).
Solution I have proposed is to have a NAT router sitting at Company A site b/w the server farm and Firewall.
1. All traffic b/w "B" Server farm and "A" server farm not Natted. All traffic between B's remote will be source NATTed to 10.100.1.0/24 space and all A's destinations will appear at these remote sites (using the NAT router) as 10.101.1.0 (Static 1 to 1 NATs). Does anyone see any issues with this setup, considering the NAT router in question will be doing static NAT as well as routing.
No i don't see any problem with what you are proposing but could you not set this nat up on the firewall rather than insert a router ?
That is easier said than done. Multiple firewall technologies including windows (dont ask) have been utilized. Objective is have users throughout this merged entity have faster access to internal resources as well as encourage consolidation. The key question here is if an interface is marked ip nat inside and another ip nat outside, could I have still have routing of NON-NATTED subnets through this router. In other words does the ip nat inside/outside command mandate that all traffic through is either natted or dropped? Thanks much!
Apologies as i didn't fully understand what you were proposing - my fault.
I think you will have problems with the static translations in that if you set up static translations all devices at the remote end would need to refer to the natted addresses.
You can do conditional NAT with route-maps but only for dynamic NAT as far as i know.
The only thing i can think of is that you need to only go through the router if you are routing to the Natted addresses. if you want to go direct to the real addresses you bypass the router. But i don't know how easy that would be with your topology.
As far as conditional NATTing is concerned, I think the following command does conditional NAT for static:
ip nat inside source static REAL VIRTUAL route-map1
ip nat inside source static REAL VIRTUAL
Let me know.
One final request regarding the same. Could you also find out about the concurrent routing i.e. static nat with route-map stating that this nat applies for only certain source and destinations (using specific deny statement first and general permit following that) and then routing b/w inside and outside b/w internal subnet and the networks in the deny statement.
Apologies for delay in replying, we had a bit of an emergency at work :)
I tested this out and it looks like you should be fine. I set up a server behind a router and did a static NAT entry for it with a route-map spsecifying the source IP addresses.
Then from one of the source IP addresses i could ping the natted address.
Then from a different source IP address that was not included in the route-map i pinged the real address and this worked also.
So from a lab environment it looks like you can do what you are proposing.
Could you explain your second query again ?
(firewall edited config attached))
In order to complete the aforementioned design, I need the PIX firewall do the following (example subnets: NYC is 10.2.0.0/22; Boston Hub: 10.1.10.0/24 & Boston Remote Sites 10.0.0.0/8 (note that Boston remotes are connected to boston hub using an internal mpls network. these remotes connect to nyc using the vpn connection b/w boston pix and nyc firewall :
NAT all traffic hitting the inside interface of the Boston PIX so that:
traffic going to NYC from Boston Hub is not natted. traffic entering the pix from any boston remote sites and destined for nyc hub is natted to 10.252.0.0/22 address space.
We have to make sure, as well, that traffic originating from NYC to 10.1.10.0 subnet should work fine.
Please take a look and let me know.