Anyone using UTM in Bridged mode?

Hi,

we have some transparent installations running. So in general it´s working, normally for basic functionality it´s not necessary to add extra Ethertypes. But of course it depends, on how your environment is actually configured. Could you please draw a simple picture with some information about what protocols/traffic pass the firewall? What I know for sure is, that LACP will not work through the Bridge, so you will not be able to build a LAG between two switches through this "software-bridge". But you could build LAGs from a switch for example to the UTM and Bridge them then.

Spanning-Tree and ARP is no problem. You can choose between L3 Port, L2 tagged vlan, L2 untagged, you can create separate Interfaces in VLAN (when using trunkports). Did you create a firewall rule to that time? And if yes, was it sufficient for your essential traffic? Did you also use the transparent proxy?

The more input you give, the more detailed the answer from the community can be.

Regards,

Sebastian

Pretty simple configuration:    

• multi-site network on 192.168.*.* 
• Central site has a firewall connected to a switch.  
• Changed it to firewall-utm(bridged)-switch.  

Firewall, UTM, and switch are all on the default VLAN and the same subnet.   No QOS either, so tagging was not a concern.   Firewall is an IPv4-only device, so I did not expect that other Ethertypes would be necessary either.

I had to manually change one of the UTM interfaces to MDIX mode because neither my UTM appliance nor my firewall were smart enough to do automatic MDIX detection, and I did not have a crossover cable handy.

Bob Alfson has repeatedly posted that he recommends against bridge mode, so I wondered if my bad experience was normative.   Glad yours was better.

I never got as far as enabling transparent proxy,  I did not understand UTM architecture as well back then.   Today, I wonder if bridged traffic is processed by the UTM firewall rules when transparent proxy is off, and the firewall rules created the problem?

If you really did not add any firewall rule, then all your traffic was probably blocked..... For a first try, you could add a simple any any any allow rule. if you want to try it again, you should start with a small lab. Then you should monitor the firewall log to see, what happens...

Good stuff, Sebastian!  Great idea to start a new, appropriately-titled thread for this, Doug!

I recommend against bridge mode for several reasons.  In your case, since you don't need the UTM to do QoS, you wouldn't suffer from the UTM's inability to do QoS on a bridged interface.  I suspect that Sebastian's firewall rule suggestion was all you needed to mak your bridge function.  If you're using Web Filtering in Transparent mode through a bridged UTM, then I would change to Full Transparent so that the UTM doesn't masquerade the users' accesses.

Cheers - Bob

Thanks Bob.... Maybe I will do that in future.

Because I currently have a case with a sophos developer on this... Beginning with UTM 9.3 the bridging function was changed. Now in 9.3 there is a problem, that everybody using bridges, should be aware of. When you create a bridge interface and you need the UTM to have an ip address in a specific vlan (so the utm basically bridges two trunkports between switches i.e.), you can leave the bridge interface ip configuration (this address would reside in the untagged/native vlan) blank. When you apply the config, the value for the ip address will automatically be changed to 0.0.0.0. After that you need to create another interface, type Ethernet VLAN, select the bridge interface as Hardware, add a vlan Tag and enter the ip address. So far, that is in fact working with utm >=9.3.

But: If you (for whatever reason), change the ip address of the bridge interface from 0.0.0.0 to another valid ip address, then all the member interfaces from the bridge will go down and will not come back. The interfaces will remain in an inactive state, unless you reboot the firewall. After a reboot, the new setting is active and the interfaces are working again.

So if you are using an interface that uses brx as Hardware, never change the ip address on the brx interface itself from the default value (0.0.0.0), unless you have some helping hands onsite. Btw.: If you are changing from a valid IP Config e.g.: 192.168.1.1./24 to 172.16.1.1/12, that seems to make no problems. If STP is activated, it takes 30seconds and then the firewall will be reachable again.

Edit: This has now been classified as Bug-ID: NUTM-8604

Hope that helps.

Best Regards

Sebastian

Follow up:  

I am preparing to try again with Bridged Mode, with UTM still behind another firewall.   With bridge mode enabled, UTM can implement transparent proxies, and the other firewall configuration does not need to change.   If a UTM upgrade creates disaster, I could take it out of the configuration and still have a working network.   The bridge is the only interface that needs to be active.

The downside to this configuration, per KB# 121221 is that if Transparent AD SSO is used, it needs to hog ports 80 (and presumably 443) on the (only) interface, which disables any ability to use User Portal and SSL VPN on that IP address and port.   The KB article implies that it might even block WAF traffic on one of the interface's additional addresses, which surprises me.

I am planning to use Transparent Web Proxy primarily to find traffic that is bypassing Standard Proxy.   Some of that traffic will be from servers, and I don't want to break existing functionality by triggering a login prompt.   So the Transparent Proxy will use Authentication None, because reconfiguring that other traffic to another port would be too disruptive to me and to my users.

In general, Doug, I change the User Portal to 2443 and SSL VPN to UDP 1443 to avoid any conflict with Web Filtering and WAF.

Cheers - Bob

And you usually change SSL VPN to UDP.   For the moment, I prefer the loss prevention of TCP over the performance benefit of UDP.

What about the KB article's reference to conflicts between Transparent SSO and WAF?   I have never configured WAF on an interface's primary address.  Do you know whether Transparent SSO grabs ports 80 and 443 on all interface addresses, or only on the designated interface's primary address?

I've not seen it written anywhere, but I believe that OpenVPN already does loss prevention in the decryption process.  Google uses UDP 443 for HTTPS traffic between Chrome and its servers, and I have seen the same claim for those SSL conversations.

Maybe I've not understood that KB.  I guess I would consider it a bug if httpproxy in Transparent mode captured TCP 443/80 traffic aimed at an IP on an interface.  If the admin put a Virtual Server on "DMZ (Address)," for use by clients in "Internal (Network)," I would consider that a misconfiguration.

Cheers - Bob

Adding notes to provide a consolidated reference on what I have learned:

Converting Exception sites from the proxy script:

In standard mode, I use a proxy script to bypass certain highly-trusted websites.   These have been configured as wildcards, such as "contains .123rescue.com/" (which Sophos Support uses for screen sharing).   I want to keep these sites bypassed when I activate Transparent Mode, but the Transparent Mode Skip List does not support domain wildcards.   Since the bypassed sites have never been logged, I have no way of knowing what host names might be needed for this to work (and the list would probably be incomplete anyway.)

Fortunately, this issue was discussed previously in this link

https://community.sophos.com/products/unified-threat-management/f/general-discussion/76428/wild-card-dns-definitions-in-transparent-skip-list

The solution is to use a website exception instead of using the skip list.    The link suggested using Regex, but I think I have an easier method:

• Create a new Website Override and paste in all of the sites referenced in the proxy script.   
• Assign a tag, such as "Web Proxy Bypass", check the option for "Include Subdomains", then save.   
• Create an exception, with as few or as many features disabled as you desire, and link it to the Tag "Web Proxy Bypass".

Choose "Full Transparent Mode", not "Transparent Mode"

This option is only enabled when bridge mode is active, and the discussion on this link says that it is actually required when bridge mode is active.

https://community.sophos.com/products/unified-threat-management/f/web-protection-web-filtering-application-visibility-control/73266/bridge-web-protection-transparent-block-traffic-http-https

When changing from out-of-band to bridge mode, create a UTM firewall rule for ANY-ANY = ALLOW, or something similar as appropriate

When UTM is out-of-band, no firewall filtering occurs because only Standard Proxy traffic moves through the UTM.   Once UTM is in-line, all unproxied traffic flows through the firewall layer.   Since UTM is not zone-based, even outbound traffic needs to be explicitly authorized.  Assuming that traffic filtering is performed correctly by the firewall that is in front of UTM, then an ANY-ANY-ALLOW rule should be sufficient.   A more restrictive rule will usually be needed for sites with DMZ, Remote Access, or Guest WiFi users connecting through the UTM. 

(On my first attempt to use Bridge mode, I probably failed because I did not create a Firewall-allow rule and I did not use Full Transparent Mode.)