This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Transparent Proxy+Country Code blocking and allowing all inbound smtp

Hello UTMers!

 

Quick question for the geniuses here (I'm talking to you balfson!): What is the proper design of a country code exception that allows SMTP inbound and outbound from all countries? I have seen a bunch of posts on these forums...some say the internal address needs to be added, others say the wan address also needs to be added (I assume it would be the IP that the MX record responds on) but I cannot get either to work. I do have the transparent proxy enabled as well as country code blocking enabled for almost all countries (disable access both ways).

 

My current rule looks like this:

Skip blocking of these regions : ALL COUNTRIES SELECTED

For all requests COMING FROM THESE

Hosts/Networks- Internal network address + External IP that MX record responds on (External WAN address).

Using SMTP.

 

What am I doing wrong here?



This thread was automatically locked due to age.
Parents
  • My notes on country blocking exceptions:

    • If you are exempting a remote object, the country list must be left empty.   UTM already knows what sources to exempt, so including a country list only confuses things.
    • If your are exempting a local object, the country list must be supplied.   Without a country list, it would have no idea what traffic to exempt.
    • If you are exempting a non-transparent resource, you should only have to exempt the UTM address to which the resource is applied.
    • If you are exempting a transparent resource, it may be helpful to exempt both the inbound address and the interface on which the traffic applies.   Not certain on this, but exempting both objects is not likely to create a security hole.

    Limitations of country blocking

    • The algorithm may produce inconsistent results, where the same URL and IP address are associated with different countries at different times.
    • A surprising number of entries may have no country identification.
    • The most likely result of these issues is that they may allow traffic through that you had intended to block.   The reverse may be possible if the country association floats from an allowed country to a blocked country.
    • These problems have been escalated and confirmed by development.   A fix should be forthcoming, but I have no information about which release will include it.
Reply
  • My notes on country blocking exceptions:

    • If you are exempting a remote object, the country list must be left empty.   UTM already knows what sources to exempt, so including a country list only confuses things.
    • If your are exempting a local object, the country list must be supplied.   Without a country list, it would have no idea what traffic to exempt.
    • If you are exempting a non-transparent resource, you should only have to exempt the UTM address to which the resource is applied.
    • If you are exempting a transparent resource, it may be helpful to exempt both the inbound address and the interface on which the traffic applies.   Not certain on this, but exempting both objects is not likely to create a security hole.

    Limitations of country blocking

    • The algorithm may produce inconsistent results, where the same URL and IP address are associated with different countries at different times.
    • A surprising number of entries may have no country identification.
    • The most likely result of these issues is that they may allow traffic through that you had intended to block.   The reverse may be possible if the country association floats from an allowed country to a blocked country.
    • These problems have been escalated and confirmed by development.   A fix should be forthcoming, but I have no information about which release will include it.
Children
No Data