Please occasionally check the Changelog at the bottom of this post to see if there have been corrections/additions  since you last were here.

Over the years, I've accumulated suggestions from dozens of folks here. I made notes in my personal Tips-n-Tricks list, but it was only in February of this year that I started making a list of the "Rules" we all had established here. I intend to continue to maintain this list, so if you see one that's inaccurate or imprecise, please post in this thread or send me a PM.

The Zeroeth Rule:

Start with a hostname that is a unique (not used for anything else) FQDN resolvable in public DNS to your public IP. If you didn't do that, use slickone27's trick to get CAs, certificates, hostname entries, etc. all aligned; it will save you hours and frustration.

Rule #1:

Always check the logs!  For example, when you disabled Intrusion Prevention, you only disabled Snort - you did not disable the items on the other tabs! (Many people are tripped up by UDP Flood Protection which is logged in the Intrusion Prevention log file.  This is often the cause of bad voice-quality with VoIP and unreliable IPsec connections that don't terminate on the UTM.)

Whenever something seems strange, always check the Intrusion Prevention, Application Control and Firewall logs. If 'Advanced Threat Protection' on the Dashboard is not zero, check that log also. Hint: If this didn't help, you likely have a routing problem. In that case, check #3 through #5.

Rule #2:

Do you wonder why traffic is allowed through even when you have an explicit firewall rule blocking it?  In general, a packet arriving at an interface is handled only by one of the below, in order (see images at the bottom):

  1. the connection tracker (conntrack) first
  2. then Country Blocking
  3. then the 'ICMP' tab in 'Firewall': Traceroute and Ping are regulated on the 'ICMP' tab.  The "All" service only includes TCP and UDP - none of the other IP protocols are included.
  4. then Intrusion Prevention (see the images below to see that IPS actually can happen in several places but happens only once!)
  5. then DNATs*
  6. then VPNs
  7. then Proxies (except the SMTP Proxy in Transparent mode which captures traffic forwarded by a DNAT)
  8. then manual Routes and manual Firewall rules, which are considered only if the automatic Routes and rules coming before hadn't already handled the traffic
  9. and, finally, Application Control.

    * A "blackhole DNAT" should be to an IPv4 address in or to one in 100::/64 for IPv6.

Rule #2.1:

What happens with outbound traffic?

  1. The connection tracker takes precedence over any other outbound rules so that response packets always leave from the IP and interface the request arrived on.
  2. Multipath is applied before SNAT/Masq.  Note that the UTM Proxies skip SNAT/Masq and assign a public IP as the source of packets each handles.  Unlike with the other UTM Proxies, HTTP/S Proxy traffic can still be identified by Multipath rules as to its private, internal source-IP.
  3. SNAT takes precedence over Masquerading, so it happens first, causing the packet to not qualify for any masquerading rule.

Before the packet leaves, ATP will block it if the destination is on a list of malicious IPs.

Rule #3:

Never create a Host/Network definition bound to a specific interface. Always leave all definitions with 'Interface: <<Any>>'.

There are two known exceptions

  • Beginning with V9.4 and the introduction of STAS (Sophos Transparent Authentication Suite), the definition of the STAS AD domain controller Host must be bound to the interface for the subnet containing the DC.  Note that you will need an additional Host definition with 'Interface: <<Any>>' if you want to make a firewall rule for the DC.
  • An advanced use of Uplink Monitoring can affect how Uplink Balancing functions when monitoring hosts are specified: "If a selected host is bound to an interface, it will only be used to monitor this interface."

Rule #3.1: Other solutions to routing problems (not seeing any blocks, but not getting responses) include:

  • Devices in the LAN must have the IP of "Internal (Address)" as their default gateway.
  • Never connect two NICs into the same, physical Ethernet segment unless bridging or creating a LAG.
  • When adding an interface, don't forget the Masquerading rule for the new network behind the UTM.

Rule #4:

When creating DNATs for traffic arriving from the internet, in "Going to:" always use the "(Address)" object created by WebAdmin when the interface or the Additional Address was defined.  For any Traffic Selector to apply to packets with a destination of an IP on the UTM, the corresponding "(Address)" object must be used.  Under the covers, it's iptables that does the work.  Using "Any" or a normal Network/Host definition causes the Traffic Selector to apply to packets in the FORWARD chain.  The "(Address)" objects are bound to the interface on which they're defined, so that causes the Selector to apply to the INPUT chain.

Rule #5:

In NAT rules, it is a good habit to leave a field blank when not making a change. In the case of a service with a single destination port, this makes no difference. In the case of a service with multiple ports, or a Group, repeating the service makes the NAT rule ineffective.

Rule #6:

There are only six reasons to sync users from AD to the ASG/UTM:

  • The user is to be added to 'Allowed Administrators' or given a 'Role' on the 'Access Control' tab in 'WebAdmin Settings'.
  • The user needs access to the User Portal.
  • The user should be able to log on to a Remote Access VPN that uses certificates to authenticate the user.
  • Email Protection is enabled and the user should receive Quarantine Reports and be able to manage personal black/whitelists.
  • You want to do Reporting by Department for Web Protection (please vote for and comment on Reporting: AD/eDir Backend Group "Departments").
  • You want to use the Authentication Agent to populate "username (User Network)" objects.

There's no other reason to sync users to WebAdmin - certainly not for AD-SSO.

Rule #7:

If you have slow throughput and/or ifconfig shows errors, collisions, etc., try these steps, in sequence, until your problem goes away:

  1. If you have a Realtek, Marvel or 3Com NIC, skip to the last step.
  2. Confirm that 'Interfaces & Routing >> Quality of Service (QoS)' is not limiting bandwidth. Also confirm that 'TCP window scaling' is enabled on the 'Advanced' tab of 'Network Protection >> Firewall'.
  3. Edit the interface definition, and, in the 'Advanced' section, set the MTU to 1350. If that works, check with your ISP to help find the largest setting that works. If this doesn't work, set the MTU back to its original value.
  4. Change the Ethernet cable.
  5. If connected to a switch, change the switch port.
  6. If connected to a router or modem, change that device.
  7. On the 'Hardware' tab in 'Interfaces & Routing >> Interfaces', experiment with different settings of fixed speeds and duplex. Make the same settings on the router/switch/modem to which the interface connects. Before testing the change, reboot both devices to force them to renegotiate their connection.
  8. Move the interface definition to another eth on the UTM or replace the NIC with an identical one. If you have a Realtek, Marvel or 3Com NIC, you should replace the NIC with an Intel (NOT an Intel 82574 based NIC due to bugs from Intel that aren't fixed - the 210 series is good). Note that if you don't already have an Intel NIC, you will need to reload from ISO in order to install the driver for the new NIC

Rule #8:

Before changing the hardware the UTM runs on, go to 'Interfaces & Routing >> Interfaces' and, on the 'Hardware' tab, edit each NIC to have a 'Virtual MAC Address' that copies the existing MAC. This will cause your new NICs to be recognized immediately after the configuration is restored. The alternative is to make certain that each router/switch connected to the various NICs has cleared its ARP table:

  • When changing UTM hardware or NICs, Always power-cycle any cable modems or other devices that lock MAC addresses.
  • Some ISPs (FiOS) require calling ISP to break the lease, unless one does it manually (from the UTM console) when switching UTM hardware

Rule #9:

When a Web Filtering Filter Action changes based on Policies with Time Events, established connections like YouTube will continue to function and will not be blocked.  Use Sheldon's Trick: create a firewall Block rule for a one-minute Time Event after your policy allowing traffic is deactivated by a Time Event and one blocking traffic then handles the requests.

Cheers - Bob


Changelog: 2019-04-17 Added the information about ATP to #2.1 after stu asked a question about it; 2019-01-02 Added exception for Uplink Balancing to #3 as suggested by Toni LuCar; 2018-12-30 Deleted reference to encryption/signing from Toni LuCar;  #6 based on a comment from2018-12-28 Added #2.1 based on a question from member Davis Admin; 2018-01-03 Added a line to #3 based on a post by shaun threetwotwosix; 2017-12-27 apijnappels posted this suggestion for the * on #2.5; 2017-12-09 In #2, inserted #3 about ICMP; 2017-06-09 Replaced the flow diagram mentioned in #2 with a newer version and then put the old one back along with an older iptables version, too; 2017-05-30 In #2, - moved DNATs from #3 to #4 (after Intrusion Prevention) - I think that's right; 2017-05-20 Added the question at the top of #2 based on a suggestion from Louis-M; 2017-04-02 Reformatted #2 based on an idea from Louis-M; 2017-02-16 Changed #1 because people were ignoring notes and parenthetical remarks.  Two people today ignored my notes and -omments, turned off IPS and thought they were following the rule!; 2017-01-25 added Intrusion Prevention to #2; 2017-01-16 added parenthetical remark in #3.1 based on a comment by new member Brendan Corcoran; 2016-12-08 added #9; 2016-12-03 added by a new member; iptables information to #4 because of a question asked by new member Len Goddard; 2016-10-22 added comments to the end of NOTE on #1 and updated #3 with the exception noted by vilic in March; 2016-10-18 added NOTE to #1; 2016-05-06 added the parenthetical remark about the Transparent-mode SMTP Proxy -to #2 thanks to a report by fellow member Matthew; 2015-10-05 added hint to #1; 2015-09-25 typo; 2015-08-13 Changed #7 to numbering instead of bullet points; 2015-07-10 Bart van Kampen's tests proved that AppCtrl comes after firewall rules, so -#2 was modified; 2015-06-19 Thanks to new member jleigh5, added second line to #6 about User Portal; 2015-06-14 "unique..." added to 0-eth rule; 2015-06-11 added details on Intel NICs based on a comment from William; 2015-06-07 changed the link in #0 to work with Macs; 2015-05-25 added the first reason in #6 about WebAdmin; 2015-04-10 added link to feature request in #6; 2015-03-15 clearer wording in Zeroeth; 2015-02-03 #8 thanks to BarryG and AppCtrl in #2 thanks to FrankBarmentlo; 2014-12-24 added Country Blocking in #2; 2014-09-10 added conntrack in #2; 2014-09-09 added Advanced Threat in #1; 2013-06-10 added BarryG's masq idea in 3.1; 2013-06-08 added fourth reason to #6

  • Excellent rules Grandis Professorem of the Sophos UTM! Thank you Bob.  With over 15,000 posts, there is no doubt that you are the man!
  • Why zeroeth law?  Never seem to have issue here?
  • In reply to eganders_01:

    Excellent rules Grandis Professorem of the Sophos UTM! Thank you Bob.  With over 15,000 posts, there is no doubt that you are the man!

    Full approval with you and BAlfson (Rulz)!
    That are the most user problems and first level calls...

    Nice greetings
  • Simon, if someone doesn't follow the Zeroeth rule, it complicates configuration for most VPNs and email, necessitating work-arounds that make it difficult for someone else to help or follow as a new admin.

    Cheers - Bob
  • Thanks for the great pointers Smile
  • In reply to BAlfson:

    Simon, if someone doesn't follow the Zeroeth rule, it complicates configuration for most VPNs and email, necessitating work-arounds that make it difficult for someone else to help or follow as a new admin.

    Cheers - Bob

    We're not currently doing any VPNs with the UTM; but to get ready, any reason we couldn't just go ahead and rename the box without the factory reset?  Or is it deeper than that?

    Thank you for this Rulz list Bob.
  • Yes, you can do that, but you will run into different issues in different places - open the Help and search on hostname - you'll find 47 places where you're setting traps for yourself.  I know how to work around those issues, but I don't think there's a complete "How-To: Change your Hostname" document.

    I would set up another PC or VM and create a new config on it.  You can restore that config backup to your production device and restore a backup from the production device if the new configuration doesn't work as you want.

    Cheers - Bob
  • Can someone clarify #4?

    A Host object should be perfectly sufficient for a DNAT rule, so I think I've misunderstood something somewhere.

    The only difference between the automatically created definitions (eg "External WAN (Address)") and a Host object is that the automatically created ones are bound to an interface and you can't change that, but with a Host you can leave Interface Binding unset. This could have importance if packets are coming in on different [unexpected] interfaces but that's outside the norm.
  • Shhh, Jeff, you're right, but if they always follow Rule #4, they won't get in trouble.  You're also right that binding to an interface could help with spoof prevention, but, as long as folks haven't disabled 'Spoof protection', binding to an interface will not increase anti-spoof.

    Cheers - Bob
  • Just added 3.1 based on a post by BarryG. 

    Cheers - Bob

    Sorry for any short responses.  Posted from my iPhone.
  • I can't agree with rule 3...there are times when you don't want that host to be bound to anything but .  Doing it in "violation" of rule 3 actually makes configuration easier when you have multiple non-wan networks.
  • Hi Bob,

    Maybe you should add a rule to enable masquerading for each LAN/DMZ/WiFi network... a lot of users seem to forget that when adding interfaces.

  • some simple examples would be greatly appreciated.
  • I'm new to Sophos/astaro UTM. I'm using UTM 9.1

    I'm familiar with pro-sumer/SB router/firewalls like Netgear Pro-safe. Moving over to UTM has been a challenge. It's not the additional complexity, but the lack of quality documentation, real-world example cases, and also hidden non-obvious rules. When I found this thread via google-search, after three days of trial, error, frustration and very close to adopting the sledge-hammer approach to warranty, I was happy for the pointers. *THANKS* Although it might be worth editing/adding a little to help "the beginner" access the knowledge and good practice buried within it.

    Anyway, there might be another RULZ that I've discovered after 3 days of late nights.

    The HTTP Webserver Protection (WAF Web Application Firewall) "feature" is fantastic but I think it has hidden traps. It appears to me that the UTM WAF does not work solely by "port" number, ie, all traffic on port 80, 443, but works by sniffing for HTTP traffic/packets in addition to the port rules. This is probably a clever feature. But it means that HTTP traffic destined to another port might get inadvertently dropped/blocked.

    I succeeded getting a regular HTTP:80 webserver up and running over WAF. Great. The Rulz here helped me get the server accessible from both sides of the UTM, ie WAN access and LAN access. However, I have a second server that is a telephone PBX. The admin webconsole runs over port 5080. No matter what firewall rules, DNATing, port forwarding I did, and I tried every which way, I could not get port 5080 forwarded to the telephone PBX to get a successful connection from WAN. In the end, I cracked it by using the WAF to do this? WHAT, I didn't expect that! It appears the WAF was dropping the WAN attempt to connect to the tel-PBX webconsole on port 5080 even though I had DNAT rules and Firewall rules to make this happen. It seems that the WAF gets there first, sniffs, sees HTTP protocol that wasn't on the allowed port 80, and dumps it, before DNAT or firewall have a chance to route it. (Or perhaps after they routed it, but it was on 5080 not 80 so WAF stopped it).

    This behaviour doesn't seem to be documented anywhere (at least within easy and obvious reach of the new admin).

    So, a suggested new rule for your list is that ANY HTTP protocol, never mind whether port 80, 443, 5080, 8000, 8080 etc, if it is HTTP it should be managed through the Webserver Protection WAF or the packets might get dropped no matter what other rules are in place. And it will take hours to debug. 

    *EDIT* Everything now working OK on the ISDN over IP. Big Smile
  • Hi, 

    Please open a new thread if you still have questions, and include the UTM version #.

    I haven't tested DNATs with the WAF, but I have with the VOIP Security helper, and they work fine.
    I'm assuming you're not trying to NAT the same ports that the helper would be working with.

    I believe the WAF works the same way as all the other proxies; e.g. I believe it only listens on ports 80 and 443.

    FYI, Bob's rule #2, and the attachment he posted describes how the hidden rules work.