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

Quarantine Report Allowed Networks - Risk of accepting all networks

Hello all,

with many users working from home, we have noticed that the Release buttons within the quarantine report emails no longer work.

As this function is configured with the same hostname as the public DNS entry of the WAN interface and we are using L2TP VPN, the Clients try to connect to port 3840 on the WAN interface. The internal DNS-Server has the correct internal entry present, but is not queried by VPN-Clients in this case, causing them to send the request from their public IPs. Only internal Networks are configured under Quarantine-Report >> Advanced >> Allowed Networks.

For ease of use, we want to add Internet IPv4 to the Allowed Networks, but want to make sure we don't expose ourselfs to unnecessary security risk in the process. The UTM Engineer Handout calls this "not recommended", but I could not find any specific mention of this being a security-related warning.

Does anyone know how severe if at all the security implications of this setting are, or can point me to an official statement regarding this?

Thanks



This thread was automatically locked due to age.
Parents
  • I think you will need a Full NAT rule to rewrite the traffic going to the external interface.

    For traffic from: L2TP pool network
    Using Service: Spam release (I'm not sure if you need to create this yourself or that it's default but otherwise create it using TCP destination port 3840)
    Going to: External WAN (Address)

    Change destination to: Internal (Address) (or any other address that your internal DNS also points to)
    And the service to: <leave empty>

    Change the source to: Internal (Address)
    And the service to: <leave emtpy>

    Tick 'Automatic firewall rule' and also 'Log initial packets' under Advanced so you can see the traffic in the firewall. 

    Last but not least turn ON the NAT rule.


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • Thanks for the reply!

    But I fear my description wasn't clear enough. Clients don't send the quarantine release request from their VPN Pool interface/IP.


    example:

    UTM WAN = 169.200.1.1 - public DNS: gateway.sophos.com
    UTM Internal = 10.1.1.1 - internal DNS: gateway.sophos.com
    Quarantine Report release link hostname: gateway.sophos.com
    internal DNS Servers are confgured under Remote Access >> Advanced >> Client Options
    Client public IP = 89.100.1.1

    A Clients starts a L2TP session from 89.100.1.1 and is assigned the VPN pool IP 10.242.2.2.
    Afterwards, the user clicks the Release button in the Quarantine Report email.
    The Client Browser then displays an error message that the page cannot be accessed/displayed.
    The firewall log shows a dropped Packet with srcip="89.100.1.1", dstip="169.200.1.1" and dstport="3840"

     

    A quick and easy fix would be to allow quarantine release requests from the internet. That's why I'm looking for tangible security risks in that approach.

  • In that case it's strange that your clients get the external IP-address while they are referring to the Internal DNS server.

    If you make a connection and from a command-prompt enter NSLOOKUP (assuming Windows), which DNS server replies? If it's your internal DNS server then you could check if Internal DNS points the domain name to the Internal IP-address.

    If you have more public IP-addresses, you could also use one for either VPN or quarantine release.

    If that's also not possible you could make the external DNS-name for the quarantine release server also point to the internal IP-address. Your VPN-clients should then be able to connect to it (however remote internet computers can not anymore, if there are no remote systems that require access this is an alternative).

    If nothing of this is possible then you might indeed need to open it up to the internet.


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • Hallo and welcome to the UTM Community!

    This feels like a DNS problem.  Please show a picture of the 'Advanced' tab in 'Remote Access'.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob!

    I agree that this is a DNS related issue.

    I think It comes down to the issue that the same hostname is resolved to different IPs depending if you are within the internal network or not. But it would still work, if Clients using L2TP VPN would query the internal DNS server first.

    Advanced Settings are:

    DNS server #1:    10.1.1.5
     
    DNS server #2:    10.1.1.6
     
    WINS server #1:    0.0.0.0
     
    WINS server #2:    0.0.0.0
     
    Domain name:    ad.local

     

    ipconfig /all:

    PPP-Adapter VPNIntern:

    Verbindungsspezifisches DNS-Suffix:
    Beschreibung. . . . . . . . . . . : VPNIntern
    Physische Adresse . . . . . . . . :
    DHCP aktiviert. . . . . . . . . . : Nein
    Autokonfiguration aktiviert . . . : Ja
    IPv4-Adresse . . . . . . . . . . : 172.30.8.129(Bevorzugt)
    Subnetzmaske . . . . . . . . . . : 255.255.255.255
    Standardgateway . . . . . . . . . : 0.0.0.0
    DNS-Server . . . . . . . . . . . : 10.1.1.5
    10.1.1.6
    NetBIOS über TCP/IP . . . . . . . : Aktiviert

     

    nslookup:

    Standardserver:  speedport.ip
    Address:  fe80::1

Reply
  • Hi Bob!

    I agree that this is a DNS related issue.

    I think It comes down to the issue that the same hostname is resolved to different IPs depending if you are within the internal network or not. But it would still work, if Clients using L2TP VPN would query the internal DNS server first.

    Advanced Settings are:

    DNS server #1:    10.1.1.5
     
    DNS server #2:    10.1.1.6
     
    WINS server #1:    0.0.0.0
     
    WINS server #2:    0.0.0.0
     
    Domain name:    ad.local

     

    ipconfig /all:

    PPP-Adapter VPNIntern:

    Verbindungsspezifisches DNS-Suffix:
    Beschreibung. . . . . . . . . . . : VPNIntern
    Physische Adresse . . . . . . . . :
    DHCP aktiviert. . . . . . . . . . : Nein
    Autokonfiguration aktiviert . . . : Ja
    IPv4-Adresse . . . . . . . . . . : 172.30.8.129(Bevorzugt)
    Subnetzmaske . . . . . . . . . . : 255.255.255.255
    Standardgateway . . . . . . . . . : 0.0.0.0
    DNS-Server . . . . . . . . . . . : 10.1.1.5
    10.1.1.6
    NetBIOS über TCP/IP . . . . . . . : Aktiviert

     

    nslookup:

    Standardserver:  speedport.ip
    Address:  fe80::1

Children
  • I'm not sure what causes this, but maybe you can increase the priority for the PPP-adapter so that it has higher prio than your Ethernet adapter which now gives the other DNS-server priority.

    Or as I mentioned before, if no-one needs to access this DNS-name from outside, you can also point the outside DNS-name to the same internal IP-address as the inside DNS-server is doing. 


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • apijnappels said:
    if no-one needs to access this DNS-name from outside, you can also point the outside DNS-name

    Thanks for the tip, but the public dns-name is intended to allow users to access the user portal without establishing a vpn connection, so it is in use.

    The other issues are seemingly fixed by deactivating IPv6 in the clients NIC.

  • Under Email protection -> Quarantine report -> Advanced -> Hostname you can set a custom hostname especially for mailrelease. That might help you out without disabling IPv6.


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.