I need some help w/ the Geo-IP blocking feature. Either its not working properly or I didnt set it up correctly.
I have a peplink balance 20x with a windows server 2016 behind it. This runs my company’s various software databases and programs for remote use. Since my operations are US based only, I do not need or want people who are international to be able to access it. So i blocked IPs from all other countries via the in-control portal.
Problem is, hackers from other countries (namely russia), are still able to see my server and are attempting to login to it. I can see this in the event viewer on windows server, which gives me the IP address of the person whom attempted to login, albeit unsuccessfully since they cant guess the user/password and I have 2FA…
So why are they still able to see the server even with their country’s IP addresses supposedly blocked with the traffic policies I have in place on the router?
I may file a support ticket on this as well but wanted to document it here. Please see pics below…
Can you post what the firewall rule looks like as it is inside the balance20x?
This shows what you setup via ic2, but I don’t know if this has been downloaded to your 20x.
well i may have figured it out myself. I didnt notice the “default” rule at the bottom before. and when i clicked the ? info button, it says “If an inbound IP session does not match any of the rules listed, the Default rule will be applied.”
My default rule was set to allow.
I have since changed it to deny.
i will keep an eye on the server event viewer and see if the hacking attempts have stopped…
Please update this thread when this problem is resolved. My 20X exhibits the same problem.
A firewall rule, inbound or outbound, with a smaller set of regions will work as expected. The name of each country/region will be explicitly written in the ‘Source’ column. However, when too many regions populate the list, something breaks and the value in the ‘Source’ column reads ‘Unknown.’ When this happens, the rule does not function, despite what is displayed in InControl2. I do not know the exact number of regions at which this happens.
It seems more regions are blocked than are allowed, so perhaps it would be better to set the ‘Action’ of the Default rule to . Then, make rules for regions from which access is permitted. Allow few rather than block many.
I just connected my B20x to IC2 and added 2 country blocks, Russia and China. I enabled logging so will see if anything comes up.
Some will argue that country blocks won’t stop professional hackers, since they will most likely conduct their attacks from different hop locations globally using VPNs.
Also, IoT devices phone home (eg China?) may not work properly… Id argue at worst they’re not sending telemetry to their mothership, so it cant all be bad.
The inbound firewall rules only apply to the following types of traffic:
Inbound drop-in WAN traffic where the WAN is in drop-in mode
Inbound traffic that is defined in Port Forwarding
Inbound traffic that is defined in Inbound NAT Mappings
In my case, country blocks won’t apply since none of the above applies to me yet. I will be port forwarding to a helium hotspot miner in the future so I’ll be revisiting this then.
Support accessed my router and discovered that there is a bug that causes the rules to fail when there are more than 200 IP addresses configured for geo-blocking.
they are working on a fix but for now the work around is to remove all the country blocks(I had every country but the US blocked), set default rule to deny and then add an allowed rule for every country that should have access.
I have implemented this today and will see how it works…
yeah im sure some hackers will get through almost any security. Just the reason to have multi-layered security. I have Duo security 2FA for my server so even if they somehow get past my SD-WAN rules, they wont be able to get in without a pushed authentication code from DUO which would be impossible for them to receive.
It’s not the number of IPs but number of Geo IP rules (Geo locations) that created for the device. Bug maybe triggered if you added more than 70 Geo locations. This will be fix for coming firmware 8.1.3 release (Reference ID: 25184).
Temporary solution is to use blocking method to block the counties that you are not allow access and keep the Geo locations below 70. This will be fix for coming firmware release.
. Then, make 
rules for regions from which access is permitted. Allow few rather than block many.
