Technical Tip: Explicit Proxy configured on a Loopback Interface fails because of captive portal config on incoming interface
| 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: |
