05-14-2015 01:23 PM - edited 03-11-2019 10:56 PM
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?
Solved! Go to Solution.
05-14-2015 02:38 PM
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
05-14-2015 01:40 PM
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
05-14-2015 02:33 PM
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
05-14-2015 02:38 PM
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
05-14-2015 02:55 PM
I think I have it figured out -there was a bad internal route on the network causing the packets to black-hole.
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