Disabling VPN portal breaks SSLVPN connections

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   

Can you try adding the following option to the .pro file and check:

"check_remote_availability": false

Yep. Precisely what we're seeing kerobra . DDOS attacks on the VPN portal.

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? 

OK I understand.
We took 443 for VPN portal since we believed it would be more convenient for end users. 443 TCP was taken for SSLVPN in good faith to evade any problems withj restricted networks.
That "Note" in Administrator help should be a BIG FAT RED warning at least.

However, my idea in blocking VPN portal for anything but for country "Germany" didn't work.
On firewalls, where the bad combination of VPN portal and SSLVPN port-sharing was used and login security was unintentionally evaded logins are tried 5 or 6 times every second.
On firewalls with ports not shared it is done every 3 minutes evading the 1-120 second timeframe for login security.

Source IP is allways 92.53.65.166 on all firewalls.

You tried a Blackhole DNAT? Because this should forward everything to the blackhole regardless of the service. 

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.

No for me it was easier to completely deactivate VPN portal in the WAN zone with no exceptions and enabling it on purpose only like we did with the UserPortal in the past.

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