FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Stephen_G
Moderator
Moderator
Article Id 247040
Description This article describes how to troubleshoot and fix an issue where an application becomes inaccessible through a previously configured NAT hairpin after configuring a policy route for the server network.
Scope FortiGate v6x, v7x.
Solution

Consider a scenario where the administrator tries to access an application hosted in the same server and the server network needs to have a policy route through a particular ISP.

 

In this case, all of the traffic is passed through the policy route, which makes a VIP hairpin inaccessible.

 

Below is an example configuration for the scenario:

 

# config firewall vip

edit "VIP-Server"

set uuid 3acb6a34-b282-51ed-77eb-bf23ffe194a5

set extip 172.16.16.110

set mappedip "192.168.1.2"

set extintf "any"

set portforward enable

set extport 80

set mappedport 80

next

end

 

# config firewall policy

edit 1

set name "Server to Internet"

set uuid 09547506-b29e-51ed-5d35-c1a7794eccd6

set srcintf "lan"

set dstintf "wan"

set action accept

set srcaddr "192.168.1.2/32"

set dstaddr "all"

set schedule "always"

set service "ALL"

set logtraffic all

set nat enable

next

edit 2

set name "Hairpin-VIP_Server"

set uuid 355d6c52-b29e-51ed-8df2-7feb1f060ca4

set srcintf "lan"

set dstintf "lan"

set action accept

set srcaddr "192.168.1.2/32"

set dstaddr "VIP-Server"

set schedule "always"

set service "ALL"

set logtraffic all

next

edit 3

set name "VIP-Server-Policy"

set uuid 1f4579be-b29e-51ed-cb0e-2968a2deabac

set srcintf "wan"

set dstintf "lan"

set action accept

set srcaddr "all"

set dstaddr "VIP-Server"

set schedule "always"

set service "ALL"

set logtraffic all

next

end

 

In the GUI:

 

Stephen_G_0-1677182843205.png

 

After a policy route is enabled to the server network, all traffic flows through the policy route. However, hairpin-vip becomes inaccessible through the same network.

 

# config router policy

edit 1

set input-device "lan"

set srcaddr "Server-Network"

set dstaddr "all"

set gateway 172.16.16.1

set output-device "wan"

next

end

 

In the GUI:

 

Stephen_G_1-1677182843207.png

 

The Debug Result:

 

The debug output shows the traffic is accepted by the policy route and later by policy 0, and the packet is dropped. This means traffic could not make it to the firewall policy, instead dropping packets after the match with policy route.

 

id=65308 trace_id=569 func=print_pkt_detail line=5868 msg="vd-root:0 received a packet(proto=6, 192.168.1.2:50200->172.16.16.110:80) tun_id=0.0.0.0 from lan. flag [S], seq 488837056, ack 0, win 64240"

id=65308 trace_id=569 func=init_ip_session_common line=6049 msg="allocate a new session-00005ceb, tun_id=0.0.0.0"

id=65308 trace_id=569 func=iprope_dnat_check line=5268 msg="in-[lan], out-[]"

id=65308 trace_id=569 func=iprope_dnat_tree_check line=830 msg="len=1"

id=65308 trace_id=569 func=__iprope_check_one_dnat_policy line=5131 msg="checking gnum-100000 policy-2"

id=65308 trace_id=569 func=get_new_addr line=1228 msg="find DNAT: IP-192.168.1.2, port-80"

id=65308 trace_id=569 func=__iprope_check_one_dnat_policy line=5223 msg="matched policy-2, act=accept, vip=2, flag=100, sflag=2000000"

id=65308 trace_id=569 func=iprope_dnat_check line=5280 msg="result: skb_flags-02000000, vid-2, ret-matched, act-accept, flag-00000100"

id=65308 trace_id=569 func=fw_pre_route_handler line=176 msg="VIP-192.168.1.2:80, outdev-unknown"

id=65308 trace_id=569 func=__ip_session_run_tuple line=3498 msg="DNAT 172.16.16.110:80->192.168.1.2:80"

id=65308 trace_id=569 func=rpdb_srv_match_input line=1045 msg="Match policy routing id=2: to 172.16.16.1 via ifindex-5"

id=65308 trace_id=569 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-172.16.16.1 via wan"

id=65308 trace_id=569 func=iprope_fwd_check line=789 msg="in-[lan], out-[wan], skb_flags-020000c0, vid-2, app_id: 0, url_cat_id: 0"

 

id=65308 trace_id=569 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=37, len=2"

id=65308 trace_id=569 func=__iprope_check_one_policy line=2047 msg="checked gnum-100004 policy-6, ret-matched, act-accept"

id=65308 trace_id=569 func=__iprope_check_one_policy line=2047 msg="checked gnum-100004 policy-0, ret-matched, act-accept"

id=65308 trace_id=569 func=__iprope_user_identity_check line=1822 msg="ret-matched"

id=65308 trace_id=569 func=__iprope_check_one_policy line=2265 msg="policy-0 is matched, act-drop"

id=65308 trace_id=569 func=iprope_fwd_check line=826 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"

id=65308 trace_id=569 func=iprope_fwd_auth_check line=845 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"

id=65308 trace_id=569 func=fw_forward_handler line=757 msg="Denied by forward policy check (policy 0)"

 

To fix this, configure a stop policy route to incoming traffic for the server interface which has the same source and destination addresses just above the policy route for the server to internet traffic.

 

This allows FortiGate to avoid checking the route if its source and destination match with the server network, instead allowing it to pass its traffic through a policy table. Traffic that doesn't match the stop policy route is processed with the online policy route.

 

In the CLI:

 

# config router policy

edit 2

set input-device "lan"

set srcaddr "Server-Network"

set dstaddr "Server-Network"

set action deny

next

edit 1

set input-device "lan"

set srcaddr "Server-Network"

set dstaddr "all"

set gateway 172.16.16.1

set output-device "wan"

next

end

 

In the GUI:

 

Stephen_G_2-1677182905271.png

 

Traffic flow after the stop policy route is configured:

 

Stephen_G_3-1677182905275.png

 

Here, the log shows that the traffic is SNATed first and later DNATed to the server IP.

 

Stephen_G_4-1677182905276.png

 

 

Use similar approach if the server resides in a different internal subnet.

 

Consider an example where a server resides in the DMZ interface and a policy route is in place for the server network. To enable access to the server from the LAN network, configure a LAN to DMZ subnet 'stop policy route' policy:

 

# config router policy

    edit 3

        set input-device "lan"

        set srcaddr "LAN-Network"

        set dstaddr "DMZ-Server-Subnet"

        set action deny

    next

end

 

In the GUI:

 

Stephen_G_0-1677490559111.png

 

 

Related document:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-Hairpin-NAT-VIP-in-policy-rout...

 

Article content by Bijay Prakash Ghising.