Block an Incoming IP Address on a FortiGate Firewall

Eric DawsonByEric Dawson Computers & Software

The method for how to block incoming Internet Protocol (IP) address on FortiGate firewall is to create a Subnet address object and use it in a Deny policy. Set the incoming interface to the wide area network (WAN), outgoing interface to the local area network (LAN), source to that object, and destination to “all”.

For a single public host, enter x.x.x.x/32 in Subnet / IP Range; for a subnet, use x.x.x.x/24. Open Policy & Objects, then IPv4 Policy, or Firewall Policy on firmware above 7.0. Keep Schedule set to Always and Services to All, then save and move the policy to the top of the policy list.

Which Policy Controls the Traffic Being Blocked?

A FortiGate firewall Deny policy controls traffic passing through the appliance toward an internal network. Local-in protection controls traffic addressed to the FortiGate itself, including its management interface and virtual private network (VPN) services. Choose the control by the connection’s destination, rather than treating every incoming connection as forwarded traffic.

External connections are not permitted into the internal network unless a firewall policy allows externally initiated sessions. Blocking a public address therefore concerns the access provided by those existing rules. An unwanted connection to an internal host belongs to that forwarding path, even though it first arrives at the firewall’s external interface.

Local-in policy settings identify the receiving interface, source address object, destination address object, and action. Fortinet’s example includes set intf wan1, set srcaddr <address_obj>, and set dstaddr <address_obj>. Its action setting accepts accept or deny, while the interface selection follows the interface receiving management traffic rather than requiring that particular example interface name.

Management access also deserves attention when deciding what to block. Disabling those services on the WAN interface addresses that exposure. Fortinet recommends this approach rather than leaving administrative services publicly accessible and relying solely on individual address restrictions.

Secure Sockets Layer (SSL) VPN access presents a different requirement when remote connections are needed. Removing web management access from an external interface leaves the VPN login page reachable from the internet. Required remote access therefore needs its own protection rather than assuming that disabling administrative web access closes that entry point.

Banned-IP actions have a narrower scope than their name suggests. Running diagnose user banned-ip add src4 %%srcip%% 0 admin blocks services passing through the FortiGate, not administrative access to its graphical user interface (GUI) login page. Command-line blocking is therefore a separate operational choice from protecting the appliance’s own login endpoint.

Threat validation helps determine which addresses warrant a block before enforcement. Relevant checks include command-and-control activity, peer-to-peer botnets, address reputation, compromised hosts, and threat level.

Create the Address Object and Apply the Deny Rule

FortiGate firewall configuration uses an address object to define the unwanted public IP address and a Deny policy to block it. Finish the graphical user interface (GUI) setup by saving that policy and positioning it before other rules, following Fortinet’s procedure.

Externally initiated sessions require permission from a firewall policy before entering the internal network. Place an explicit source-address block ahead of any policies that allow these incoming connections.

Menu labels depend on the installed firmware version. For versions above 7.0, open Policy & Objects > Firewall policy when creating the rule; the older menu label is Policy & Objects > IPv4 policy.

  1. Open Policy & Objects > Addresses, select “Create New,” and choose “Address” to begin defining the source you want to block.
  2. Keep the category set to “Address” and provide a name of your choice. Set the object type to “Subnet.”
  3. Enter x.x.x.x/32 in Subnet / IP Range for a single public host, replacing x.x.x.x with the unwanted address. Use x.x.x.x/24 only when blocking an entire subnet, rather than an individual host.
  4. Go to the firewall-policy menu for your firmware and select “Create New.” Give the policy a name of your choice.
  5. Choose WAN as the incoming interface. Select the local area network (LAN) interface as the outgoing interface.
  6. Assign the newly created address object to Source, then set Destination to all.
  7. Set Schedule to “Always” and Services to “All.” Choose “Deny” for Action.
  8. Enable network address translation (NAT) and the intrusion prevention system (IPS) under Security Profiles, matching the settings in the manufacturer procedure.
  9. Click “OK” to save the policy. Drag the rule from its ID column to the top of the policy list so it is evaluated before the rules below it.

Published services using a Virtual IP (VIP) require a destination-match check: traffic using a VIP might not match a blocking policy whose destination is all. Validate that exception when the unwanted address is targeting an internally hosted service published through a VIP.

Multiple known source addresses can be organized through Addresses > Address Group > Create New. A group provides the policy source when the block needs to cover several address objects rather than one.

Frequently changing malicious-address lists are a reason to consider External Threat Feeds instead of maintaining individual objects manually. Automated updates and better operational efficiency are the stated benefits of that approach.

How to Block Incoming IP Address on FortiGate Firewall with Managed Groups

Managed address groups block several source IP addresses through a shared policy source, grouping blocked addresses rather than selecting them individually as policy sources. To create the group, select Addresses -> Address Group and select “Create New”.

Alert Logic’s “Block External IP Address” response adds each targeted address to a group that already exists on the FortiGate. Before creating the response in the Alert Logic console, prepare that group on the firewall. Group creation is a prerequisite for the automated response, not an action performed by it.

A dedicated address group keeps additions and removals clearly managed for this response. Its role is to hold the addresses controlled by the automation, while the firewall policy determines their treatment. Administrators configure the group as the source of a new or existing policy with a DENY action.

Temporary blocking combines a version-based group capacity with a response expiration setting. Capacity determines the documented member limit, while expiration determines the default lifetime of the automated block. FortiGate version 7 and earlier versions have different limits in Alert Logic’s documentation; the response has the default expiration shown separately below (Alert Logic).

Setting Version or Scope Documented Value
Address-group capacity FortiGate version 7 600 address-group members
Address-group capacity Earlier FortiGate versions 300 members
Default block expiration Alert Logic Block External IP Address response 604800 seconds

Connection permissions are another requirement for the managed-group workflow. An authenticated Fortinet FortiGate next-generation firewall (NGFW) connection must grant Alert Logic access to update the address group. Authorization therefore belongs in the response setup alongside the existing group and its policy association.

Exclusion lists provide a separate control for addresses that the automated response should skip. Define those IP addresses in one or more exclusion lists when configuring exclusions. Exemptions belong in that response configuration rather than being treated as additional entries in the blocking group.

Protect Management Access with Local-In Policies

Local-in policies block specific source addresses from reaching a FortiGate interface when the unwanted connection targets the firewall itself. Use this control for interface access, including connections aimed at management services, rather than treating every incoming connection as traffic destined for an internal host.

Interface selection determines where the local-in rule applies to incoming management traffic. Fortinet’s configuration example uses set intf wan1, but the receiving interface can be another interface specified for that traffic. Choose the interface receiving the unwanted connection, rather than copying the example’s interface name without matching it to the deployment.

Address matching in the example uses set srcaddr <address_obj> and set dstaddr <address_obj> to specify source and destination objects. Replace those placeholders with the relevant FortiGate firewall address object names. Both fields belong to the local-in configuration, so the example identifies the connection’s destination as well as its source.

Action selection is explicit in the example’s set action {accept | deny} setting. Select deny for the blocking action rather than accept, which is the other choice shown in the configuration. Keep that selection tied to the interface and address conditions being configured for the unwanted management connection.

Follow Fortinet’s management-access guidance for public administration. Required remote-user connections need separate treatment from public administration.

SSL virtual private network (VPN) access requires an exception for remote connections: the web interface cannot simply be disabled on the internet-facing interface. Removing web and shell management access still leaves the SSL VPN login page reachable from the internet. Login traffic uses Hypertext Transfer Protocol (HTTP).

Command line interface (CLI) banning uses diagnose user banned-ip add src4 %%srcip%% 0 admin in the automatic-ban example. However, a banned-IP action blocks services passing through the FortiGate, not administrative access to its graphical user interface (GUI) login page. Do not substitute that command for interface-level login protection.

Check Policy Order and Published Service Exceptions

Policy order and published-service destinations affect whether an incoming connection matches the intended block. Place the blocking policy at the top of the policy list so it is evaluated before policies below it. FortiGate provides a drag handle in the policy’s ID column for changing that position.

Published services require a destination check because traffic using a Virtual IP (VIP) might not match a blocking policy whose destination is all, a warning from Fortinet. Review that destination setting when the unwanted connection targets a service published through a VIP. An address object identifying the unwanted source is only one part of the policy configuration.

Dynamic wide area network (WAN) deployments also require attention to the published service’s external address. Use 0.0.0.0/0 as the external-address wildcard for Internet Protocol version 4 (IPv4) VIPs when the FortiGate has a dynamic WAN address. That setting belongs to the VIP configuration, rather than the address object identifying the incoming source.

Published-service policies also deserve inspection when their destination is an IPv4 virtual-IP group. A configuration using that destination with an accept action permits the published traffic through its own policy treatment. Check the policy handling the service, not just the source object intended to block the unwanted address.

During office and maintenance coordination at apartment properties in the Dayton suburbs from 2009-2013, I dealt with about 40 move-outs a year, enough to make exceptions look ordinary until they cost someone a deposit. For rule sequencing and exceptions involving externally published services, I would check that a block is encountered before permits and confirm that the exposed service is actually covered.

What Does Login-Block Time Actually Protect?

Login-block time controls the duration of a Secure Sockets Layer virtual private network (SSL VPN) login block, not a network traffic Deny rule. Administrative-login lockouts use a separate setting under system global, rather than the SSL VPN configuration.

Which Setting Controls the Login-Block Duration?

SSL VPN login protection uses set login-block-time x under vpn ssl settings. Its default duration is 60 seconds, and its maximum is 86,400 seconds (Fortinet community guidance). Keep that configuration context attached to the command when distinguishing remote-access login protection from administrative-login protection.

Administrative-login protection uses admin-lockout-duration x under system global, with a maximum value of 2147483647. Selecting the administrative setting addresses the management-login lockout duration rather than the remote-access login timer. Match the configuration context to the login service being protected before changing a duration.

What Else Controls Login Protection?

HTTP Login Protection Settings specify both the allowed login attempts and the resulting block duration. Attempt limits answer how many login attempts are allowed; duration answers how long the resulting block lasts. Treat those as separate configuration choices rather than assuming a longer timer changes the attempt threshold.

System event filtering for VPN events provides the relevant view when checking SSL VPN activity. Automatic blocking of addresses attempting access to publicly hosted services requires automated settings to be configured. A login-duration adjustment should therefore remain a login-protection change, rather than a substitute for configuring an automated blocking response.

Choose Automation Without Assuming Complete Coverage

Automated blocking requires configured response settings, and threat lists do not catch every attacker reported in community experience. FortiGate appliances are unlikely to automatically block addresses attempting access to publicly hosted services unless automation has been configured, according to Fortinet. Configure the response rather than assuming that attempted access automatically creates a block.

Validation before blocking should include command-and-control activity, peer-to-peer (P2P) botnets, address reputation, compromised hosts, and threat level. Effective blocking through firewall policies includes these checks. Review those conditions when deciding which activity should lead to a response, rather than treating every attempt to reach a public service as the same event.

Stellar Cyber’s FortiGate connector requires triggerable FortiGate rules for its response actions. Address names must also avoid characters outside the American Standard Code for Information Interchange (ASCII). Check both requirements when preparing that connector: its prerequisites include the rules that perform the response and the names of the address objects involved.

Inbound and outbound actions have different group targets in the Stellar Cyber workflow. Incoming-address blocking adds an address to the source group, while outgoing-address blocking adds it to the destination group. Match the requested response direction to the corresponding group when configuring the connector’s action.

Alert Logic’s automated response requires an authenticated connection to the next-generation firewall (NGFW). Temporary additions have a default expiration of 604800 seconds in that workflow. Check the expiration setting when selecting this response for temporary blocking, since the documented workflow includes expiration rather than only adding addresses to a managed group.

Those users matched incoming addresses against the lists during their attempts to identify attackers.

Exclusions provide a practical configuration step for an Alert Logic response that must leave specified addresses outside automated blocking. Define those addresses in one or more exclusion lists, as required by its workflow. Use that exclusion mechanism when configuring exceptions for the automated response, so the addresses intended for exclusion are explicitly included in the configuration before enabling that response.

Frequently Asked Questions

Why Can a Blocked IP Still Reach the FortiGate Login Page?

The SSL VPN login page remains internet-accessible even after HTTP management access, its secure equivalent, and Secure Shell (SSH) management access are removed from WAN interfaces. Remote SSL VPN connections require the web interface to remain enabled, according to Fortinet community guidance.

Can a FortiGate Address Group Block Several Incoming IPs?

Address group creation starts at Addresses > Address Group > Create New. Group capacity reaches 600 members on FortiGate version 7 and 300 members on earlier versions. External Threat Feeds provide automated updates for environments that frequently block malicious addresses.

Does Set Login-Block-Time X Control Administrative Login Lockouts?

Set login-block-time x sets the login-block duration, with a default of 60 seconds and a maximum of 86,400 seconds. Administrative login lockouts use system global admin-lockout-duration, with a default of 60 seconds and a maximum of 2,147,483,647 seconds.

References

Sources read in September 2026.

Eric Dawson

I'm Eric Dawson, and I write The Money Watch from north Columbus, Ohio. Most of what I cover comes from my own life: renting, a 2014 Honda Fit, parking, computers, food and the bills behind all of it. I spent four years in an apartment-property office and eleven on a distributor's operations desk, reading leases and invoices. Where you need real information, I research the maker's or agency's own page and independent sources and report what they publish. I don't give tax, investment, legal or medical advice.