Possible solution to hairpin routing issues.
Using your perimeter firewall as a VPN termination point can cause routing issues on a cisco ASA because of hair-pinning and invalid next-hop addresses. There are a few ways to get around this type of problem. The one I present is a very fun way of doing it and should be left out of production due to its weirdness. Good way to sharpen skills for CCIE exam though.
This is a common scenario, where a VPN users are unable to reach internet resources. The ASA is unable to find the next hop for packets returning from internet destinations.
1) VPN client tries to reach webserver via its next hop which is the firewall
2) The packet is delivered successfully
3) Packet returns from sever for next hop 192.168.60.100 (after un-nat)
- Route fails to locate next hop
This fails because the ASA’s route says its interface is OUTSIDE and the next hop for 192.168.60.0/24 as 86.71.71.128.129 (the ISP router) bu the returning traffic tries to reach 192.168.60.0/24 via the INSIDE interface
Solution:
1) On ASA, advertise static routes into OSPF
Router ospf 101 Network 172.16.0.0 0.0.255.255 area 0 Redistribute static subnets route-map RM-STATIC-TO-OSPF Route-map RM-STATIC-TO-OSPF Match ip address ACL-STATIC-TO-OSPF Ip access-list standard ACL-STATIC-TO-OSPF Permit ip 192.168.60.0 0.0.0.255- R1 will receive 192.168.60.0/24 via 172.16.1.3
- R2 will receive 192.168.60.0/24 via 172.16.2.3
2) On R1, create two static routes to R2 – more specific routes are required or the ASA will prefer its static route as the AD is lower
ip route 192.168.60.0 255.255.255.128 172.16.0.2 ip route 192.168.60.128 255.255.255.128 172.16.0.2 Router ospf 101 Network 172.16.0.0 0.0.255.255 area 0 Redistribute static subnets route-map RM-STATIC-TO-OSPF Route-map RM-STATIC-TO-OSPF Match ip address ACL-STATIC-TO-OSPF Ip access-list standard ACL-STATIC-TO-OSPF Permit ip 192.168.60.0 0.0.0.255 
So this is what’s happening
1) VPN client tries to reach webserver via its next hope which is the firewall
2) The packet is delivered successfully
3) Packet returns from webserver for destination 192.168.60.100 (after un-nat)
4) ASA forwards packet to R1 (because R1 now has a more specific route to the VPN host due to the redistributed static subnet
5) R1 forward the packet to R2 based on the static route we set (the reason new didn’t forward the packet back to the ASA is because the ASA wouldn’t install the route into its routing table as the registered next hop will be itself)
6) R2 receiving the packet from R1 just as with the ASA will not add the specific routes to its routing table due to the forward address being itself
R2# show ip interface brief | include 172\.16\.0
e0/0 172.16.0.2 YES NVRAM up up
R2# show ip ospf database external 192.168.60.0
OSPF Router with ID (172.16.1.1) (Process ID 101)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 337
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 192.168.60.0 (External Network Number )
Advertising Router: 172.16.1.1
LS Seq Number: 800000DF
Checksum: 0x1A93
Length: 36
Network Mask: /32
Metric Type: 1 (Comparable directly to link state metric)
TOS: 0
Metric: 20
Forward Address: 172.16.0.2
External Route Tag: 0
7) R2, however will still have the advertised route from ASA for 192.168.60.0/24 and forward the packet that way.
8) ASA sees this packet as interesting and sends it over the VPN and everyone is happy. The interesting thing here is that the ASA doesn’t see this as asymmetric routing even though the TCP SYN was originated from the internet interface.
That’s it.
JUNIOR TAITT 