Ok i recently came into a situation where I wanted an ASA to do hairpin routing. Here is the situation. A client was running there internet through a partner's WAN. They do not have a layer3 switch/router, and the defautl gateway on there network was actually the the partner's equip. They recently purchased there own internet circuit and an ASA5510. I initially tried putting in the nat exception and permit same security interface and static route on the ASA so that traffic bound for the extranet segment would be routed back out the inside interface toward the gateway to the partner's WAN. Pings worked right away, however no applications would work: no web traffic, application traffic, anything. My only guess is that the ASA does not like this in relation to stateful traffic flow, and the fact that since the partner's gateway is on the same subnet, you end up with asymentric routing. The solotuion ended up being adding a route to the workstations, but I am still curious if what I tried should have worked, or more detailed on why it didnt. thanks. I do know that with a router not a firewall it likely would have worked.
Your clients had the ASA as the default gateway so traffic went to the ASA intially. When the app servers on the partner extranet responded to the client traffic would it go back via the ASA or direct to the clients.
If direct then that is why it isn't working. As you say adding a route to the workstation(s) fixed it. You could also have natted the clients addresses to the ASA interface so the extranet servers would have to send the traffic back to the ASA.
I would think that the return traffic would go directly to the workstations. I guess my question is when you try to hairpin on an ASA like this, how is it different then when you hairpin on a router? Does a router somehow communicate using icmp so that last leg of return traffic still goes back to it instead of directly back(asymentric)
A router wouldn't do it any differently but then a router is not keeping the state of the connection so it would work. The problem is that your ASA is not just routing the packets, it is also keeping state for the connection and it is not seeing all the packets in the connection so it drops the traffic.
A router doesn't keep state, unless of course you run the IOS firewall. So a router just routes the client packets to the servers and the servers send the packets back to the clients direct. The clients don't really care how the packets got back and the the router doesn't because it treats each packet separately.
Hmmm would need to test. If you haven't enabled ICMP inspection then yes ICMP should work fine. If you have enabled ICMP inspection not sure what would happen. I suspect you may have problems.
UDP - i suspect again it depends. The ASA does keep state of UDP but only by using a timer ie. when it sees an outbound packet it sets a timer and if it receives the return packet within that timer it allows it through.
Now for UDP requests that are a simple on packet request/one packet response then yes i suspect you would be okay.
However if the UDP connection involved multiple packets - well i just don't know to be honest. I'm not sure if the ASA keeps "state" for the entire UDP connection or on a per request/response.
In addition there are other protocols that are not stateful eg. GRE.
In another thread i saw icmp referenced for a similar objective, and the fact that the ASA does not participate in ICMP the same way a router does.
Also, in theory would TCP stateful bypass(new 8.2 feature) work?
"and the fact that the ASA does not participate in ICMP the same way a router does."
not sure i understand what you mean with this.
"Also, in theory would TCP stateful bypass(new 8.2 feature) work?"
Don't know as i have never used that feature. Sounds like it would from the name but wouldn't like to say :-)
Yes state bypass would help in this scenario.
This feature has been there in the FWSM platform:
match access-list permit_host
set connection advanced-options tcp-state-bypass
service-policy permit_all_tcp interface outside
Introduced in 3.2.1
I had this problem before. The following post solved it (be sure to follow the instructions exactly):