static (outside,inside) & Xlate time-outs

[watson.daniel]

I recently had to create a VPN tunnel between two sites that had Identical IP subnets (PIX515E 6.3(3) at my end & cheapo Netscreen at far end both using 192.168.1.0) and using the static (outside,inside) command to NAT both ends IP subnets to different subnets as below:

static (inside,outside) 172.13.13.0 access-list translatePIX 0 0

static (outside,inside) 172.31.31.0 192.168.1.0 netmask 255.255.255.0 0 0

access-list translatePIX permit ip 192.168.1.0 255.255.255.0 172.31.31.0 255.255.255.0

crypto map vpn-map 60 ipsec-isakmp

crypto map vpn-map 60 match address SDI

access-list SDI permit ip 172.13.13.0 255.255.255.0 192.168.1.0 255.255.255.0

This works well but the problem that has appeared is that when one of the users behind the PIX access's the far end server he is left without Internet access till his Xlate times out or is cleared.

Global 172.13.13.120 Local 192.168.1.120

I have tried adding 172.13.13.0 to the Nat (inside) 1 statement but this didn't work. Now I am considering just lowering the Xlate timeout to something like 30mins but I am unsure of the relationship with the connection timeout. Can you have a short xlate timeout with a longer conn?

Any other suggestions would be welcome. (except for readdressing)

[ehirsel]

How does the user on the 192.168.1/24 network get internet access? Do they have to cross the vpn tunnel to the other side, or is there a local router off of the pix outside interface, or some other method?

You can't add 172.13.13 to the nat (inside) because that is viewd as a globla address. You should be able to use nat (inside) 1 182.168.1.0 255.255.255.0.

[watson.daniel]

The users on the local LAN access the internet directly through the same outside interface that terminates the VPN tunnels. The NAT(inside) 1 192.168.1.0 statement is already there and doesn't work for them while the XLATE for 172.13.13 lives. Clear Xlates and it works until he access's that particluar VPN tunnel.

[ehirsel]

What does your global (outside) 1 statement say?

Is it possible for you to use a 172.13.13/24 addreses for internet connections? If so then you can recode your

static (inside,outside) 172.13.13.0 access-list translatePIX 0 0 as static (inside,outside) 172.13.13.0 192.168.1.0 0 0

[watson.daniel]

The Global (outside) 1 is a public internet address.

It is not possible to use 172.13.13.0 addresses on the internet.

static (inside,outside) 172.13.13.0 access-list translatePIX 0 0 - This is required to tell the pix when to change the source IP of outbound packets to 172.13.13.0

Is it possible/recommendable to drop the xlate timeout below the conn timeout? Or to alleviate some of the pain perhaps I should just drop the xlate timeouts to 15mins so the user doesn't have to wait long before being allowed to access the internet?

[ehirsel]

From the cisco 6.3 doc:

The connection timer takes precedence over the translation timer, such that the translation timer only works after all connections have timed out.

Based on this and the fact that the conn timer can be no shorter than 5 min, you could set conn timer to 10 or 15 min, and set the xlate timer 1 min higher than conn value.

Is your vpn connection used in a way such that your users always connect to the hosts on the other side, but not vice versa? If so, then instead of translating between 192.168.x.x and 172.13.13.x, you could use nat and global for the vpn connection too - yes the vpn config would need to be reworked.

If not, how many public addreses do you have? And is the pool bigger than or equal to the number of servers on your side that the remote vpn site connects to?

[moriarty7]

You might want to consider using the alias feature for the re-addressing of these IP's. I know the following document talks about using the alias command between the internal and DMZ networks, but with your VPN connection I would expect it will work the same, and also allow your normal NAT to work for Internet access concurrently. Hope this helps!

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aee.shtml#dmz

Craig Young