topic Did you see packets hitting in Network Security

Policy NAT on ASA problem?

Colin Higgins — Tue, 12 Mar 2019 05:56:47 GMT

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?

ColinIf 172.25.91.104 is not

Jon Marshall — Thu, 14 May 2015 20:40:02 GMT

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

Colin Higgins — Thu, 14 May 2015 21:33:01 GMT

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

Jon Marshall — Thu, 14 May 2015 21:38:44 GMT

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

Colin Higgins — Thu, 14 May 2015 21:55:43 GMT

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