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.
sagha
Staff
Staff
Article Id 398390
Description This article explains a scenario where an explicit proxy may fail on a Loopback if there is a captive portal config on the incoming interface.
Scope FortiGate.
Solution

A loopback interface is configured and has explicit proxy enabled: 

 

config system interface
    edit "LOOPBACK1"
        set vdom "root"
        set ip 10.5.5.19 255.255.255.255
        set allowaccess ping https http
        set type loopback
        set explicit-web-proxy enable
        set role lan
        set snmp-index 362
    next
end
 
Explicit proxy configuration: 
 
config web-proxy explicit
    set status enable
    set http-incoming-port 8081
    set incoming-ip 10.5.5.19
end
 
There is a policy that allows traffic from the incoming interface towards the loopback interface.
 
config firewall policy
    edit 10
        set name "Port1 to LOOPBACK"
        set srcintf "port1"
        set dstintf "LOOPBACK1"
        set action accept
        set srcaddr "all"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end
 
Inbound traffic is seen on the FortiGate, but is then dropped.
 
FGT # diagnose sniffer packet any 'host 10.12.0.1 and port 8080' 4 0 a
interfaces=[any]
filters=[host 10.12.0.1 and port 8080]

2025-05-13 09:49:48.673062 port1 in 10.12.0.1.64338 -> 10.5.5.19.8080: syn 1677162700
2025-05-13 09:49:52.674096 port1 in 10.12.0.1.64338 -> 10.5.5.19.8080: syn 1677162700
 
Debug flow shows that traffic fails to match any policy, and hence it is getting dropped. 
 
025-05-16 11:56:07 id=65308 trace_id=113855 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=6, 10.12.0.1:58204->10.5.5.19:8081) tun_id=0.0.0.0 from port1. flag [S
], seq 3718586160, ack 0, win 64240"
2025-05-16 11:56:07 id=65308 trace_id=113855 func=init_ip_session_common line=6047 msg="allocate a new session-0e7dd737"
2025-05-16 11:56:07 id=65308 trace_id=113855 func=iprope_dnat_check line=5281 msg="in-[port1], out-[]"
2025-05-16 11:56:07 id=65308 trace_id=113855 func=iprope_dnat_tree_check line=824 msg="len=0"
2025-05-16 11:56:07 id=65308 trace_id=113855 func=iprope_dnat_check line=5293 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2025-05-16 11:56:07 id=65308 trace_id=113855 func=__vf_ip_route_input_rcu line=1990 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
2025-05-13 10:51:23 id=65308 trace_id=106407 func=fw_local_in_handler line=615 msg="iprope_in_check() check failed on policy 0, drop"
 
Verifying the configuration on port 1, it is seen that a captive portal is enabled.
 
config system interface
    edit "EDU_MPLS-PRI"
        set vdom "EDU"
        set ip 10.15.5.50 255.255.255.252
        set allowaccess ping
        set security-mode captive-portal              
        set security-groups "LDAP_grp" 
        set role lan
        set snmp-index 75
    next
 
For traffic to work between Port1 and LOOPBACK1, the user must be authenticated via Captive Portal on the FortiGate, which will then match the firewall policy 10 configured, and traffic will be allowed. 
 
To apply a fix, traffic that needs to be proxied can be exempted from the Captive Portal check. 
 
config firewall policy
    edit 10
        set name "Port1 to LOOPBACK"
        set srcintf "port1"
        set dstintf "LOOPBACK1"
        set action accept
        set srcaddr "all"
        set dstaddr "all"
        set captive-portal-exempt enable
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end
 
More details on the above command can be found here: