10-12-2013 07:53 PM - edited 03-11-2019 07:51 PM
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
10-13-2013 12:08 AM
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
10-14-2013 08:04 AM
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
10-14-2013 08:10 AM
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,
10-14-2013 09:48 AM
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
10-14-2013 09:52 AM
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
10-14-2013 10:37 AM
"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
10-14-2013 02:33 PM
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?
10-14-2013 08:16 PM
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
10-15-2013 05:30 AM
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,
10-14-2013 03:31 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide