Block VPN Traffic by Country

[PhoneBoy]

VPN traffic (Site to Site or Remote Access) is currently accepted by Implied Rules, meaning you cannot use Access Policy or legacy GeoProtection to block VPN access from specific countries.

@Aleksandr_Nosit pointed out to me that DOS Rate Limiting rules can be set by country, which will block all matched traffic (including VPN) before implied rules.
Here are a couple examples (see sk112454 for other possibilities)

Option 1: allow access from specific countries, block the rest

“X.X.X.X” – is gateway external interface IP address:

Bypass rules:

fwaccel dos rate add -a b source cc:EE
fwaccel dos rate add -a b source cc:LV
fwaccel dos rate add -a b source cc:FI
fwaccel dos rate add -a b source cc:SE
fwaccel dos rate add -a b source cc:DK

Block “rest of the world” rule :

fwaccel dos rate add -a d -l a service any source any destination cidr:X.X.X.X/32 pkt-rate 0

Option 2: block specific countries

This will block China while allowing other countries:

fwaccel dos rate add -a d -l a service any source cc:CC destination cidr:X.X.X.X/32 pkt-rate 0

[Machine_Head]

Thanks!

Useful as some customers complain about implied rules

[PhoneBoy]

I can see this method being useful for "overriding" certain implied rules, particularly if the dos rules are very targeted.

[the_rock]

Thanks phoneboy, thats super useful info, for sure.

Andy

[CheckPointerXL]

Hello PhoneBoy,

about the statement:

Block “rest of the world” rule :

fwaccel dos rate add -a d -l a service any source destination cidr:X.X.X.X./32 pkt-rate 0

Did you miss "any" after "source" ? or maybe you can avoid to specify "source" word for "any" because of it is default

another question, did this configuration survives to JHF/major upgrade installations ?

[PhoneBoy]

You are correct, I was missing an "any" there and have fixed it in the original post.
If I remember correctly, fwaccel dos rules are persistent across reboots/upgrades.

[Chris_Atkinson]

sk180527 & sk126172 will be helpful for anyone attempting similar using VSX.

[the_rock]

@PhoneBoy So sorry to reply to this almost a year later, but just need to confirm something. Is there any limitation for this when you create VMSS CP fw on Azure? My colleague and I tested it with public IP assisnged and we blocked CA (country code for Canada) from your 2nd example to external IP of the fw, but we could still create and connect to VPN site.

Thanks in advance.

Best,

Andy

[PhoneBoy]

In Public Cloud, it's entirely possible we're not seeing the real source IP (depending on the exact configuration).
You should confirm precisely what IP the gateway is seeing with tcpdump or similar. 

[the_rock]

I really have gut feeling its because even though ifconfig shows public IP, BUT, when I look at fw topology in smart console object, that IP is NOT listed there...I will talk to one of my colleagues next week who is way better with Azure than myself, but logically, thats what stands out to me.

Andy

eth0 Link encap:Ethernet HWaddr 00:0D:3A:F4:98:C4
inet addr:10.2.0.4 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::20d:3aff:fef4:98c4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:604471 errors:0 dropped:0 overruns:0 frame:0
TX packets:598227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:466812315 (445.1 MiB) TX bytes:142959965 (136.3 MiB)

eth0:1 Link encap:Ethernet HWaddr 00:0D:3A:F4:98:C4
inet addr:52.229.98.249 Bcast:52.229.98.249 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

eth1 Link encap:Ethernet HWaddr 00:0D:3A:F4:9E:31
inet addr:10.2.1.4 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::20d:3aff:fef4:9e31/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:2424 (2.3 KiB)

[VikingsFan]

Wouldn't there be an Option 3, which we're doing currently: Disable the Implied Rule and manually build out your accept rules/block rules?  Might not be preferred by most but it gives us more granular control and able to do everything within the access layer instead of CLI.

[the_rock]

See if this post I made last year helps. I definitely validated it works 100%, but you know how it goes with Azure subscription, even when devices are powered off, they still charge you 🙂

Andy

https://community.checkpoint.com/t5/Remote-Access-VPN/Geo-VPN-blocking/m-p/214040#M10593

[the_rock]

FWIW, just my PERSONAL opinion, I would NOT be disabling implied rules. I had seen people do this before and more often than not, down the road, it can lead to more issues.

Thats just my experience...

Andy

[VikingsFan]

Agree.  We did have some bumps from disabling a handful of the implied rules but now have the ruleset pretty solid with no issues (to my knowledge). 🙂  Could always manually build out the rules from this list too, which is what I used for checking some of mine: https://support.checkpoint.com/results/sk/sk119497

The change to the Geo Blocking and removing it from Smart Console and not working with access rules was one of the driving factors to look at removing implied rules.  Can't remember exactly but even with setting that configuration you referenced we were seeing countries getting through for VPN activity.  I didn't disable ALL the rules but focused on the remote access ones and also some of the SMB ones which we don't service on this gateway.

The ones we disabled are attached if interested.

[the_rock]

Speaking of geo blocking, did post I made last year that I posted in previous response help? Not sure if makes sense, but definitely worked when I tested it.

Andy

[VikingsFan]

It makes sense and unfortunately I did not find that during my testing last year when implementing the cluster.  Looked at my notes and I had found this SK: https://support.checkpoint.com/results/sk/sk180808 but don't believe it worked as expected which is why I started unchecking implied rules.  Things are stable now and don't think we'll revert anything but would have been great if I had seen your post.

[the_rock]

Hey, no worries, all good, as long as things are stable.

Andy

[CheckPointerXL]

i was able to control access by country into access policy after following https://support.checkpoint.com/results/sk/sk105740

[chethan_m]

Much needed.

Thank you!

[Timothy_Hall]

The country code for China is CN, not CC in your Option 2 command.  The inhabitants of the Coco/Keeling Islands took offense.  🙂

[the_rock]

I recommend that place, people are so sweet! By the way, never thought about it, till I saw your post, but I probably met half the country there 🤣🤣

[Timothy_Hall · Accepted solution]

One limitation of blocking all ports from a country, as shown above, is that if the outbound traffic is Hide NAT'd behind the gateway's main address, all communication of any kind with that country will be impossible.  The following statements block only the specific ports required for RAS IPSec VPN (and Mobile Access Blade) while still potentially allowing other communication with that country:

X.X.X.X - external gateway address
line 1 = IPSEC, line 2 = Site/Topology Download, line 3 = Visitor Mode/MAB, line 4=IKE, line 5 = NAT-T

fwaccel dos rate add -a d -l a service 50 source cc:CN destination cidr:X.X.X.X/32 pkt-rate 0
fwaccel dos rate add -a d -l a service 6/264 source cc:CN destination cidr:X.X.X.X/32 pkt-rate 0
fwaccel dos rate add -a d -l a service 6/443 source cc:CN destination cidr:X.X.X.X/32 pkt-rate 0
fwaccel dos rate add -a d -l a service 17/500 source cc:CN destination cidr:X.X.X.X/32 pkt-rate 0
fwaccel dos rate add -a d -l a service 17/4500 source cc:CN destination cidr:X.X.X.X/32 pkt-rate 0