cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
333
Views
0
Helpful
4
Replies

Policy NAT on ASA problem?

Colin Higgins
Level 2
Level 2

I have an internal web server I want to NAT to multiple clients coming in over VPN tunnels.

The web server is behind the "inside" interface of the firewall, and its real address is 172.25.92.73

Another firewall sits northbound from this one, and provides VPN tunnels to clients. Between these two
firewalls are trunked, transit subnets for each client. Example:

172.25.91.96 /27 for ACME

So the tunnel gets established between the remote client private network and this transit network above.

In order to NAT the internal web server to this subnet and route correctly, I am using a policy NAT like so:

object network obj-172.25.92.73
 description web server
 host 172.25.92.73

object network obj-172.25.91.104
 description NAT for ACME
 host 172.25.91.104

object-group network ACME-HOSTS
 network-object host 172.50.1.10

nat (inside,ACME) source static obj-172.25.92.73 obj-172.25.91.104 destination static ACME-HOSTS ACME-HOSTS no-proxy-arp

I then apply an ACL to the northbound interface on the internal firewall

access-list ACME-IN extended permit tcp object-group ACME-HOSTS object obj-172.25.92.73 eq 80
access-group ACME-IN in interface ACME

I also added routes from the internal network to these remote VPN networks through the firewalls

 

so it looks something like this

 

remote client vpn----->FW1------>FW2------>web server (172.25.92.73)

                                 172.25.91.96 /27

Problem is, the tunnel is getting established when the remote client tries to access 172.25.91.104 on tcp 80,
but the connection is never established, and I don't see any rejections on the ACL.

Now the internal firewall also has another web server on a DMZ that is reached through the same VPN. 
This one works, but the NAT is set up differently. Example:

object network obj-10.250.10.10
 host 10.250.10.10
 nat (DMZ,ACME) static 172.25.91.102

(and I added an entry in the ACME-IN ACL for this)

I see the hits on the ACL and traffic going into the DMZ.

Is there anything wrong with the policy NAT here that would prevent connections to the internal web server?

1 Accepted Solution

Accepted Solutions

Did you see packets hitting before removing that option ?

Is the default gateway of the server set to the inside interface of the firewall ?

Can you post the output of -

packet-tracer input ACME tcp 8.8.8.8 12345 172.25.91.104 80

Jon

View solution in original post

4 Replies 4

Jon Marshall
Hall of Fame
Hall of Fame

Colin

If 172.25.91.104 is not the outside interface IP of the firewall then can you remove the "no-proxy-arp" option from your static translation and retest.

Jon

still not working. I changed it up a bit to allow ping from the northbound firewall, and if I do a "debug icmp trace" I see the packets hitting the internal firewall, a message saying

 

ICMP echo request untranslating ACME:172.25.91.97 to inside: 172.25.92.73

 

which appears correct, but I never get any packets back from 172.25.92.73

 

Did you see packets hitting before removing that option ?

Is the default gateway of the server set to the inside interface of the firewall ?

Can you post the output of -

packet-tracer input ACME tcp 8.8.8.8 12345 172.25.91.104 80

Jon

I think I have it figured out -there was a bad internal route on the network causing the packets to black-hole.

Review Cisco Networking for a $25 gift card