Fortinet Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
druber
New Contributor II

What is the proper way to block inbound packets from specific hosts?

So, kinda new here.  I wanted to block traffic inbound from, say, russia, china and korea.  I set up a firewall rule as wan/lan/GEO/all (where GEO was the geographic list).  No traffic.  So I added another entry as a whitelist from any US traffic, as a positive test.  Still nothing.  Tried changing the dstinf from LAN to any (since I thought maybe the new rule - at the top of the rules list - didn't have a destination, so maybe LAN was wrong.)  Still nothing.  Finally, out of desperation, I created a VIP group, and added the various VIP entries (for my mail server, PBX server, etc...)  Lo and behold, the whitelist entry worked.  So I did the same thing for the GEO-IP blocklist, and that is also now working.  My question: is this really necessary, or am I missing something crucial here?  I've gone through the fortios 6.4.6 manual and saw nothing that spoke to this.  FWIW, I am set in profile mode, not policy mode...  I'm used to pfsense, where nat happens before acl, so you need to check the destination as the internal IP.  But in this case, since I'm trying to block anything from GEO-IP, why didn't 'all' work as a destination?

 

Also, if this IS the correct way to do things, I assume the GEO-IP block rule should be entry #1?

druber
1 Solution
lobstercreed
Valued Contributor

This is standard behavior in the FortiGate.  It can easily be fixed by setting "match-vip" to enable in the CLI for the deny policy in question.  This is a very old article that addresses what you're describing:  https://kb.fortinet.com/k....do?externalID=FD36750

View solution in original post

6 REPLIES 6
Toshi_Esumi
Esteemed Contributor II

You don't have any out-to-in policies to allow any pass-through traffic to inside, do you? But want to block random VPN/hack attempts to the outside port(s) of the FGT, I assume. Then you need  to use local-in-policy.

I found a very convenient article so that I don't have to type more.

https://conetrix.com/blog/fortigate-local-in-policies-and-geoblocking

 

druber
New Contributor II

toshiesumi wrote:

You don't have any out-to-in policies to allow any pass-through traffic to inside, do you? But want to block random VPN/hack attempts to the outside port(s) of the FGT, I assume. Then you need  to use local-in-policy.

I found a very convenient article so that I don't have to type more.

https://conetrix.com/blog/fortigate-local-in-policies-and-geoblocking

Not sure what you mean by your first sentence?  Anyway, I DNAT several services to inside hosts.  I want to block anything coming from countries specified in the GEO-IP list.  I will check the local-in article you posted.  Thanks!

druber
Toshi_Esumi
Esteemed Contributor II

What I meant was routing a public subnet into your network. But if you had DNAT/VIP polices for specific services/ports to allow inbound traffic, and that's all you're concerning about, you've gotten what you wanted already. Local-in-policy would work for other attemps for the services FGT is offering, like HTTPS/SSH admin access, IPSec/SSL VPN, SNMP and so on, which are terminated by the FGT.

druber
New Contributor II

toshiesumi wrote:

What I meant was routing a public subnet into your network. But if you had DNAT/VIP polices for specific services/ports to allow inbound traffic, and that's all you're concerning about, you've gotten what you wanted already. Local-in-policy would work for other attemps for the services FGT is offering, like HTTPS/SSH admin access, IPSec/SSL VPN, SNMP and so on, which are terminated by the FGT.

Makes sense, thanks.  Yes, in fact I have a dynamic residential IP, and there are zero services on the FGT itself to be accessed from the WAN.

druber
druber
New Contributor II

Almost forgot: do you have any idea why it didn't work when I gave all for the Destination, and required a VIP or VIP group?  Bug?

druber
lobstercreed
Valued Contributor

This is standard behavior in the FortiGate.  It can easily be fixed by setting "match-vip" to enable in the CLI for the deny policy in question.  This is a very old article that addresses what you're describing:  https://kb.fortinet.com/k....do?externalID=FD36750