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:
|
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.