Guest User!

You are not Sophos Staff.

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

Enabled logging on SUM Auto-Created rule for S2S VPN

I am having lots of issues with a couple of Site 2 Site VPNs originating from the same location and realized that logging is disabled on the firewall rules with no apparent way to turn it on. I used the S2S wizard with auto-firewall rule creating since this is a branch office with full access. It's in production, so I can't just shut it off to rebuild without a maintenance window.

Am I missing it or is there just no way to do it when created automatically?

 



This thread was automatically locked due to age.
  • If it's the firewall rule you want to log, Tim, select "Automatic firewall rules" at the top of the 'Rules' tab.  Was that it?  Is that something one also can do in SUM?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I can create rules using SUM and they allow me to enable logging. However when you allow SUM to auto-create the rule while building a Site to Site VPN, I don't see the option to enable logging. On the UTM, you can see the rules but can't edit. On the SUM I can't see anywhere that the rules can be viewed. There is only a checkbox to enable/disable Automatic Rule Creation.

    I now have a ticket open with Sophos. Over last weekend I replaced a WatchGuard cluster with a Sophos UTM cluster. We never had proxy enabled on the WatchGuard. However, everything else is configured the same.

    1. The remote site has two tunnels. TN <> FTW and TN <> DAL.
    2. DNS and DHCP were forwarded and relayed to servers in FTW.
    3. WPAD was configured via DHCP.
    4. The TN Sophos (Remote site) is the default gateway for the network. In FTW/DAL it is not.
    5. Remote site needs access to web services and infrastructure at both locations FTW/DAL.
    6. Remote site has direct access to internet from site.
    7. Remote site has two ISPs, ATT (Primary Business Class 100MB) and Comcast (100MB), configured in failover mode.

    On initial setup, I had the UTM configured in Standard Proxy mode. That wasn't blocking traffic, so I tried Transparent. That did manage traffic, but then we couldn't resolve host names, we had to use FQDNs. I changed the proxy back to Standard mode for one day and no traffic was sent through web protection.

    That night I investigated and found that the problem was with the proxy.pac configuration. Must have had a stray character in the file. Finally resolved that and thought everything was fine. That morning, one user couldn't get to any intranet resources and only sporadic access to the internet. In troubleshooting his issue I decided to try toggling from Standard to Transparent. The back. Somewhere in that process, two more computers became unable to access the intranet.

    What's unique, is that all three problem computers are laptops configured for MS DirectAccess. What appears to be happening is that DirectAccess can't reach the "Network Location Server" that determines if the laptop is inside or outside the company. It then brings up the laptops tunnel, but can't fully connect to the DirectAccess server over the internet.

    When the computer is in this state, I can ping between sites and do nslookup all day long. However, intranet web browsing does not work. I can see nothing of significance in the logs. Only traffic trying to go directly to the internet, nothing to the intranet. Using TCPDUMP on the UTM I can see the traffic.

    We have several other laptops at this location that are not having the problem. In fact two new laptops were deployed last week, built from the same image the same day. One doesn't work and one does. The three with problems include one Windows 7, one Windows 8.1 and one Windows 10.

    Sophos support looked at it last night and didn't see anything obvious. They send the best practice for DNS, so I reworked that to comply with their guidelines, but no improvement for the afflicted laptops.

     

     

     

     

  • The KnowledgeBase article was copied from DNS best practice 2+ years ago and hasn't been maintained as has my post.  If you can't find anything in the Firewall, AppCtrl or Web Filtering logs related to those three laptops, then I'd also guess that there's something funky going on with DNS.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I reviewed your DNS guide and the only thing that needed to be changed was the checkbox for ISP. Which I only checked at the request of Sophos support.

    Internally at my primary sites, AD DNS servers forward to OpenDNS and not the Sophos. Resolution is working fine.

    At the remote site, the clients point to the DNS servers at the Primary site. I have tried manually configuring them to use the Sophos, but that didn't make a difference.

     

    From your experience, should the Sophos be able to resolve hostnames to fqdn?

  • OK, I've made some progress. If I change the IP Address of the computer, it identifies the network properly as being a Domain Network. The old address appears to be somehow blocked, but I can see it communicating just fine.

    Does the Sophos UTM ever blacklist a client?

  • I don't know who is familiar with DirectAccess, but to determine if it is inside or outside of the network, it pings a resource inside the network that should only be accessible inside. If it doesn't get a response, it assumes it is outside and invokes the tunnel.

    The problem I am having is with the communication between the client and that web URL. Once a client IP goes bad at the remote site, it doesn't ever come back. At least not yet. I can change the IP address and then it might start working.

    Running wireshark on the DirectAccess server I noticed that traffic was coming in from the client but there were errors on the reply. 

    1421 19.892731 192.168.169.252 192.168.3.8 ICMP 590 Destination unreachable (Fragmentation needed)

    MTU of next hop: 1438

    192.168.169.252 is the inside interface on the Sophos and 192.168.3.8 is the Direct Access server.

    The errors occur on both the a good and bad client IP, but they persist on the on the bad ones. The good ones have several, but the packet size steadily decreases until the client is accepted.

     

     

  • Apparently the overhead on the tunnel from Sophos to Sophos is higher than from Sophos to WatchGuard. Or Sophos is handling the traffic differently. Anyways the S2S tunnel left us with a PDU of 1438. To resolve the immediate issue, change the MTU on the troublesome server to 1430. Since the server was receiving the ICMP fragmentation notice, my understanding is that it should have adjusted accordingly.