How to Block Incoming IP Address on FortiGate Firewall​?

Unwanted or malicious traffic targeting your network perimeter can originate from a handful of hostile IPs. FortiGate’s rich feature set lets you block these IP addresses at the firewall itself, preventing them from ever reaching your internal resources. In this post, we’ll explore:

1. FortiGate’s traffic-processing model and why address objects are key
2. Two primary methods for blocking IPs:
   • GUI-based (Policy & Objects → Addresses → Firewall Policy)
   • CLI-based (config firewall address, config firewall policy)
3. Advanced options: Address Groups, Local-In policies, and automated integrations (e.g., Alert Logic)
4. Troubleshooting tips for common pitfalls

By the end, you’ll have a complete toolkit for denying traffic from any source IP on FortiGate firewalls running FortiOS 7.x.

FortiGate Traffic Flow & Address Objects

Before diving into commands, it’s crucial to grasp how FortiGate handles incoming packets:

1. Packet Arrival
   Packets hit a specific interface (e.g., wan1 or a VDOM link).
2. Local-In vs. Forwarding
   • Local-In policies govern traffic destined to the FortiGate itself (administrative access, SSL-VPN).
   • Firewall Policies handle traffic being forwarded through the FortiGate from one interface to another.
3. Policy Matching
   FortiGate evaluates “source” and “destination” against address objects or address groups, then applies the first matching policy (top-down).
4. Action: ACCEPT or DENY
   If a policy matches and action is DENY, the packet is dropped.

Address objects (single IP, subnet, or range) and address groups (collections of objects) are the building blocks. By creating an object for a malicious IP and then referencing it in a DENY policy, you effectively block traffic from that IP.

Method 1: Blocking via the GUI

This is often the quickest for ad-hoc blocking, especially if you’re already logged into the FortiGate web console.

1. Log In
   Open your browser, navigate to https://<firewall-ip>, and authenticate with an admin user.
2. Create an Address Object
   • Go to Policy & Objects → Objects → Addresses.
   • Click Create New → Address.
   • Fill in:
     • Name: block-ip-203.0.113.45 (choose a descriptive name)
     • Type: IP/Netmask
     • Subnet/IP Range: 203.0.113.45/32
     • Interface: wan1 (optional—limits matching to traffic on that interface)
   • Click OK.
3. (Optional) Create an Address Group
   If you anticipate blocking multiple IPs, grouping them simplifies policy management:
   • Go to Addresses → Address Groups → Create New.
   • Name it blacklist, then add your address objects to the group.
4. Create a DENY Policy
   • Navigate to Policy & Objects → IPv4 Policy → Create New.
   • Configure:
     • Name: DENY-BlockedIPs
     • Incoming Interface: your WAN (e.g., wan1)
     • Outgoing Interface: the internal interface (e.g., lan)
     • Source: select your single address object (or blacklist group)
     • Destination: all (or specific servers if limiting to particular hosts)
     • Schedule: always
     • Service: ALL (or restrict to TCP/UDP as needed)
     • Action: Deny
   • Click OK .
5. Reorder If Necessary
   Ensure your DENY policy sits above any general ACCEPT policies so it matches first

Method 2: Blocking via the CLI

For scripted deployments or automations, the CLI is ideal. The core commands revolve around config firewall address and config firewall policy.

• Create the Address Object

config firewall address
    edit "block-ip-203.0.113.45"
        set subnet 203.0.113.45 255.255.255.255
    next
end

• (Optional) Create an Address Group

config firewall addrgrp
    edit "blacklist"
        append member "block-ip-203.0.113.45"
    next
end

• Create the DENY Policy

config firewall policy
    edit 0
        set name "DENY-BlockedIPs"
        set srcintf "wan1"
        set dstintf "lan"
        set srcaddr "block-ip-203.0.113.45"
        # or for group: set srcaddr "blacklist"
        set dstaddr "all"
        set action deny
        set schedule "always"
        set service "ALL"
        set logtraffic all
    next
end

• Verify Configuration

show firewall address "block-ip-203.0.113.45"
show firewall policy | grep DENY-BlockedIPs

Advanced Option: Local-In Policy for Administrative Access

If you need to protect the FortiGate itself (SSH, HTTPS) from specific source IPs:

• Enable Local-In Policies

config system global
    set local-in-policy enable
end

1. Create a Local-In Policy

config firewall local-in-policy
    edit 0
        set intf "wan1"
        set srcaddr "block-ip-203.0.113.45"
        set dstaddr "all"
        set action deny
        set service "SSH"  # or HTTPS, etc.
    next
end

Tip: By default, local-in policy is disabled; enabling it gives you fine-grained control over management-plane traffic.

Automating with Alert Logic

For dynamically blocking IPs flagged by threat intelligence or IDS, integrating FortiGate with an automated-response platform like Alert Logic can save time:

1. Pre-create an Address Group (e.g., alertlogic-blocklist).
2. Configure a Firewall Policy that uses this group as the source for a DENY action.
3. Set Up the Alert Logic Simple Response to:
   • Connect via API to your FortiGate.
   • Add offending IPs to the address group.
   • Optionally remove them after a TTL (e.g., 86400 seconds).
4. Monitor and Audit as Alert Logic updates the group automatically.

This approach offloads decision-making to your SIEM/IDS and keeps firewall policy static, while the address group membership is dynamically managed.

Troubleshooting Tips

• Policy Order
  DENY policies must precede ACCEPT policies in the policy list. Use move <id> before <other-id> in CLI or drag-and-drop in GUI.
• Interface Binding
  If your address object isn’t scoped to an interface, it matches on all interfaces—sometimes unexpectedly. Specify the interface if you see no blocks.
• Logging
  Enable set logtraffic all on DENY policies to verify matches in FortiAnalyzer or the logs.
• Cache and Sessions
  Existing sessions may persist; clear them with execute clear session all (use cautiously on production).
• DNS-Based Blocking
  For dynamic IP changes (e.g., CDNs), consider fqdn-type objects instead of static IPs.
• IPv6
  Use config firewall address6 with set ip6 <ip>/128 to block IPv6 addresses similarly.

Please follow and like us: