I can ping from 10.156.16.28 to 24.x.x.x and get responses (I did not before I started). However, when I try to browse to the webserver or telnet to port 80 for 24.x.x.x I get nothing. Packet-tracer said the flow should be allowed so I did some captures on the ASA and it looked good.
When I sniff the traffic on 10.156.16.28 I see this:
source destination info
10.156.16.28 24.x.x.x SYN
172.22.35.10 10.156.16.28 SYN-ACK
10.156.16.28 172.22.35.10 RST (broken tcp. the acknowledgement field is nonzero while the ack flag is not set)
Obviously the traffic is making it's way back to 10.156.16.28, but that host doesn't ACK it.
I'm running an ASA5520 with 8.2 code and Websense filtering disabled for testing this. I cannot do DNS doctoring as the DNS is on our corporate network (doesn't go through this ASA) and I don't have access to the firewall on that side.
The 24.x.x.x IP is the public IP of the webser and is NAT'd to 172.22.35.10.
Currently when an inside user does a DNS query for the FQDN of the website, the DNS serever translates it to 24.x.x.x. Since the webserver is actually on the inside (172.22.35.10), the inside host will not be able to access it by using the FQDN. I thought I understood that I could setup a hairpin the way I described in my original post to re-direct any traffic coming from the 10.156.16.x network to the internal IP of the web server. Something similar is outlined here: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml#solution2
So as I see it, this what is happening: 10.156.16.28 makes a DNS query for realcoolwebsite.com and the DNS server tells it the IP is 24.x.x.x.x. Since this IP doesn't reside on the network the router sends it to the default gateway (the ASA). The ASA was dropping the traffic before I added the static statement and the same-security permit intra-interface command. After I add those command the ASA now un-NAT's (that's what it is called in the output of packet-tracer) 24.x.x.x to 172.22.35.10 and sends it back inside. This is proved out in the trace files and the fact that I can ping 24.x.x.x from 10.156.16.28.
The internal client needs to access the web server. So, it does a DNS lookup and the DNS server replies with the public IP 24.x.x.x The client will send that traffic to the ASA. However, the ASA will normally sent this traffic to the outside, but since the webserver is inside, the ASA needs to redirect this to the inside interface again. You can't do DNS doctoring since the DNS server is also on the inside.
Then, With this command: static (inside,inside) 24.x.x.x 172.22.35.10 The ASA will accept packets intended to 24.x.x.x and send them to 172.22.35.10
This is working since you're able to PING 24.x.x.x from 10.156.156.28
The problem seems with browsing or telneting to that 24.x.x.x
There are no ACLs applied to the inside interface of the ASA that might be blocking these ports? I assume not since Packet Tracer tells you the connection should go through.
You can try a ''capture'' that should give us more details:
CAPTURE INSIDE INTERFACE access-list test permit tcp host 10.156.156.28 host 24.x.x.x access-list test permit tcp host 24.x.x.x host 10.156.156.28 capture test access-list test interface inside trace
Talking it out with you and a good night's sleep showed me where I went wrong. I did not include the global and nat stetments and had instead added a nat0 ACL entry. I fixed that with these commands:
global (inside) 98 interface
nat (inside) 98 10.156.16.28 255.255.255.255
What was happening was basically a triangle effect and the 10.156.16.28 host was dropping the traffic as it didn't expect it. Ping presumably worked because of the stateless nature of ICMP.
Now I can access the website. However, the 10.156.16.28 host cannot access anything on the outside because the nat & global statements that were being used are now superseded by the better macth. Normally it would match the following for outside connections:
global (outside) 1 36.x.x.x
nat (inside) 1 10.156.16.0 255.255.255.0
Any thoughts on how I can make the hairpin work as well as allow the 10.156.16.28 host to be translated to 36.x.x.x when it goes to the internet?
BenefitsDocumentationPrerequisiteImage Download LinksLimitationsSupported PlatformsLicense RequirementsTopologyStep-By-Step ConfigurationConfigure Virtual ServiceActivate the virtual service and configure guest IPsConfiguring UTD (Service Plane)Configurin...
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...