External IP Block List Not Working

[dthorpe]

I’m trying to create a policy to block IPs from the EmergingThreats list using an External Connector feed, but it doesn’t seem to be working as expected.

I have an External Connector > IP Address External Feed configured, and it shows approximately 1500 valid entries.

Connection Status 2025/10/28 08:31:32

Last Content Update 2025/10/27 16:31:24

Entries 1490  Valid  

I can view the entries, and if I manually test one of the IPs by browsing to it, the connection succeeds, it’s not being blocked. 

If I add a single IP address directly to this rule, it does block that address correctly. However, when I rely on the external feed, it does not block any of the listed IPs. I’ve also tested with other external IP lists, and I’m seeing the same issue.

Is there something wrong with my configuration, or should I be implementing IP blocking in a different way?

Here’s the policy configuration I’m using:

config system external-resource
edit "Emergingthreats-block-IPs.net"
set uuid 05a9ff8e-cf98-51ef-828e-33680b9d9101
set type address
set resource "https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt"
set refresh-rate 60
next
end

config firewall security-policy
edit 215
set uuid 11ed86ec-8dc7-51f0-d96b-b317e5087810
set name "DT Testing Emergingthreats Block"
set srcintf "any"
set dstintf "any"
set srcaddr "grp dthorpe devices"
set dstaddr "Emergingthreats-block-IPs.net"
set enforce-default-app-port disable
set service "ALL"
set schedule "always"
set logtraffic all
next
end

FW1 # diagnose sys external-address-resource list
List of external address resources:
name:Emergingthreats-block-IPs.net, uuid-idx:3446, num of ipv4/ipv6 ranges:1290/0, used:yes

...

FW1 # diagnose sys external-address-resource list Emergingthreats-block-IPs.net
IPv4 ranges of uuid-idx 3446 (num=1290)
1.10.16.0-1.10.31.255
1.19.0.0-1.19.255.255
1.32.128.0-1.32.191.255
...

We are running 

Model FortiGate 901G 

Version v7.6.x

[AEK]

Can you try add this to the policy and see if it helps?

set auto-asic-offload disable

[dthorpe]

Outcome - sites weren't blocked.

I couldn't disable it on the Security policy but did on the SSL Instpection based on this link.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-Disable-Hardware-Acceleration/ta...

>Security policies do not allow disabling the session offloading to NPU
FW1 # config firewall security-policy

FW1 (security-policy) # edit 215

FW1 (215) # set auto-asic-offload disable

command parse error before 'auto-asic-offload'
Command fail. Return code -61

FW1 (215) #

FW1 # config firewall policy

FW1 (policy) # edit "1"

FW1 (1) # show
config firewall policy
edit 1
set name "consolidated_all"
set uuid 061441b4-cf98-51ef-b1b9-abc3a8d5f530
set srcintf "any"
set dstintf "any"
set srcaddr "all"
set dstaddr "all"
set service "ALL"
set ssl-ssh-profile "certificate-inspection"
set auto-asic-offload disable
next
end

FW1 (1) #

Tested sites were still not blocked.

I tried a quick test with it globally disabled. Same outcome.
config ips global
set np-accel-mode none
end

[AEK · Accepted solution]

Hi Donovan

There are some known issues that probably match yours.

Resolved in 7.6.4:

1150232

Threat feed URLs are not blocked since Sandbox block list file version check always fails and aborts loading other types of URL lists, including external-resource category URL list.

Resolved in 7.6.3:

1103748, 111268

Threat feeds used as source or destination addresses in security policies may not match correctly.

Try update to 7.6.4 and it will probably fix it.

Edit: By the way it is always better to use profile-based instead of policy-based NGFW. Policy-based is mainly kept on the FGT for admins who are used to firewalls of other vendors, while profile-based is the modern way to do and is  more powerful and usually has less bugs.

[dthorpe]

Thank you for the responses. I’ll schedule an upgrade and hopefully that will resolve the issue.

We hired a company back in January to migrate us from Palo Alto to FortiGate using the FortiConverter Tool. Since then, we’ve noticed quite a few issues with the conversion and resulting configurations. I was only recently assigned to manage our firewall and have been digging into it over the past few months, so I’ll add profile-based configurations to my growing list of items to review and address.

Thank You.

[kabbabu7]

The error logs show that the URL returns a 403 Forbidden error. If you go to the URL in your browser, you will see a CloudFlare error message. So this is not an OPNsense issue; the blocklist URL is down. I personally use the OISD Big blocklist in Unbound DNS settings (it’s an option in the OPNsense UI): https://oisd.nl