Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 5 subscribers
  • Views 16265 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

UTM in transparent/bridged mode

AdamBurn

Hello all,

 

Desperately hoping that someone can help with me this.  We've had the UTM running for over a year now in standard mode with no problems.  I now want everything to go through the UTM transparently.

 

The topology would be LAN > UTM > External Firewall > WAN

Currently the default gateway on the core switches is setup as the existing firewall (*.*.192.251).  I would change this to the UTM IP (*.*.192.254) and then what?  I have tried a number of different ways none of which have worked properly.  My original plan was to have an inside interface, and an outside one, so in and out.  Then I have thought about link aggregation?

I have read recently about using a gateway route, is that the way forward?  The internal interface is setup with the IP *.*.192.254 with the gateway *.*.192.1 and this one interface handles all traffic.

All I require is that all web traffic comes through the UTM, web filtered, then out to the existing firewall.

 

Thanks in advance



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

    There is a significant loss in capability and accountability when you switch to teansparent mode.

    I suggest that you enable teansparent mode as a backup to standard mode rather than a replacement.

  • 0 in reply to DouglasFoster

    Doug said, "Since you have an existing firewall, i would recommend keeping it at the perimeter.   UTM opens unwanted ports and the UTM firewall rules are ignored when a proxy is involved."  I don't often disagree with him, but I will here.  It's true that someone accustomed to Cisco can be surprised by how the UTM functions.  Firewall rules are applied, but rules created by enabling proxies are applied before manual rules (see #2 in Rulz).  If you want to close a port at a WAN connection, just use a DNAT to a non-existent IP.

    In general, I would not recommend bridging the UTM, but it's not clear to me from this discussion what function(s) the UTM provides.  Is this simply a thread about Web Filtering that should be moved to the Web Protection forum?

    My approach would be to get rid of the perimeter firewall if the UTM has a Network Protection subscription, and possibly so even if it does not.  Again, it's not clear to me exactly what the situation is.

    Cheers - Bob

Reply
  • 0 in reply to DouglasFoster

    Doug said, "Since you have an existing firewall, i would recommend keeping it at the perimeter.   UTM opens unwanted ports and the UTM firewall rules are ignored when a proxy is involved."  I don't often disagree with him, but I will here.  It's true that someone accustomed to Cisco can be surprised by how the UTM functions.  Firewall rules are applied, but rules created by enabling proxies are applied before manual rules (see #2 in Rulz).  If you want to close a port at a WAN connection, just use a DNAT to a non-existent IP.

    In general, I would not recommend bridging the UTM, but it's not clear to me from this discussion what function(s) the UTM provides.  Is this simply a thread about Web Filtering that should be moved to the Web Protection forum?

    My approach would be to get rid of the perimeter firewall if the UTM has a Network Protection subscription, and possibly so even if it does not.  Again, it's not clear to me exactly what the situation is.

    Cheers - Bob

Children
  • 0 in reply to BAlfson

    Bob, we will have to agree to disagree.  

    If UTM wants to be a perimeter device, it needs to not open ports that the user does not expect to have open.  Sophos calls XG a firewall, but it does not call UTM a firewall.   I think that is instructive.   UTM is a product with many good features at a great price, but an acceptable perimeter firewall is not one of them.

    If you want to sell the idea that the workarounds are acceptable, I suggest you (or Sophos) create a wiki article that itemizes all of the necessary DNAT workarounds.   It seems they include SMTP Proxy which opens 25 on all addresses, something with RED certificates being visible on the internet even when the RED devices are not supposed to be visible on the internet, and (my experience) WAF opens 443 even when all WAF sites are configured for alternate ports.  What else do we need to worry about that is not on my list?   We cannot patch what we do not know, and a wiki article would at least warn the sysadmins who stumble on the entry.  Specifically, can 127.0.0.99 work as a DNAT dead-end, or will UTM respond on all loopback addresses?  If I use a non-loopback private IP, I need to worry about that IP being used in the future, so a loopback address is definitely preferred.

    On port scanning, I only have experience with Trustwave, and once they accept a defense, it does roll over to all subsequent scans.   I am astounded by how much they can expose from an automated scan, as I assume the bad guys and the NSA can learn as much or more.   I would love to know how to prevent the information leakage which allows PCI scanners to know the version numbers of component products.   I value what Trustwave reports, because if they can detect a version number and rattle off all of the vulnerabilities that might be unaddressed, then we can assume that a bad guy can extract the same version information and attempt to attack each of those vulnerabilities.   It is a headache to prove that each CVE has been addressed, but the information at least gives me a degree of parity with the bad guys.