cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2050
Views
0
Helpful
17
Replies

Overlapping Networks through a VPN Tunnel

cfinotti22
Level 1
Level 1

After days of troubleshooting my NAT issue I now have an overlapping network problem.  When I ping from my source network (PIX DMZ) to my destination network (ASA 5505 Easy VPN) the ICMP response is never returned.  I can telnet to ports on the remote end, Example (telnet 192.168.168.1 443); however ping from 192.168.1.1 to 192.168.168.1 does not.  The remote network is using an Easy VPN setup but the Cisco ASA device is behind a nat’ed DSL modem.  Look below to see if it makes sense.

PIX DMZ  192.168.1.1   -->  ##Remote Site##   --> Verizon DSL Modem  Inside 192.168.1.1 -->  Cisco ASA 5505 Outside   192.168.1.2  --> Cisco ASA 5505  Inside  192.168.168.1

As you can see the ICMP ping will make it to the inside interface of the 5505 but will never make it back because of the nat’ed DSL modem that is sitting in front of the 5505.  Hopefully this make sense....

17 Replies 17

Jitendriya Athavale
Cisco Employee
Cisco Employee

wht dont you translate one of the 192.168.1.1 ip's to something else

you can translate the 192.168.1.1 ip on pix dmz to sometihng different using policy based static nat so that it is translated to something different only when it needs to get through vpn

Can you give me an example?  Would I create the static and bind it from the inside to the outside?

static (inside,outside) 192.168.1.0 255.255.255.0  ?

i am not sure how your network is setup but yeah i can give a example

so you cant do much on your dmz pix for 192.168.1.1 ip

you need to translate it to something else on the next hop if at all it is capable of natting

you can change the source ip

---pixdmz 192.168.1.1-------------------router-----------

so translate 192.168.1.1 ->192.168.100.1 for eg

or

if you are already patting on the pix and this 192.168.1.1 is th epatted ip of network behind the pix then use policy nat

access-list remote extended permit ip

nat(inside) 1 access-list remote

global(dmz)1 192.168.100.1

this is take care of natting for the interested traffic

nat(inside) 2 0.0.0.0 0.0.0.0

global(dmz) 2 interface

this will take care of natting for rest of traffic

Here is my current NAT configuration:

# sh run nat

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0

nat (DMZ) 0 access-list nonat-dmz

nat (DMZ) 1 0.0.0.0 0.0.0.0

#sh run | i global
global (outside) 1 interface

Would I use the following:

access-list nonat line 10 extended permit ip 192.168.1.0 255.255.255.0 10.80.1.0 255.255.255.0

nat(inside) 2 access-list remote

global(dmz)1 10.80.1.1

where is the 192.168.1.1 ipon which interface ,also what is 192.168.1.1 ip

The 192.168.1.0/24 subnet is the DMZ interface on the PIX.

interface Ethernet2.80
vlan 50
nameif DMZ
security-level 80
ip address 192.168.1.1 255.255.255.0

Can you give an example?

Thanks.

do you want the users behind the ASA to access resources via the vpn u r trying to configure

Everyone on the inside network of the PIX along with the DMZ segment should have the ability to reach the remote network.

try what i wrote in my previous post

access-list remote extended permit ip

nat(inside) 1 access-list remote

global(dmz)1 192.168.100.1

this is take care of natting for the interested traffic

nat(inside) 2 0.0.0.0 0.0.0.0

global(dmz) 2 interface

this will let your internal users access the remote end as we will be patting the source ip to 192.168.100.1

I must say I am confused on this topic.  This is a snippet of what I'm currently using which is not working.

access-list nonat extended permit ip 192.168.168.0 255.255.255.0 192.168.100.0 255.255.255.0

access-list nonat-dmz extended permit ip 192.168.1.0 255.255.255.0 192.168.168.0 255.255.255.0

nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0


nat (DMZ) 0 access-list nonat-dmz
nat (DMZ) 1 0.0.0.0 0.0.0.0

# sh run | i globa
global (outside) 1 interface
global (DMZ) 1 192.168.100.1

i understand its getting very confusing, lets start over... we know what the prob is

can you give the internal network on pix side and asa side

also please paste the nat and crypto config on both ends

####### PIX Interfaces ########

Inside and DMZ interfaces on the PIX:

sh int ip bri
Ethernet1.100              10.45.45.2      YES CONFIG up                    up
Ethernet2.50               192.168.1.1     YES CONFIG up                    up

####### NAT Interfaces on PIX ########

access-list nonat extended permit ip 192.168.168.0 255.255.255.0 192.168.100.0 255.255.255.0
access-list nonat-dmz extended permit ip 192.168.1.0 255.255.255.0 192.168.168.0 255.255.255.0

nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0

nat (DMZ) 0 access-list nonat-dmz
nat (DMZ) 1 0.0.0.0 0.0.0.0

# sh run | i globa
global (outside) 1 interface
global (DMZ) 1 192.168.100.1

####### Tunnel Group / Group Policy Interfaces on PIX ########

tunnel-group ASA-test general-attributes
address-pool S2S
default-group-policy ASA-S2S
tunnel-group ASA-test ipsec-attributes
pre-shared-key

group-policy ASA-S2S internal
group-policy ASA-S2S attributes
split-tunnel-policy tunnelspecified
split-tunnel-network-list value ASA-S2S
nem enable

access-list ASA-S2S extended permit ip object-group DM_INLINE_NETWORK_7 object-group DM_INLINE_NETWORK_8

object-group network DM_INLINE_NETWORK_7
network-object 192.168.1.0 255.255.255.0
network-object 10.37.1.0 255.255.255.0
object-group network DM_INLINE_NETWORK_8
network-object 10.22.250.0 255.255.255.0
network-object 192.168.168.0 255.255.255.0

####### Remote Easy VPN Client on ASA5505 ########

vpnclient server
vpnclient mode network-extension-mode
vpnclient nem-st-autoconnect
vpnclient vpngroup ASA-test password
vpnclient username test password
vpnclient enable

####### IP Info on ASA5505 ########
Interface                  IP-Address      OK? Method Status                Protocol
Vlan1                      192.168.168.1   YES CONFIG up                    up
Vlan2                      192.168.1.30    YES CONFIG up                    up
     

hmmm thts gonna be tricky now...

i dont think this would work bcoz all encrpted packets would have source ip as 192.168.1.1, i think you need to change ip's or atleast do some variable subnetting so that we put them in different networks

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: