Country Blocking and SMTP traffic

My approach:

1. If you have a small home network or a tiny business network, you may be able to review all of your logs visually.   I am assuming that most networks will generate logs that are too big for reliable review using visual methods.
   
   
2. Begin the country blocking rollout with two assumptions:
   1. The network is currently clean, so existing traffic is harmless (but not necessarily essential.)
   2. We have no need to communicate with high-risk country X, so we should block future traffic to or from there
      
      
3. It would be immediately useful to capture your existing traffic to prove those assumptions.   Web logs can do this if you have one or both proxies enabled, but the firewall logs cannot.   So the launch sequence involves (a) deploying Web Proxy with logging, (b) reviewing the logs to see if you have any allowed traffic with country X, and (c) implementing appropriate exceptions for the desired traffic.
   
   
4. You could, of course, skip step 2 and proceed directly to blocking country X.   The firewall log will show anything blocked because of country blocking, but not the country name.  If you have only blocked one country, this is easy.   If you block more than one country at once, it gets more complicated.
   
   
5. Once you start blocking country X, it becomes necessary to see what is blocked, then evaluate whether it should remain blocked or be whitelisted.   If a whitelist is needed, you also need to determine the scope of that whitelist.   Figuring out the appropriate whitelist entry can be challenging.
   
   
6. The bigger problem with the firewall logs is when you see a blocked connection from 192.168.1.15:10101 to 215.14.99.33:45454.  What installed application or business function does this represent?  Reverse DNS is worth checking, but often is of little value.    If it is web traffic that you can capture in the web logs, the URL information is much more useful .  For Windows PC, running "netstat -a -b -n" may help with this process, if the originating process is still active when you do your check.
   
   
7. Within the web logs, the challenge is to separate user-initiated browser traffic from everything else.   As I indicated earlier, "everything else" is a lot more stuff than I ever expected, and it often uses IP addresses instead of URLs.   So if your Antivirus software is blocked because it cannot connect to 99.99.99.99 and 201.201.101.101, what is the complete list of addresses that it will try in the future?   I found that using both proxy modes was a big help, because most browser traffic used the standard proxy, and most non-browser traffic use the transparent proxy.

At this point, you start discovering that Microsoft telemetry is sending a lot of data to *nexus*.live.com on servers scattered all over the world.   Should this be always allowed, always blocked, or allowed on the occasions that it picks an allowed country.  Web sites that you trust are using tracking services and content networks that pull data from all over the world.   It is easy to hate tracking services, but how do you predict whether blocking the foreign component will break a website that your user needs?

It is messy, but possible.   I have been surprised by how rarely our users notice and complain.

To cut things short. I have nothing in contrary  with your approach, BUT
The question was about allowing one service or port, no web no webcam, blogs, vpn etc from/or to that country!

Here a Screenshot of my Firewall Log for Port TCP/3389 (I suppose you know what it is and has nothing to do with other services, just Firewall)

This Port its not even open in my side

Sorry.  Not the first time that I have been told my long answer did not address the correct question.

So I think the correct question is:

You want to block one device (the DVR) from reaching China, and you know the port that it uses.

Ideas:

• Turn on transparent web so you know whether it is using a fixed URL, variable URL, fixed IP, or variable IP  (as well as whether the port is fixed, which sounds likely).
• It will help for the DVR to have a fixed IP.   I think UTM can do this by assigning an IP to a MAC address.   If addresses are assigned somewhere else, look for a way to create a DHCP reservation.
• If the destination address or destination port is fixed, you should be able to create a firewall rule to block traffic from <DVR source IP> to <any>:<known port> or <known ip>:<any port>.  (This does not require country blocking).
• To do country blocking for everything except port 9999, you would have to create service objects for 1:9998 and 1000:65535.   Then create a country blocking exception for those port ranges.

One question
I have to much SMTP attempts to relay from my IP, from one Country.
Should i see web logs etc. ? My DHCP doesnt give IP to not known MAC's

We are seeing this as well.   There is also a huge spike in password guessing attacks in remote access devices.  

Hopefully your UTM does not allow authenticated relay at all, and only allows unauthenticated relay from your internal mail servers.  If this is true, the attacks will never succeed, and they can be ignored.   Nothing can be done to prevent their packets from arriving.   To minimize overhead, you could disable logging of those failures.

The more important defense is 2factor authentication for remote access, probably coupled with country blocking for incoming traffic to your remote access ports.