ASA 8.2 with overlapping VPN subnets

[martens72]

Hello,

We have servers in the datacenter to monitor several customer ASA devices over VPN tunnel. The issue is some customers overlap with each other. For example, 192.168.1.0/24 may be used as remote subnet for 2-3 customers. The monitored devices are running ASA 8.2 code.

In ASA 8.3+ code, I would create manual nat to change the source IP of the remote device when connecting to our monitoring server. In 8.2 however, I have tried to static Policy nat the inside interface with the following config (192.168.1.254 is the inside interface IP):

<ACL>

access-list monitoring remark ----- Access list for NAT to monitoring devices -----

access-list monitoring extended permit ip host 192.168.1.254 10.20.10.0 255.255.255.0

<Static Nat>

static (inside,outside) 172.16.33.254 access-list monitoring

<Crypto Map>

access-list tunnel extended permit ip host 172.16.33.254 object-group MonitoringServers

Am I barking up the wrong tree? Is it possible to NAT the IP of the inside interface in such a manner, or will I need to bypass the tunnel monitoring and use the external IP?

Thanks in advance for your help.

Michael Martens

[Julio Carvajal]

Hello Michael,

If the VPN goes from the Data center to each of the Spokes,

Why dont you do a policy nat on the spoke routers when communicating to the Data center (let's say change their IP to the subnet range 10.20.20.0/24 for one spoke 10.20.40.0/24 to another and keep going).

Then on the Data center site change the No_Nat config and Crypto ACL to reflect that new address space.

Regards

[martens72]

I have applied the following on the spoke ASA (8.2):

access-list monitoring extended permit ip 192.168.1.0 255.255.255.0 10.20.10.0 255.255.255.0

nat (inside) 5 access-list monitoring tcp 0 0 udp 0

global (outside) 5 172.16.33.1-172.16.33.254 netmask 255.255.255.0

access-list tunnel extended permit ip 172.16.33.0 255.255.255.0 object-group MonitoringServers

The Hub ASA (8.4) is setup to encrypt traffic to the 172.16.33.0/24 subnet for this tunnel. When I ping from the spoke, using the inside interface to host 10.20.10.80, it fails, and gives no indication that the inside interface IP of 192.168.1.254 is being nat'd into 172.16.33.x

Again, am I expecting too much from the 8.2 spoke, or just missing something in the config? Specifically, I am trying to monitor the inside interface IP (192.168.1.254) using host 10.20.10.80 from the Hub side. I am trying to nat the inside interface to use 172.16.33.254 when communicating to any server in 10.20.10.x subnet.

Michael Martens

[Julio Carvajal]

Hello Michael,

Did you change the No-Nat config on the HUB site to be pointing now to the 172.16.33.0/24?

On the spoke side run

packet-tracer input inside icmp 192.168.1.10 8 0 192.168.1.10

Regards,

[martens72]

I found I had a missing manual nat statement in the Hub ASA. I can  now ping from the remote subnet to the monitoring server; however I need  the monitoring server to access the ASA inside interface for snmp polling. I am  replacing the dynamic policy nat with a static policy nat to change the  inside interface from 192.168.1.254 to 172.16.33.254 when accessed from the monitoring server, or vice versa. Is it possible to  nat the IP of the inside interface to a new outside global? It doesn't  seem to be working as expected.

Micahel Martens

[Julio Carvajal]

Hello MIchael,

Do U have the management access inside command?

Do a static translation with ACL's instead than a policy-nat on the Spoke site

Regards,

Jcarvaja

[martens72]

"management-access inside" is set. Assuming the inside interface IP is 192.168.1.254, I have the following config:

access-list monitoring extended permit ip host 192.168.1.254 10.20.10.0 255.255.255.0

static (inside,outside) 172.16.33.254 access-list monitoring

The crypto acl permits the traffic for encryption; and was working with the dynamic policy nat.

ASA# sh xlate | incl 172.16.33

Global 172.16.33.254 Local 192.168.1.254

NAT from inside:192.168.1.254 to outside(monitoring):172.16.33.254 flags s

match ip inside host 192.168.1.254 outside 10.20.10.0 255.255.255.0

    static translation to 172.16.33.254

    translate_hits = 0, untranslate_hits = 960

[martens72]

I'm thinking this is next to impossible....I can't find any reference to NAT'ing the actual IP of the interface online.

Packet tracer using the 172.16.33.254 IP is good in both directions to the monitoring server - the issue just seems to be that the interface itself can't be NAT'd into another IP address. The only option I would have is to monitor the ASA directly over the public IP,  which I would much rather do over the encrypted tunnel.

Any ideas?

[Julio Carvajal]

Hello Michael,

I just got confused from all of the information provided .

Can you build a topology and we can start from scratch. I do think this is possible.

Regards

[Anand Solgama]

Hi,

I did

like this bro    ...... ASA 8.02

access-list INSIDE extended permit ip 192.168.1.0 255.255.255.0 1.0.0.0 255.0.0.0

global (outside) 1 200.200.200.200

nat (inside) 1 access-list INSIDE

and on outside router ICMP debig output here

*Oct 15 17:55:10.851: ICMP: echo reply sent, src 1.1.1.1, dst 200.200.200.200

R1#

*Oct 15 17:55:11.883: ICMP: echo reply sent, src 1.1.1.1, dst 200.200.200.200

R1#

*Oct 15 17:55:12.923: ICMP: echo reply sent, src 1.1.1.1, dst 200.200.200.200

R1#

*Oct 15 17:55:13.939: ICMP: echo reply sent, src 1.1.1.1, dst 200.200.200.200

R1#

*Oct 15 17:55:16.067: ICMP: echo reply sent, src 200.200.200.2, dst 192.168.1.2

R1#

*Oct 15 17:55:17.083: ICMP: echo reply sent, src 200.200.200.2, dst 192.168.1.2

R1#

*Oct 15 17:55:18.119: ICMP: echo reply sent, src 200.200.200.2, dst 192.168.1.2

R1#

*Oct 15 17:55:19.147: ICMP: echo reply sent, src 200.200.200.2, dst 192.168.1.2

R1#

*Oct 15 17:55:20.163: ICMP: echo reply sent, src 200.200.200.2, dst 192.168.1.2

SEE WHEN PING TO 1.1.1.1 IT CHANGE ADDRESS AS PER MY  ACL "INSIDE" AND WHEN GO TO 200.200.200.2 IT WILL NOT MATCH ACL SO NO NAT FOR THAT 

BYE,

[vishaw jasrotia]

Hey Michael ,

I am fully aware of the topology that you are using , but as per what I understand from your toplology you can use static route on the host basis.

Thanks

Vishaw