Firewalls typically don’t hairpin well or at all for that matter, unless specifically told to do so. Hair-pinning is when a packet ultimately leaves the same interface it came into.
On a LAN it is somewhat common for packets to “bounce” off of one router interface to get to the right one, a prime candidate for the ICMP Redirect process. Forget having your Cisco ASA or Pix participate in that little exchange of ICMP messages needed though, Cisco has long held that routing protocols are exploitable and have no place on a firewall (Yes they now speak EIGRP and OSPF, go figure).
The other example of hair-pinning that comes to mind deals with VPNs and Internet Access. The scenario is that a spoke or remote site VPNs to the hub or central site and wants to travel on to the Internet from there. While it’s tempting to think of a VPN as originating from deep in the firewall the reality is that it is treated as coming from the outside interface.
In short you have to set up NAT for packets that arrive on the outside interface to turnaround and exit through the outside interface. Yes this is counter-intuitive, you have to apply the same NAT-Exempt and NAT statements on the interface as if friendlies were behind you and not the wild woolly Internet.
Assuming you assign VPN addresses from a pool on 172.16.0.0/24; the CLI then looks like this:
global (outside) 1 interface nat (inside) 0 access-list inside_nat0 nat (inside) 1 0.0.0.0 0.0.0.0 nat (outside) 0 access-list outside_nat0 nat (outside) 1 10.17.0.0 255.255.255.0 access-list outside_nat0 extended permit ip any 172.16.0.0 255.255.255.0 access-list inside_nat0_outbound extended permit ip any <your network>
Also you will need a very important sysopt:
same-security-traffic permit intra-interface
This basically turns on the ability to hair-pin.