1. Blocking traffic to an IP range on the Internet & 2. Force traffic to a specific webserver to use only one of our two WAN connections

Question

Hi, I have a Cisco ASA background and find it hard to fully understand the UTM firewall. 
 For a subnet I want to block all traffic to a specific IP range on internet. The firewall rules I created do absolutely nothing, as I understand this is because we use Web protection. 
 But in web protection I can block traffic only based on domain or regular expression. How do I block all traffic to an IP range on internet for a specific VLAN on my network? 
 Second question, we have 2 internet connections connected to the UTM with load balancing enabled. There is a website that only works on one of the internet connections. How can I force traffic for the website to use that specific interface? 
 Thanks in advance!

DouglasFoster · Answer

You are correct, ASA and UTM are very different, and some important information about its architecture is only documented in this forum. Short version to your two questions: 
 
 UTM Architecture UTM is a series of mutually-exclusive proxies (packet filters). Firewall Rules, being the least sophisticated, is the filter of last resort (not the first one). UTM is also directionless, so you have no equivalent of "security=inside" and "security=outside". A very few proxies ask for an internal scope definition, but the setting is specific to that proxy. Most proxies have an "Allowed Networks" filter that determines whether or not the packet enters the filter or keeps looking for a different one. Once inside the proxy, the source address is generally not usable (except for Firewall Rules), so source-destination pairs are generally not processed in the way that you expect from your experience with ASA. Consequently, your firewall rules never apply to traffic that is handled by the web filter. This architecture works, but at first it makes your head hurt a little bit. My longer writeup on UTM architecture is in the Wiki section. 
 UTM Web Filter The web proxies rely on a source IP (Allowed Networks) filter to determine which (if any) "Filter Profile" is used to begin handling the packet. Thereafter, all filtering is based on URL. So a block based on IP address has no effect if the URL is an FQDN, and vice versa. This is actually a pretty reasonable architecture because SNI means that an IP address and a FQDN may not generate the same web response, and the reputation of a web hosting company's server address may be different than the reputation of a hosted web site that is running on that server. 
 
 A few more critical documents for reading: 
 
 Bob Alfson's "RULZ", which explains packet filtering order, the fine art of using DNAT as a global block, and advice on DNS setup. https://community.sophos.com/products/unified-threat-management/f/general-discussion/22065/rulz 
 The other documents in the Wiki section. It is a short list. 
 Detailed UTM port usage overview https://community.sophos.com/products/unified-threat-management/f/general-discussion/100848/how-to-understand-utm-port-usage 
 Web Filtering Lessons Learned https://community.sophos.com/products/unified-threat-management/f/web-protection-web-filtering-application-visibility-control/101117/optimizing-web-proxy-lessons-learned 
 Demonstration with sample code for pulling logs into a SQL database https://community.sophos.com/products/unified-threat-management/f/management-networking-logging-and-reporting/100770/how-to-using-a-sql-database-to-interpret-utm-log-files 
 
 DNAT to a Dead End address is used to discard traffic unconditionally, because Destination NAT rules are applied first, before any of the proxy entry points are evaluated. So if you want to block anyone from accessing a range of web addresses using ports 80 and 443, a DNAT rule is the way to go. 
 Hope this helps. Once you get over the shock, and the glaring omissions from the documentation, the architecture works. I am in the minority, because I think it works better behind an ASA or equivalent firewall, instead of in place of one. At most installations however, it is the firewall. I have done all that I can to offset the documentation problem.