Technical Tip: Traffic is not getting blocked even after adding Ban IP

The IP ban feature enforces access control by blacklisting specified source IP addresses, thereby dropping all associated traffic at the firewall.

Upon banning an IP address, the system forcibly terminates all active sessions associated with that source, ensuring the immediate termination of ongoing connections.

Even after banning the IP, SSH/HTTPS/PING to FortiGate’s interface still works. It is because IP ban evaluation is performed only when traffic matches a firewall policy configured with an ACCEPT action.

If the source address is on the ban list, the effective action is overridden to DENY. It applies only to the traffic meant to pass through from the FortiGate (Forwarding Traffic) and it does not work for Local-In traffic. For example, the Kernel Banned IP feature cannot work when using the Virtual IP of the FortiGate as a Destination interface. There is only one complex scenario  with a FortiGate using VDOM_A and VDOM_B in which the destination is a Loopback in VDOM_B and npu-vlink is used for the intercommunication between the VDOMs.

In the example below, 10.32.22.43 is added to the Ban IP by the Admin.

To add an IP Address to the ban list:

diagnose user banned-ip add src4 10.32.22.43 0 admin

To view the banned IP list:

kaon-kvm42 # diagnose user banned-ip list
src-ip-addr created expires cause
10.32.22.43 Sat Aug 23 07:13:06 2025 indefinite Administrative

Debug Ssample of traffic blocked due to the ban IP:

kaon-kvm42 # id=65308 trace_id=16 func=print_pkt_detail line=6194 msg="vd-root:0 received a packet(proto=6, 10.32.22.43:15498->10.5.141.231:4433) tun_id=0.0.0.0 from port1. flag [S], seq 3414889184, ack 0, win 64240"
id=65308 trace_id=16 func=init_ip_session_common line=6401 msg="allocate a new session-054926d3"
id=65308 trace_id=16 func=get_new_addr line=1308 msg="find DNAT: IP-172.29.29.29, port-4433"
id=65308 trace_id=16 func=fw_pre_route_handler line=192 msg="VIP-172.29.29.29:4433, outdev-port1"
id=65308 trace_id=16 func=__ip_session_run_tuple line=3593 msg="DNAT 10.5.141.231:4433->172.29.29.29:4433"
id=65308 trace_id=16 func=__vf_ip_route_input_rcu line=2116 msg="find a route: flag=00000000 gw-0.0.0.0 via port3"
id=65308 trace_id=16 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=29, len=4"
id=65308 trace_id=16 func=fw_forward_handler line=912 msg="Denied by endpoint check"

Debug sample of PING to FortiGate's interface with the same ban IP:

kaon-kvm42 # id=65308 trace_id=26 func=print_pkt_detail line=6194 msg="vd-root:0 received a packet(proto=1, 10.32.22.43:1->10.5.141.231:2048) tun_id=0.0.0.0 from port1. type=8, code=0, id=1, seq=16."
id=65308 trace_id=26 func=init_ip_session_common line=6401 msg="allocate a new session-0549edf4"
id=65308 trace_id=26 func=__vf_ip_route_input_rcu line=2116 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
id=65308 trace_id=26 func=ip_session_confirm_final line=3258 msg="npu_state=0x0, hook=1"
id=65308 trace_id=27 func=print_pkt_detail line=6194 msg="vd-root:0 received a packet(proto=1, 10.5.141.231:1->10.32.22.43:0) tun_id=0.0.0.0 from local. type=0, code=0, id=1, seq=16."
id=65308 trace_id=27 func=resolve_ip_tuple_fast line=6302 msg="Find an existing session, id-0549edf4, reply direction"

The above debug shows reply packets from the FortiGate for ICMP.