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

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:

1. 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.
   
   
2. 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.

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:

1. 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.
   
   
2. 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.

Thank you for the informative answer. Before I go read all this documentation, let's say I have an internal subnet and I want to block traffic to an internet IP range, but only TCP ports 1024 and above. The firewall rules do work now because this is not web traffic and therefore not handled by the web proxy?

Yes.   Each of the proxies listen for specific target ports as well as a source IP list.   If none of the proxies match the packet, then the firewall rules apply.  You can review my Port Usage document, but I think the only high-port usage is Standard Web (8080) and Standard FTP (2121), and these are not worrisome because they must be paired with a UTM destination address on the packet.  

Hoi Jeroen and welcome to the UTM Community!

As Doug noted, Rulz will help you understand.  In this case, I would have referred you to #2.  His READ ME FIRST: UTM Architecture in the Wiki is also enlightening.

Even with a Profile in Transparent mode, a client can activate explicit proxy in the browser and not be subject to the Transparent Mode Skiplist as the proxy reacts as if it were in Standard mode.  You might be interested in a document I maintain that I make available to members of the UTM Community, "Configure HTTP Proxy for a Network of Guests."  If you would like me to send you this document, PM me your email address. I also maintain a version auf Deutsch initially translated by fellow member hallowach when he and I did a major revision in 2013.

Cheers - Bob
PS Moving this thread to the Web Filtering forum and giving it an appropriate title.  One of the unwritten rules here is "one topic per thread" - that's to make it easier for future members to find an answer to a question that's already been answered without starting a new thread.