I've tried many times in the past to try and block IPs in our FortiGate 60E (firmware v5.6.3 build1547 (GA)) and I must say it's the most convoluted and confusing UI I've used to date. Which is why I'm here asking what I'm doing wrong. What I've typically done is create a new address and then set it to deny in the IPv4 Policy.
(step1.png)
Policy & Objects -> Addresses Create New -> Address Name: "45.141.84.162/32 20200805" Type: Subnet Subnet/IP Range: 45.141.84.162/32 Interface: wan1 (or all)
(step2.png) Policy & Objects -> IPv4 Policy Create New Name: "Block 45.141.84.162" Incoming Interface: wan1 Outgoing Interface: internal Source: "45.141.84.162/32 20200805" Destination: all Schedule: always Service: ALL Action: DENY Enable this policy: Checked
But i then still see traffic coming through as if it did nothing. I've also tried using IP ranges of 45.141.84.162-45.141.84.162 and that has done nothing as well. So far the only way I've seen to actually stop an IP address is to ban the IP.
FortiView -> Traffic From WAN -> Sources Filter on Source and IP Right-Click on the IP and select Ban IP I can then see the banned IP under Monitor -> Quarantine Monitor. But even then I can only ban a single IP, i can't ban a netblock. Is there a better way of going about this?
Solved! Go to Solution.
You just need to set the "match-vip enable" setting in your Deny rule.
[ol]Your Deny rule will now match inbound traffic that matches any of your VIPs.
Alternatively you can set the destination of your Deny rule to all of your VIPs instead of "All". I know it's a bit counterintuitive but the problem is that inbound traffic destined for your VIP doesn't match the "All" destination. That's why your current rule is still allowing traffic through.
This is only only necessary for WAN to LAN IPv4 rules where NAT (VIPs) are involved. For IPv6 deny policies or VLAN-to-VLAN deny policies this isn't necessary.
Reference: https://kb.fortinet.com/kb/documentLink.do?externalID=FD33338
Local-in Policies is a third method you can use to block traffic as Toshi mentions.
Russ
NSE7
Do you have VIPs and policies to allow traffic from the wan1 to internal? Then this policy should work as long as you placed it at the top of policies.
Instead, if you want to block traffic into the FGT without any allow policies in place, you need to use local-in policy instead. You might need to use CLI to configure it though. It can block any login attempt via HTTP/HTTPS/SSH, etc. as well as VPN attempts into the FGT. You can find many config examples on the internet with some key words like "fortigate local in policy".
Toshi,
We have lots of port forwards for RDP but nothing beyond that in the VIP (i assume you mean Virtual IPs?). I did have it placed at the top of the policies (please see attached). But as I said, i still saw the IP coming through and it didn't stop until i banned it.
I've never heard of a "local-in policy", i will take a look though. As I'm still fairly new to Fortinet/Fortigate, is CLI the preferred way to configure this device? The UI doesn't not seem like it was organized by a sane person.
You just need to set the "match-vip enable" setting in your Deny rule.
[ol]Your Deny rule will now match inbound traffic that matches any of your VIPs.
Alternatively you can set the destination of your Deny rule to all of your VIPs instead of "All". I know it's a bit counterintuitive but the problem is that inbound traffic destined for your VIP doesn't match the "All" destination. That's why your current rule is still allowing traffic through.
This is only only necessary for WAN to LAN IPv4 rules where NAT (VIPs) are involved. For IPv6 deny policies or VLAN-to-VLAN deny policies this isn't necessary.
Reference: https://kb.fortinet.com/kb/documentLink.do?externalID=FD33338
Local-in Policies is a third method you can use to block traffic as Toshi mentions.
Russ
NSE7
Thanks TecnetRuss. I was actually testing this with my FGT and got the same symptom coursevector was experiencing. Then my flow debug was showing the FGT was examining VIP first before checking the policies. Then allowing it by ignoring the deny policy. My solution was to set the exact same VIP policy except specifying the source I wanted to deny and change the action to deny. Then place it above the original VIP policy. It worked as intended,
I was about to explain this and suggest "wait for others for a better solution". I'm guessing "set match-vip enable" is doing exactly the same ... checking VIP with the deny policy then examining the action.
I've learned one thing new today.
TecnetRuss,
Ok, i think i understand what you're saying. I agree it is counter-intuitive, maybe they should add a checkbox to the GUI for that? Or did they add it in later firmware? I know the one I'm talking about is old, running 5.6.3. But i checked my other router running 6.4 and still don't see anything like that. Can you let me know if it does exist in GUI form somewhere?
No, unfortunately there isn't a GUI option to enable the "match-VIP" property in 5.4, 5.6, 6.0, 6.2 or 6.4. I agree it would make sense to show that in the GUI. If you want to use the GUI only then you'll have to get in the habit of setting the destination of your Deny policies to be your VIP(s) instead of "All", but the problem with that method is that, unlike "match-VIP" which matches all your VIPs, when you add another VIP Allow policy you'll have to remember to add that VIP to the destinations of your Deny policy or policies also.
Russ
NSE7
Understood and I think I'll stick to the CLI method for the reasons you outlined. I don't want to have to update it each time a new Virtual IP is created. Thanks for your help!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.