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

Strange issue with FW

We have an additional interface that goes off to another company via a leased line.

When web protection (transparent) is enabled, we can reach their server on port 80. When we disable the web proxy, we can't reach their server. We have added FW rules to allow this and can see in the logs, traffic going to the server on port 80 and the server replying on port 80. But we can't get to it via our browser unless the web proxy is on.

There are no settings in the browser and all other traffic looks ok. We've also tried this on another port 22222 and it's the same. We can't access the server even though the FW logs are clearly showing it go through.

 

There is no nat rules here and traffic is purely routed. We know the connection works as we have sip trunks and rtp going across the link without issue.



This thread was automatically locked due to age.
Parents
  • Sounds like a routing problem, most likely on return trip.   With proxy on, the remote device sees a packet with a return address associated with the utm tunnel interface.    With proxy off, the remote device seedms a packet with the source device ip.  You need a dtatuc route on remote site for the source ip subnet.

    If you use full trandparent proxy, the failure will appear again (if my theory is correct)

  • Good insight, Doug.  I wonder if adding a route on the non-UTM side to the IP of "External (Address)" through the direct link might not resolve his issue...

    Cheers - Bob 

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Well. Issue solved. We did call Sophos support for this one as it had me scratching my head. for a while. We could rdp, sip etc you name it across the link so we knew there was no routing issue. We could reach a server via http when the proxy was enabled but couldn't when it was disabled. When turning the proxy off, we witnessed  the FW logs showing the traffic passing to the remote server and the remote server responding with everything allowed.

    So what was the issue?

    Somebody (who will remain nameless) had put a block for http for all source addresses in application control. As we were running the proxy, we didn't notice this.

    Got to hand it to Sophos support. A quick call, technician was straight on. Tech took the issue in straight away and had it solved within 5 mins and then took time to explain how to diagnose it in the future. Got to give a big thumbs up here.

    I can only assume the rule must have got there by a colleague (gui shows who and when) by them pressing block on the dashboard traffic popup. If the proxy hadn't have been on, we would have noticed it but in this case the proxy was intercepting the traffic before hitting the FW.

    Sending it to the FW gave no hints either as the FW was showing it as passing. Bottom line is in the GUI check the application control log as well.

    Better still..... in the CLI tail -f /var/log/http.log | grep "whatever"

  • Thanks, Louis - that reminds me to keep mentioning #1 in Rulz.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply Children
  • Yep..... Rulz rule for the UTM!

    Rule #1:

    Always check the logs!  For example, when you disabled Intrusion Prevention, you only disabled Snort - you did not disable the items on the other tabs! (Many people are tripped up by UDP Flood Protection which is logged in the Intrusion Prevention log file.  This is often the cause of bad voice-quality with VoIP and unreliable IPsec connections that don't terminate on the UTM.)

    Whenever something seems strange, always check the Intrusion Prevention, Application Control and Firewall logs. If 'Advanced Threat Protection' on the Dashboard is not zero, check that log also. Hint: If this didn't help, you likely have a routing problem. In that case, check #3 through #5.

     

    In rulz #2

    1. the connection tracker (conntrack) first
    2. then Country Blocking
    3. then Intrusion Prevention (see the images to see that IPS actually can happen in several places but happens only once!)
    4. then DNATs
    5. then VPNs
    6. then Proxies (except the SMTP Proxy in Transparent mode which captures traffic forwarded by a DNAT)
    7. then manual Routes and manual Firewall rules, which are considered only if the automatic Routes and rules coming before hadn't already handled the traffic
    8. and, finally, Application Control.

     

    In our case, the traffic was hitting #6 and going straight out. Disabling the proxy sent it to #7 as we would expect which was allowing it through.

    We didn't think to check #8 Application control, especially for http!

    Another UTM experience as such to tuck under the belt!