PIX 6.33: Overlapping subnets through VPN

[sghezzi]

Hello,

we have the following problem:
we are using PIX 6.33 to handle many VPNs with different remote sites. All these remote sites need to access to our internal LAN 192.168.160.0, traffic comes inbound.

The problem is that one of these remote sites has also 192.168.160.0 as their internal network, and they cannot apply any NAt on their site because this would impact all their Intranet traffic (they have only a main router which takes care of the intranet and of the VPN with us).

Therefore they will use a different destination IP for their traffic to us, let's say 172.31.250.0.

It is up to us on PIx then to translate this traffic back to 192.168.160.0.

How can we do that without having impact on the traffic related to the other VPNs?

Please help!!!!!

thanks a lot
Silvia

 

[308win]

You need to change the IP addressing scheme in the remote office. (Or your's, whichever is easier.) You will never get traffic to route between 2 physically separate LAN segements with the same IP subnet. (Bridging is a different story.)

Brian

 

[chicocouk]

I have an outstanding call with TAC that is now being raised as a bug issue for the developers to address. It is actually possible to use the pix to nat incoming vpn traffic, either the source or destination address. You do this using bidirectional nat. Unfortunately as this currently stands you have to do it using policy nat. There are two issues with this. Policy nat and static nat do not coexist happily on a pix, so if you have any incoming static nat translations, wave them goodbye. This is a recognised bug (i have the cisco error number at work), but there is a more pertinent bug which also destroys these incoming connections even if you use policy nat rather than static translations for incoming traffic.

This is a really complicated thing to try to explain in a short post, i've been working on this problem for several months, but have a good contact now at TAC who has labbed it up and confirmed what we'd discovered as a problem.

So, in other words, watch this space. It's not currently possible to do what you want to do, but as soon as i get info about how to sort it, i'll post a FAQ about it. I would expect a cisco doc to appear around that time too, as it's not the easiest thing to figure out ...




CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[dopehead]

Just curious, if the remote site can't use nat how do they reach the internet in general with their 192.168.160.0 addresses ? they must be running nat already, i think they are just jerking you around to make you comply with their setup. Also, many ppl having different partners require the use of official ip's to avoid this exact scenario.

Jan

Network Systems Engineer
CCNA/CQS/CCSP

 

[chicocouk]

It depends what the router is really, doesn't it? Some routers can't handle nat-ing then passing traffic down a vpn. Larger cisco routers can handle it, for instance, using VRF-aware IpSec, but smaller routers which can deal with VPNS (such as the 800 series) don't support that feature. If it's another manufacturer it's quite plausible that the router simply doesn't support NAT-ing in conjunction with routing that NAT-ed traffic down the vpn.

I'm not sure I undestood the part about official ips, but i'm curious to hear what that would be?

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[sghezzi]

In reply to dopehead: they can reach 192.168.160.0 only through the VPN that is established by the two peers using their public IPs.

In reply to chicocouk: policy NAt combined with static NAt was exactly what I wanted to use but I had no experience with that yet....that's why I was asking help.
So you suggest not to use it at the moment due to this bug....
So, I will have to find a way to do a NAT using an additional router at the remote site.

Thanks anyway!

 

[ststokes]

You can also attempt to use the following document to help get this working. I have used it and it did work just fine.

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800949f1.shtml

Scott
CCNA, CCSE, CCSP, ISS-CE

 

[sghezzi]

Yes, I already read it, but the problem I see is that "static" command is not applicable to a specific access-list, it will interfere also on other VPNs.

it is not like the global command that can be applied to access-list through NAt/

Silvia