Disabling VPN portal breaks SSLVPN connections

Try the new Online help: 

https://docs.sophos.com/nsg/sophos-firewall/20.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Administration/DeviceAccess/DeviceAccessLocalServiceACL/index.html

https://docs.sophos.com/nsg/sophos-firewall/20.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Administration/DeviceAccess/DeviceAccessBestPractices/index.html#ssl-vpn-port

To look into this in more detail: 

Sophos Connect using the Provisioning file uses a mechanism to update the file. For doing this, it is reaching out to the VPN Portal first. 

If you disable the VPN Portal, the connection is not enabled. If you use only the OVPN File, you do not need the VPN portal to build up a connection. 

If you separate the VPN Portal from the SSLVPN Port, you can also control the access policies. 

To look into this in more detail: 

Sophos Connect using the Provisioning file uses a mechanism to update the file. For doing this, it is reaching out to the VPN Portal first. 

If you disable the VPN Portal, the connection is not enabled. If you use only the OVPN File, you do not need the VPN portal to build up a connection. 

If you separate the VPN Portal from the SSLVPN Port, you can also control the access policies. 

Yes, we are using a provisioning file.

Does that mean there is no way of closing down the VPN portal and we simply need to accept that people will continuously try and hack in to the firewall with invalid login attempts?

Moving forward, it would be better if Sophos checks in with SSLVPN rather than VPN portal.

I did a little bit of more digging into this topic. 
Pro Files will download the SSLVPN and IPsec Files and push them to the Sophos Connect client. Sophos Connect then can use this client to connect to the firewall. At this point, you do not need the VPN Portal anymore. This was tested in V2.3.1 of Sophos connect. But if you try to update the policies in Sophos Connect, it will try to reach out to the VPN Portal to get a new portal. 

Generally speaking, Sophos recommends to follow industry hardening advises:  Hardening Your Sophos Firewall  

About the VPN Portal: Sophos implemented a new portal (VPN Portal) in v20.0GA:  Sophos Firewall v20 is Now Available This Portal is build to be used in the modern world and is by no means a normal webadmin portal. 

Follow up on some feedbacks here: In SFOSv21.0 the firewall supports third party feeds, which can include those malicious actors as well and automatically block them:  New Techvids Release - Sophos Firewall v21 Demo Videos Part 2: Third-Party Threat Feeds 

My last thought here is: If you do not want to expose or use this process at all, SFOS also support ZTNA as an alternative, using Sophos Central for remote access to your apps. This process do not require any exposing of any port, making you completely invisible for external scans and/or attacks. We are offering 3 Licenses of this for free:  Free Sophos ZTNA Licenses for Sophos Firewall customers   

Pro Files will download the SSLVPN and IPsec Files and push them to the Sophos Connect client. Sophos Connect then can use this client to connect to the firewall. At this point, you do not need the VPN Portal anymore.

Thanks, but that's not what we're experiencing. The pro file was deployed weeks ago. The SSLVPN connects fine, we turn off the VPN portal and it can't connect until we open it again. What I have noticed is that the VPN portal and SSLVPN (UDP) both run on the same port.

We have 150 ZTNA licenses already. We trialed using it a few months ago but when we were setting it up and trying to get different things to work, we were told by Sophos Support you can only do RDP with it. That won't suit our requirements. We need a full tunnel with file sharing, ftp, browsers etc. all routing over the tunnel. Either way, VPN should work fine.

Could you show us your .pro file? Please delete specific information like IP and Port. 

The answer of Sophos Support is certainly not correct. Do you want to discuss this in the ZTNA community? 

Not much to it.

[
    {
        "gateway": "xxxx.com",
        "user_portal_port": 8443,
        "otp": true,
                "2fa": 1,
        "can_save_credentials": true
    },
    {
        "gateway": "xxxx.com",
        "user_portal_port": 8443,
        "otp": true,
                "2fa": 1,
        "auto_connect_host": "mydc.mydomain.com",
        "can_save_credentials": true
    },
]

Will look in to ZTNA again. That might be a solution for us, but not our clients, at least not now as we'd have to go and put together business cases etc.

First: Which SC version do you use? 

Second, could you try a client without the Auto_connect_host flag? Simply remove this part, import into a client, get the OVPN by VPN Portal and disable the VPN portal. 

Third: It could be related to the 2 Gateways, you are using. It could be related to the client noticing the user portal 1 is offline and tries the second user portal. 

Forth: Maybe this is related:  Sophos Connect Client not connecting when userportal is disabled on WAN  

Latest version - 2.3.0.0506

Tried that - no difference - same problem still

They aren't two gateways, they are two different firewalls at two different locations used for different purposes

Hi Stuart James , have you also tried with this option in the .pro file:

"check_remote_availability" : false

Yep, that fixed it. Excellent, thanks Nikhil

Although LuCar Toni made a good point that we need to leave the VPN portal open so that we can deploy new PRO files down the track. And I guess right now we're going to have to leave it open to deploy the check_remote_availability setting change. A bit annoying that it grabs the policy from there rather than the SSLVPN port, but I guess there's some technical reason.

Hi Stuart James I am from the ZTNA product team and would like to point out that ZTNA supports all TCP and UDP based applications. So its not restricted to just RDP, but any application can be accessed using ZTNA. We support both agent and agentless based access as well. Please do let me know in case you want additional information. Happy to jump onto a call.