PBR Traffic back to the interface it came from

[mario.jost]

I have following setup:

10.0.0.15   
   
   O -------------------|
ClientA                 |
                        |
              10.0.0.1  O  9.9.9.9
                      Router
                        |
   O -------------------|
ClientB

10.0.0.107

We have a public hostname fish.example.com that resolves to 9.9.9.9 where we have a static NAT that forwards the traffic to ClientB where there is a webserver running. The issue is, if clients from within the same network try to connect to fish.example.com, they get the same public IP 9.9.9.9 back and try to access the public IP of the router from within the LAN. So i was hoping we could solve this with following PBR:

ip access-list extended HAIRPIN_NAT
 10 permit tcp 10.0.0.0 0.0.0.255 host 9.9.9.9 eq 443

route-map PBR_HAIRPIN_NAT permit 10 
 match ip address HAIRPIN_NAT
 set ip next-hop 10.0.0.107

This policy is then applied onto the SVI interface of the router:

interface Vlan11
 description DSL
 vrf forwarding DSL
 ip address 10.0.0.1 255.255.255.0
 ip dns view-group DNS_DSL
 ip nat inside
 zone-member security DSL
 ip policy route-map PBT_HAIRPIN_NAT

But the access does not work. Couple of things i can think of why it does not work:

• NAT is done before PBR so the ACL does not match
• This needs to be allowed in the ZBF configuration (new zone-pair source DSL destination DSL) in order to work
• PBR does not permit returning traffic to the same interface it came from
• PBR requires a real next-hop, so setting it to the destination IP is not allowed

I dont have any experience with PBR, so if anyone could tell me if this configuration is even supposed to work, i could eliminate some sources of error.

[sdroy · Accepted solution]

Your setup might not work as you want it to because NAT typically occurs before PBR, so your ACL HAIRPIN_NAT will not match pre-NAT traffic unless this sequence is configurable. PBR also requires a valid next-hop IP that is not the same as the destination, so setting it to 10.0.0.107 might not be valid. In addition, return traffic to the same interface (hairpin traffic) typically requires explicit support, such as enabling intra-zone traffic with a zone-pair configuration in the Zone-Based Firewall (ZBF). As a workaround, you can use internal DNS to resolve fish.example.com to 10.0.0.107 so that local clients do not require hairpin NAT, or you can use a NAT loopback configuration if your platform supports it. Also, verify and update your ZBF rules to permit intra-zone traffic explicitly.

[mario.jost]

Thank you for your answer. In the meantime, i have tested a intra-zone configuration where i allow all traffic that is coming from a zone going back to the same zone, but it was still not working. Probably because, as you wrote, that NAT is done before PBR takes place, therefore never matching an entry in the ACL.

I have read into NAT loopback after you mentioned it. It seems that this is the real hairpin-nat solution, but its a huge PITA to configure and also requires you to packet-switch all the traffic instead of ip ceffing it out the fast way. 

I have read about the DNS solution even before i created this post, but we do not have DNS active on the router at the time. Maybe this is the easiest solution considering all other solutions are so complicated to implement. Thank you for your input.

[balaji.bandi]

You can try this method to have the DNS A entry on the local DNS server point to the domain to local IP.