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

[Gojira]

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)