Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member


Need some guidance on how best to configure the following scenario;

Establishing VPN tunnel between my company and a business partner. They have one network on their side 192.168.53.x and we have many on our side, but none are in conflict with this address space. The challenge I have is that our inside networks were set-up in registered space (129.1.x.x etc...) and clearly the business partner shouldn't have to set routes on their side to these illegal addresses. The VPN tunnel is terminating on the outside of our PIX. Since I currently only have a couple of users that need access I configured an additional DMZ segment off of the PIX at 10.250.80.x and have moved the users to that segment. The business partner only needs to know that new address range and everything seems to work. My problem is the scalabiltiy of the solution. Soon I will need more users and I know this band-aid will not scale. How can I get my internal networks to be able to access the tunnel? Ideally I'd like the business partner to only have to know the 10.250.80.x network.

Any thoughts would be helpful. I've tried a number of things, but with no success.

Using PIX-515 w/ 4 FE interfaces and FOS version 6.2(2). I plan to upgrade to 6.3(2) this week.

Cisco Employee


You should be able to do this with the policy-based NAT feature in 6.3(2) code. This allows you to NAt certain traffic based not only on source adress but on dest address as well. You can NAT all your traffic that's going over the VPN to the 10.250.80.x network and NAT it as normal if it's destined for the Internet. Something like the following should work (haven't tested it though):

access-list natvpn permit ip any

nat (inside) 50 access-list natvpn

global (outside) 50

access-list crypto permit ip

nat (inside) 0 access-list crypto

crypto map mymap 10 ipsec-isakmp

crypto map mymap 10 set peer

crypto map mymap 10 match address crypto

crypto map mymap 10 set transform-set myset

Since NAT happens BEFORE encryption within a PIX, you NAT the traffic first based on the fact that it's destined for the remote partner network (that's the first set of 3 lines above).

You then set up your encryption ACL based on the already-NAT'd traffic, so anything coming from the NAt pool going to the partner subnet will be encrypted and sent over the tunnel. Note here, you may or may not need the "nat 0 acess-list" statement I included, you could try it without it first cause I don't think it's necessary. It shouldn't hurt either way though if it's in there or not.

With this config of course all your users need to be on the inside segment, not the DMZ, but that'll be more scalable for you in the long run as you requested. If you want to test it with users on the DMZ first then just add the following:

nat (dmz) 50 access-list natvpn

New Member


I was able to upgrade to 6.3(2), but the ideas above didn't work for me. Once set-up I turned on "debug icmp trace" and tried to ping from an inside machine to the partner network. It basically gave me an echo-request from the original inside address to the partner address without translation. I also noticed that when I do a "show access-list natvpn" it shows (hitcnt=0) which tells me that my traffic must not be interesting enough...

I do have static translations set-up on the PIX, but none that should be impacting this configuration.

I also have a "nat (inside) 10 0 0". Could this be interfering?

Any thoughts would be great.

Cisco Employee


Your current "nat (inside) 10 0 0" statement is probably taking precedence over the new NAT command. I must admit I haven't played around with the order of preference of the new policy NAT at all.

what you can try is changing your current:

> nat (inside) 10 0 0

> global (outside) 10 .....


> nat (inside) 51 access-list Internet

> access-list Internet permit ip any

> global (outside) 51 ......

and then the natvpn ACL should be looked at first, and when there's no matches in that it'll look at the Internet ACL and NAT it accordingly.

New Member


I had tried changing the order of the NAT id without luck. I'm going to try removing the 10.250.80.x segment all together and see if I can get any insight into the problem.

If I don't have a DMZ segment on the 10.250.80.x network will I still be able to create a "global (outside) 50"? Or do I have to have the segment in order to do the translation?

New Member


Success! I didn't end up needing to disable the interface. I was testing primarily using PING and since I didn't see a translation I assumed that was the problem since PIX translates first then looks for permissions. It turns out that I didn't have ICMP permitted for my inside host. It was a little tricky getting the precendence for the NAT pools correct, but at the end it only worked properly when I changed the "nat (inside) 51" command to use an access-list (internet) instead of "".

All is great except now the PDM tells me that it doesn't support Policy NAT! Win one lose another... Thanks for all your help.

New Member


Actually the NAT precendence is due to the order not the ID or use of access-list. When you do a "show nat" the partner network needs to be first and then the Internet.

Makes sense, everything is order driven on the PIX. Soon they will have to update the system like they did for access-list's and provide "nat (inside) line 1 50 access-list partner-vpn"...

Just a thought...

CreatePlease to create content