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.
This article describes a condition where the traffic does not match an explicit web proxy-policy when sec-default-action is set to ‘accept’ under the web-proxy configuration.
Scope
FortiGate.
Solution
When the explicit web proxy configuration with sec-default-action accept is set up after the device boots up following a factory reset of the device, incoming traffic may not be matched against the proxy policy. As a result, the traffic will bypass any UTM inspection configured on the proxy policy. The following sequence of events can lead to this condition.
FortiGate is boot-up from a factory-reset condition.
Configure Explicit-web-proxy.
config system interface edit "port2" set ip 10.1.100.3 255.255.255.0
set explicit-web-proxy enable next end
config web-proxy explicit set status enable
set sec-default-action accept <-- set https-replacement-message enable set message-upon-server-error enable set pac-file-server-status disable set ssl-algorithm medium end config firewall proxy-policy edit 1 set proxy explicit-web set dstintf "port1" àEgress interface for default route. set srcaddr "all" set dstaddr "all" set service "webproxy" set action accept set utm-status enable set ssl-ssh-profile "deep-inspection" set webfilter-profile "webfilter" next
The end user tries to access a destination that is blocked by webfilter-profile via explicit-web proxy-policy, website continues to load without being blocked.
The expectation is that the traffic should match the explicit-web-proxy policy and be further allowed/blocked by the UTM profiles as configured.
This issue is documented under bug ID 1059899.
Workaround: Configure set sec-default-action to deny first in the CLI and then change the setting to accept to avoid running into this issue.
