Skip to main content
funkylicious
SuperUser
SuperUser
March 10, 2025
Question

VIP Hairpin NAT - issue

  • March 10, 2025
  • 1 reply
  • 1648 views

Hi,

 

Like the title suggests, like trying to configure a Hairpin-NAT ( SSLVPN > LAN ) I got across the most annoying thing ever. I did configure some so far, but only from LAN > LAN this one I think it's a first.

 

This works ( SSLVPN > LAN ) for some reason if I enable WAN > LAN , but I dont want access from WAN to the VIP, only from SSLVPN.

 

 

 

id=20085 trace_id=13771 func=print_pkt_detail line=5869 msg="vd-VDOM:0 received a packet(proto=6, 192.168.220.100:64947->PUB-IP:3050) tun_id=0.0.0.0 from ssl.VDOM. flag [S], seq 1209702776, ack 0, win 8192" id=20085 trace_id=13771 func=init_ip_session_common line=6048 msg="allocate a new session-ef2fd6a5, tun_id=0.0.0.0" id=20085 trace_id=13771 func=iprope_dnat_check line=5338 msg="in-[ssl.VDOM], out-[]" id=20085 trace_id=13771 func=iprope_dnat_tree_check line=827 msg="len=1" id=20085 trace_id=13771 func=__iprope_check_one_dnat_policy line=5198 msg="checking gnum-100000 policy-2" id=20085 trace_id=13771 func=get_new_addr line=1223 msg="find DNAT: IP-10.0.0.2, port-3050" id=20085 trace_id=13771 func=__iprope_check_one_dnat_policy line=5293 msg="matched policy-2, act=accept, vip=2, flag=100, sflag=2000000" id=20085 trace_id=13771 func=iprope_dnat_check line=5350 msg="result: skb_flags-02000000, vid-2, ret-matched, act-accept, flag-00000100" id=20085 trace_id=13771 func=iprope_fwd_check line=784 msg="in-[ssl.VDOM], out-[VDOM-WAN], skb_flags-02000000, vid-2, app_id: 0, url_cat_id: 0" id=20085 trace_id=13771 func=__iprope_tree_check line=561 msg="gnum-100004, use addr/intf hash, len=3" id=20085 trace_id=13771 func=__iprope_check_one_policy line=2027 msg="checked gnum-100004 policy-5, ret-no-match, act-accept" id=20085 trace_id=13771 func=__iprope_check_one_policy line=2027 msg="checked gnum-100004 policy-8, ret-no-match, act-accept" id=20085 trace_id=13771 func=__iprope_check_one_policy line=2027 msg="checked gnum-100004 policy-0, ret-matched, act-accept" id=20085 trace_id=13771 func=__iprope_user_identity_check line=1816 msg="ret-matched" id=20085 trace_id=13771 func=__iprope_check_one_policy line=2244 msg="policy-0 is matched, act-drop" id=20085 trace_id=13771 func=iprope_fwd_check line=821 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0" id=20085 trace_id=13771 func=iprope_fwd_auth_check line=840 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0" id=20085 trace_id=13771 func=_pre_route_auth line=106 msg="pre_route_auth check fail(id=0), drop"    config firewall vip     edit "viP_10.0.0.2-3050"         set id 1         set extip PUB-IP         set mappedip "10.0.0.2"         set extintf "any"         set portforward enable         set extport 3050         set mappedport 3050     next end   config firewall policy     edit <>         set srcintf "ssl.VDOM"         set dstintf "LAN"         set action accept         set srcaddr "SSLVPN_TUNNEL_ADDR2"         set dstaddr "viP_10.0.0.2-3050"         set schedule "always"         set service "ALL"         set logtraffic all         set groups "SSL VPN"     next end   get router info routing-table details 10.0.0.2 Routing entry for 10.0.0.0/8   Known via "static", distance 10, metric 0, best   * 172.16.16.2, via LAN

 

 

 

 

Anyone got any ideas, cuz I ran out of any :) ?

1 reply

Toshi_Esumi
SuperUser
SuperUser
March 10, 2025

So you want for all SSL VPN users to use the VIP outside IP (currently WAN interface IP) to access the device with 10.0.0.2 IP, right? While those SSL VPN users can access directly to 10.0.0.2 when the VPN is up. Why do you need the VIP at the first place then.

Toshi 

funkylicious
SuperUser
SuperUser
March 10, 2025

Well, as you probably might know some customers are just that way ... the demand is the access the public IP although it has access to the internal IP also :)

 

L.E. https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-Hairpin-NAT-VIP/ta-p/195448 as per example 1 this is also my case, but from WAN to LAN i cannot seem to narrow it down to only the private subnet, it only works with all .

"jack of all trades, master of none"
Toshi_Esumi
SuperUser
SuperUser
March 10, 2025

My point is those SSL VPN users don't need to use the public IP even when they're off-site accessing over the internet since they have SSL VPN (isn't that the purpose of having SSL VPN?).
And only if someone else needs to access it over the internet WITHOUT SSL VPN, of course you have to have a policy WAN->LAN with the VIP. But you said only from SSL VPN.
The hairpin is needed when the same user needs/wants to use the same host IP regardless when he/she is outside or inside of the office. But for SSL VPN users, they just need to use 10.0.0.2 in both cases.

Toshi