Country blocking exception rule with DNAT

Hi

When I first attempted obtaining a 'Lets Encrypt' certificate, the process failed, then I spotted someone here mentioning country blocking (I had blocked traffic from most, including the USA; silly me for not realising that) so when I then let the USA through, my problem was resolved (and I got my certificate). Further experimentation revealed that adding an exception (see below screen shot) didn't permit me to request a completely new certificate, but it did permit me to refresh the existing one (whereas switching that exception off prevented same) so the format of the rule I created would appear to be working.

To do so, I first created a host (in the UTM network definitions section) with the domain I wished to create the exception for (so in your case, you could use the IP address) and being lazy, I just created the exception for 'any' (but you could instead just add the port of your choice) and the resultant rule looks as shown below (and I have double clicked on the host to show it's configuration, too):

EDIT: Please note that the above rule is incorrect (please see the table posted by jeffshead and further discussions on same); for an exception to a remote host on an external network, you should not include the country in which it resides (the country selection list must be left empty or it prevents the exception from working). I have a revised image a few posts down, showing a successful test (using Shields Up - the server being based in the USA - to probe a port on my server).

Obviously, I don't need (nor wish) a DNAT rule for the Lets Encrypt server, but I do have a DNAT rule to permit SSH (externally and using a 'funky' port) being both permitted and re-directed to the standard SSH port on a Raspberry Pi sitting on my own network (it's normally left disabled; I created it to briefly give a friend access the Pi, in order to perform an interesting experiment; long story) and that looks like the below (with the automatic firewall rule creation box ticked) so that at least shows an example of one that works:

(Obviously, clicking on images will show them full sized)

With the above rule, the funky port was created as a new service (called 'Beacon - Admin') and the Raspberry Pi within my own network is the host called 'Beacon R Pi'. When the above is enabled (and let's say, for the sake of argument, the funky port (the service 'Beacon - Admin') was 12345, my friend then successfully accessed the Pi (from a Linux terminal) by typing the below:

ssh mydomain.ddns.net -p 12345

So, it all seemed to work as expected, but unfortunately, I don't know anyone who currently lives in another country (well I do, but nobody who knows what SSH means) and I don't have a VPN account, otherwise it would be interesting to combine the above SSH with a country blocking exception for the 'Beacon - Admin' funky port, but that said, the aforementioned tech friend is heading to the USA in a couple of weeks, so I will get a chance to test it quite soon.

Hope that's maybe of some use.

Kind regards,

Briain

Thanks for sharing.

Your DNAT is essentially the same as mine except for me creating my firewall rule, manually and you redirecting all IPv4 Internet traffic. I will try with automatic rule but I don't see how that will help since the log shows Country Blocking is dropping the packets.

I used to add USA to the region for my Country Blocking Exceptions but after reading a couple of threads and the help file, it appears region should be blank. I think this change came about with a recent release.

I did test this particular exception with and without USA. It made no difference. I believe the reason why yours is working and mine is not is because your exception is allowing any service whereas I want to limit the exception to a single service/port.

Thank you very much indeed for sharing the above table; I was not aware of the different requirements to suit these different scenarios, so that is very useful information to know. My 'Remote host (external network)' to Lets Encrypted one worked, (even though I had defined the country) so I will now remove USA from that exception (and try refreshing the certificate).

Interesting thought about the 'any' enabling it to work (when my friend visits the USA, I will try disabling that exception and creating a bespoke one, only permitting access from that funky 'Beacon-Admin' port) but if that is the reason why my exception works and your one doesn't, I wonder if using 'any' would be also acceptable for your own situation (given that you're only permitting 'any' port from a pre-defined IP address in that remote country) as obviously, any other port access attempts from that same remote IP address will still be blocked by the UTM's NAT (as you'd still only have the DNAT rule permitting access to your single, bespoke port) and indeed, only that IP address is permitted to skip past the country block, so it would seem to be pretty well tied down (unless you have other open ports and the remotely located site also knows about them; that could indeed be a problem if using the 'any' port in country blocking exception, though relying only on just the country blocking in that particular scenario might not be a very robust - in terms of depending upon it always working - blocking solution, I'd have thought)? 

Thinking aloud, even if that was the case, I wonder if one could perhaps mitigate it by also creating drop rules (from that IP address to the other opened ports)? I'll have to drink more coffee and ponder that one. :-)

Bri

Thank you very much indeed for sharing the above table; I was not aware of the different requirements to suit these different scenarios, so that is very useful information to know. My 'Remote host (external network)' to Lets Encrypted one worked, (even though I had defined the country) so I will now remove USA from that exception (and try refreshing the certificate).

Interesting thought about the 'any' enabling it to work (when my friend visits the USA, I will try disabling that exception and creating a bespoke one, only permitting access from that funky 'Beacon-Admin' port) but if that is the reason why my exception works and your one doesn't, I wonder if using 'any' would be also acceptable for your own situation (given that you're only permitting 'any' port from a pre-defined IP address in that remote country) as obviously, any other port access attempts from that same remote IP address will still be blocked by the UTM's NAT (as you'd still only have the DNAT rule permitting access to your single, bespoke port) and indeed, only that IP address is permitted to skip past the country block, so it would seem to be pretty well tied down (unless you have other open ports and the remotely located site also knows about them; that could indeed be a problem if using the 'any' port in country blocking exception, though relying only on just the country blocking in that particular scenario might not be a very robust - in terms of depending upon it always working - blocking solution, I'd have thought)? 

Thinking aloud, even if that was the case, I wonder if one could perhaps mitigate it by also creating drop rules (from that IP address to the other opened ports)? I'll have to drink more coffee and ponder that one. :-)

Bri

I need to allow SSH access to a third-party vendor. The problem is that they are complaining about the failed attempts and they are going to start billing for their time if they fail to connect next time. They cannot give a tight window so if I disable Country Blocking, it would have to remain disabled for days.

Hi

I've just done some more testing and have found some interesting results (and yes, your double port entry does work, as per my last test) so I'll write it up with pictures for the benefit of anyone else who's following all of this.

As mentioned above, I used a single port (8000) in the country blocking exception and requested a port probe (on 8000) from GRC's Shields up service and it seemed to work just fine, but that was pointing to a web server reverse proxied by UTMs WAF service.

Second test was to disable the virtual server (in the WAF) and instead create a DNAT rule, but this time also containing a translation from [public] port 20000 to [internal] port 8000, so the one that Icecast server uses; the new DNAT rule is shown below:

I then accessed the country blocking exceptions section and disabled my current rule, then I created a bespoke rule (only permitting the Shields Up server to access port 20000) as is shown below:

This time, when I tried the port probe it didn't see my server; Shields Up reported it to be in stealth mode, so it was not working.

In the above exception, I then removed the 'Port 2000' and instead added 'any' and this time, Shields Up reported that port 20000 was open (just to be complete, amended rule shown below):

So, it looks like you can add a single port to a country blocking exception rule and it facilitates access to a server reverse proxied by the WAF, but if you wish to permit access to a port opened (and translated) via a DNAT rule, it seems you have to use the 'any' option in your country blocking exception rule.

However, I ended up replicating your own experiment and yes, it does indeed work! As mentioned before, the internal Icecast server is on port 8000 and the DNAT translates 20000 to 8000, so I again removed 'any' and instead add both the external port (20000) and the internal port (8000) services to the country blocking exception rule, and this time, the Shields Up test (probing port 20000) now successfully found the server, so perhaps that is yet another option for you to consider (than just using 'any'). Note that as you would imagine, other port - in my case, 8000 - remains blocked to external traffic (and I did check that, just to be certain that all was okay):

Just to complete the family photo album, below shows the revised country blocking exception rule that successfully enabled Shields Up to probe port 20000:

Hope all the above tests and resultant information might be of some use for others who need to do something similar (and I am not sure why it needs the internal port added to the exception rule, but perhaps that is an unexpected consequence of many UTM functions being effectively 'directionless'; just as a wild guess)?

Kind regards,

Briain