Sophos VPN Client - disable autoconnect when in local network

With Sophos connect you can provision a provisioning file with an auto_connect_host. See this for more explanation.

OK, I did it, created .pro file and imported to client's Sophos Connect. Instantly it discovered that it's in LAN, so no auto-connect is needed, but when I tried to connect to download policy (nevermind if from LAN WIFI or another VLAN WIFI with user portal and VPN portal enabled) it gives an error:

No SSL VPN policy is defined for this user

And it's not true - in Sophos Firewall on REMOTE ACCESS VPN section SSL VPN under my policy members I have this user.. And on the user side there's also SSL VPN policy choosen.

Hi Kam , if you want openvpn to connect to only the ddns, you can specify it in the "Override hostname" in the SSLVPN global settings on the firewall:
 

With this, the .ovpn file will only have the override hostname in its remote directive and you will be able to use the .pro file also.

I have a problem with that. Don't know why, but when I open SSL VPN global settings and even try to save without any changes, error message tells me YOU MUST ENTER A NETWORK IP ADDRESS.

Nevermind if I put something in override hostname or not.

From top to bottom I have this:

Unfortunately when I click APPLY, the error comes out. The problem is, after clicking OK on the error, SFOS doesn't point to any specific field (nor by standing in that field, nor by making the field red or marked in any other way).

Next when I enter in OVERRIDE HOSTNAME my ddns hostname (domain, not IP address) I get the same error. Despite I added Dynamic DNS service in NETWORK settings and it connected succesfully on domain name.

This should not happen. This is seen if we have some problem in the interface configuration. If you can share the access id in DM, we can take a look at this problem. Alternatively, you can open a support ticket and share the access id via the ticket.

The problem is the IPv4 address you have specified. Make a network out of it because you have the netmask 24 .

Net: 10.81.234.0

OK, so it helped with global settings saving - after changing IP to 10.81.234.0 as well as override hostname with my ddns host, SFOS let me save config.

Unfortunately, when imported .pro config on user's laptop, after skipping wrong certificate warning, I tried to connect, enter username and password (which is working fine for ovpn config) and the results are:

1. when in LAN - error "No SSL VPN policy is defined for this user"

2. When on external hotspot - FAILED TO LOAD CONNECTION (which, I assume, is obvious because Sophos Connect can't import ovpn setup from VPN/user portal. But it was worth trying to be 100% sure)

What's another weird thing - when I enabled SSL VPN, in global settings there already was this incorrect IP set up. I didn't change anything, so it looks like Sophos has wrong data as default setup.

How are your device access settings configured, did you enable SSL VPN for the correct zones?

Although I had SSL VPN checked only for WAN, for the tests I checked this for all my networks. Still the same error about no ssl vpn policy.

In the .pro file, are you using the correct gateway and port ? A sample of the .pro file can be attached.

I believe you are on v20 release on the firewall. If yes, can you do the following:
1) Connect using .pro file
2) ssh to firewall and collect /log/vpnpoprtal.log 

It may tell what could be wrong with the API being called from Sophos Connect Client.

Yes, I double-checked those in .pro file - gateway is ddns domain address and port for user portal is identical as in Sophos settings. One thing came to my mind - I changed default port from 4443 to other one - maybe this is the problem?

About firewall software - yes, I'm on v20, but I don't know what do you mean by connect using .pro file. You mean I should try to connect user using .pro file, get an error and then collect vpnportal.log to check if there's anything there?

Kam said:

You mean I should try to connect user using .pro file, get an error and then collect vpnportal.log to check if there's anything there?

Yes, that is what I meant

Kam said:

I changed default port from 4443 to other one - maybe this is the problem?

For .pro files, use the vpn portal port in the .pro file (which by default is 443)

Kam said:

You mean I should try to connect user using .pro file, get an error and then collect vpnportal.log to check if there's anything there?

Yes, that is what I meant

Kam said:

I changed default port from 4443 to other one - maybe this is the problem?

For .pro files, use the vpn portal port in the .pro file (which by default is 443)

What? So the manual is specifically saying to use port for user portal, and it's misleading? That's a bummer. Ok, I'll try to change port and see if it helps.

The instructions are from an older version where there was only the user portal. As of version 20, they have split it into user and VPN portal. The .pro file is there to pull the .ovpn file from the VPN portal, so the port from the VPN portal and not from the user portal must be specified there.

Kam said:

What's another weird thing - when I enabled SSL VPN, in global settings there already was this incorrect IP set up. I didn't change anything, so it looks like Sophos has wrong data as default setup.

Yes, this also results from an older version where an IP range still had to be specified. for example: 10.81.234.5-10.81.234.85
At some point this was also changed to a whole subnet e.g. /24, but probably forgot to adjust the IP as well.

Ok, thanks for this useful information. That's a shame Sophos didn't update their KB on official site because that was thr f....n problem - after changing port in .pro file user established connection using .pro file.

But now, on the other hand, it connects everytime, doesn't matter if on LAN or on hotspot. I have to check it out further but now I'm not on site so don't have direct access to testinng device..

In fact it has been updated, you have only been given the link to the KB of 19.5. The right link for version 20 is here and it is correct there.

Ah, OK. Thanks for the updated link - will be definitely useful for others with the same problem.

Before I sum up this thread, I'd like to have a chance to workout auto-connect feature. Let's hope it some minor thing that left. Will update here as soon as I testing device in my hands.