Troubleshooting Tip: IPs profile opens port 8015 in a VIP configuration although VIP uses different ports

The behavior in FortiGate v7.0.15.

Firewall Policy configuration:

    edit 234
        set uuid 4fcce3e2-e1
        set srcintf "a_65"
        set dstintf "WEB"
        set action accept
        set srcaddr "all"
        set dstaddr "VIP_220.4.3.21"
        set schedule "always"
        set service "HTTP" "HTTPS" "8443" "PING"
        set utm-status enable
        set ssl-ssh-profile "certificate-inspection"
        set logtraffic all
    next
end

When the IPS profile is disabled in debugs:

id=20085 trace_id=1064 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-216, ret-no-match, act-accept"id=20085 trace_id=1064 func=__iprope_user_identity_check line=1814 msg="ret-matched"

id=20085 trace_id=1064 func=__iprope_check_one_policy line=2242 msg="policy-0 is matched, act-drop"

id=20085 trace_id=1064 func=iprope_fwd_check line=819 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"

id=20085 trace_id=1064 func=iprope_fwd_auth_check line=838 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-drop, idx-0"

id=20085 trace_id=1064 func=fw_forward_handler line=719 msg="Denied by forward policy check (policy 0)"

When the IPS profile is enabled in debugs:

id=1088 func=__iprope_check_one_policy line=2025 msg="checked gnum-100004 policy-234, ret-matched, act-accept"

id=20085 trace_id=1088 func=__iprope_user_identity_check line=1814 msg="ret-matched"

id=20085 trace_id=1088 func=__iprope_check line=2272 msg="gnum-4e20, check-ffffffffa002d760"

id=20085 trace_id=1088 func=__iprope_check_one_policy line=2025 msg="checked gnum-4e20 policy-4294967295, ret-matched, act-accept"

id=20085 trace_id=1088 func=__iprope_check_one_policy line=2242 msg="policy-4294967295 is matched, act-accept"

id=20085 trace_id=1088 func=__iprope_check line=2289 msg="gnum-4e20 check result: ret-matched, act-accept, flag-00800008, flag2-00000000"

id=20085 trace_id=1088 func=__iprope_check_one_policy line=2242 msg="policy-234 is matched, act-accept"

id=20085 trace_id=1088 func=iprope_fwd_check line=819 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-234"

id=20085 trace_id=1088 func=iprope_fwd_auth_check line=838 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-234"

id=20085 trace_id=1088 func=fw_forward_handler line=881 msg="Allowed by Policy-234: AV"

id=20085 trace_id=1088 func=av_receive line=434 msg="send to application layer"

Check iprope policies, and there is a new entry:

policy index=234 uuid_idx=4782 action=accept

flag (8010408): redir d_r master pol_stats

flag2 (4000): resolve_sso

flag3 (b0): !sp link-local best-route

schedule(always)

cos_fwd=255  cos_rev=255

group=00100004 av=00004e20 au=00000000 split=00000000

host=2 chk_client_info=0x0 app_list=0 ips_view=1

misc=0

zone(1): 232 -> zone(1): 99

source(1): 0.0.0.0-255.255.255.255, uuid_idx=3650,

dest(1): 10.20.18.11-10.20.18.11, uuid_idx=4593,

vip(1): 9

service(1):

[6:0x0:1007/(0,65535)->(8015,8015)] flags:0 helper:auto

Workarounds:

• Create a top-priority deny policy to block traffic to VIP external IPs on ports 8008, 8010, and 8015, effectively stopping the leakage without affecting other services.
• Configure a specific port forwarding rule to strictly match and allow only the defined service traffic. This ensures that only traffic on the specified ports and protocols is permitted, effectively filtering out any unauthorized or non-matching connections.
• This solution, while effective, is noted as challenging to deploy across multiple firewall clusters globally.

Solution:

Upgrade to v7.0.16, v7.2.9, v7.4.4, v7.6.0, and later.