Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 10 replies
  • Subscribers 7 subscribers
  • Views 22093 views
  • Users 0 members are here
Options
Suggested
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

Anyone using UTM in Bridged mode?

DouglasFoster

There are four possible configurations for UTM:

  1. UTM is the perimeter firewall, supporting all features
  2. UTM is immediately behind the perimeter firewall on a bridged connection, supporting all features
  3. UTM is immediately behind the perimeter firewall on a routed connection, supporting all features
  4. UTM is out-of-band (anywhere else on the intranet), supporting only Standard Proxy and Internal features

Bridged and Routed connections should be functionally identical.   However, inserting UTM into the network using a bridged connection should require no changes to the firewall or the internal router, while inserting UTM into an existing network using a routed connection will require addressing and routing changes on one of the adjacent devices.  So option 3 can be ignored.

I don't want to use UTM as my firewall, and option 4 doe snot support all features, so bridged mode has the most appeal.   On a UTM bridge, the system administrator must specify all of the ethertypes that are supposed to be passed, and I don't know how to determine which ones will be needed.  I did find an RFC with all of them listed, but it is a long list and UTM requites them to be entered one at a time.

My one brief attempt to use a bridged configuration failed miserably, mostly because I could not figure out how to debug problems, and I did not have the luxury of waiting while a support case percolated through Sophos.  The test was at least a year ago, so I don't remember many details, other than that Internet traffic was not flowing properly.   My unused bridge configuration is still preserved in UTM:

  • Ethertypes passed:  8887, 0806, 814c, 8035, 876b
  • Allow arp broadcasts: Yes
  • Allow IPV6:  No (not required)
  • Spanning tree:  Off
  • Aging timeout: 30 seconds (default)
  • Virtual MAC addresss:  default (lowest of member MAC addresses)

Has anyone made bridged mode work?   What settings did you use?   If you tried and failed, do you know why it failed for you?



This thread was automatically locked due to age.
Parents
  • 0

    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

  • 0 in reply to seroal

    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?

     

  • 0 in reply to DouglasFoster

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

  • 0 in reply to DouglasFoster

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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

Reply
  • 0 in reply to BAlfson

    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

Children
No Data
Unfiltered HTML