Sophos Ssl Vpn Provisioning File

[Chloe Sarnoff]

Whenthe provisioning file is used, the Sophos Connect client imports the configuration through the user portal. For remote users connecting from the WAN zone, you must allow WAN access for the user portal in Administration > Device access, under Local service ACL.

When users double-click the provisioning (.pro) file, it's imported into the Sophos Connect client. Based on the .pro file settings, the client connects to the user portal and automatically imports the remote access SSL VPN (.ovpn) file corresponding to the user and the remote access IPsec (.scx) file into the Sophos Connect client.

You can configure the provisioning file in a text editor and save it with a .pro extension. To know the operating systems on which you can use the Sophos Connect client and provisioning file, see Sophos Connect client.

Alternatively, you can directly install it on users' endpoints using Active Directory Group Policy Object (GPO) in the following folder: C:\Program Files (x86)\Sophos\Connect\import. The Sophos Connect client will automatically import the .pro file from the folder.

If you change the port and protocol on SSL VPN global settings, users must click the gear button for the configuration in the Sophos Connect client and click Update policy.

.scx file: You can only use this file with the Sophos Connect client. It contains advanced settings in addition to the other settings. You configure all the settings on the web admin console. We recommend that you use this file.

SSL VPN: It uses the .ovpn configuration file. On the user portal, users can download the file from VPN > VPN configuration under SSL VPN configuration. They can select the configuration file that's compatible with the client they use.

If you've configured the IPsec remote access settings, the provisioning file automatically imports the .scx configuration file into the Sophos Connect client for all users. It only imports the .ovpn configuration file for users you've assigned to an SSL VPN remote access policy.

Automatically imports the IPsec remote access (.scx) and SSL VPN remote access (.ovpn) configuration files into the Sophos Connect client on users' endpoints. You don't need to share the .scx file with users.

The user portal port on which the provisioning connection is made.Default port: 443. If you change the user portal port on Sophos Firewall, you must also change it in the provisioning file. auto_connect_host The target host used to determine if the Sophos Connect client is already on the internal network. If a value is supplied, the Sophos Connect client checks if the host is reachable each time a network interface IP address is obtained or modified. If the host isn't reachable, then the connection is automatically enabled, and if the credentials are saved, then the VPN tunnel is established.Default: empty string "" (auto-connect disabled).To turn on auto-connect, set it to an IP address or hostname that exists on the remote LAN network. can_save_credentials Allows users to save their username and password for the connection. If you enter true, a checkbox appears on the user authentication page. The checkbox is checked by default but the user can decide not to save credentials.Allowed values: true or false.

1 Uses the Sophos Firewall configuration for 2FA. Users must enter the OTP token or the verification code in the third input field. The OTP token or verification code is appended to the password (example: passwordotp) and sent to the authentication server. Users can generate the token using authenticator apps, such as Google Authenticator.

2 Uses an external 2FA server, such as Duo. Users must enter the verification code generated by the authenticator app in the third input field. The password and verification code are comma-separated and sent to the authentication server. See Third-party authenticator support.

If users need to enter an OTP token or code, the Sophos Connect client shows the sign-in screen twice when they sign for the first time. The first sign-in downloads the configuration file and the second establishes the connection.

we have a Sophos XGS 3300 cluster (19.0.1 MR-1-Build365) and are using Sophos Connect Client for our HO users. All users have an IPSEC and and a SSL VPN profile in the connect client. In the future we want to use the provisioning file (see below)

" If you've configured the IPsec remote access settings, the provisioning file automatically imports the .scx configuration file into the Sophos Connect client for all users. It only imports the .ovpn configuration file for users you've assigned to an SSL VPN remote access policy."

"If you've configured the IPsec remote access settings, the provisioning file automatically imports the .scx configuration file into the Sophos Connect client for all users" => It does not import the .scx config.

someone run into problems installing new devices these days from germany?

Seems my devices (RED15 & RED50) are unable to reach the provisioning server.

I get the message "try prov server" for only half a second. Support say "I checked with the RED ID A3400xxxxxxxxxx and found that this device never contact the provisioning server"

I try it from different networks with different ISP's.

One of my clients recently had a similar difficulty with an RMA RED 15. The replacement couldn't reach the provisioning server. When I asked someone onsite to try connecting directly with a laptop, Windows complained that it didn't get an IP. I had him call their local ISP to have them enable DHCP on their recently-upgraded connection. Bingo! The RED started right up.

The RED needs to use DHCP to get an IP before it can reach the provisioning servers to get its configuration. Once it has that, it doesn't normally need DHCP. That's why the original device had no problems immediately after the service was upgraded.

I called in and had support assist me. I setup the RED config with a static IP, but once the WAN was hooked up, it could not find a provisioning server and went into a boot loop with a failed network setup error message.

Hello everybody,

A short feedback about my problem:

- Of course I tested DHCP and DNS

- I tried to deploy from 3 open networks where it always worked (I have rolled out more than 100 REDs so far).

- I had to RMA the old one and a RMA replacement device. The new devices work without problems

Now when I do a provisioning file for a windows virtual machine (same subnet as WAN), I tell the Sophos Connect client to connect to the WAN address of the Sophos device. It does that all well and good... but then after it downloads the provisioning file, it only tries to connect to the LAN address.

Additionally, I've found the "temporary" ovpn files it sprinkles into the c:\program files(x86)\Sophos\Connect directory, and opening them reveals the configuration file has every address in it EXCEPT the WAN address. I.e. it has the "guest wifi" address, the LAN address, the DMZ (HA) address - and the RED tunnel address (I launched a RED tunnel on another virtual to watch that flow as well.)

What am I doing wrong here? Has anyone else had this kind of thing happen? The WAN address is an RFC1918 address behind a firewall, if that makes a difference... and I have no real way to change that without doing a creative NAT on my interior firewall...

As long as we use SSL VPN, we have always set the option "Override hostname (optional): SSL VPN clients use the IP address or hostname you enter here rather than the WAN IP address of Sophos Firewall to establish the connection."

I *think* what is happening is that since my virtual windows instance I'm using for testing is on the same "network" as the WAN, the Sophos device is not pushing the WAN interface address into the .ovpn configuration file when provisioning. The interface setups are as follows:

I'm going to spin up a router to put between my virtual machine and my internal network to "buffer" between the virtual sophos and the client. I'm just frustrated if this fixes this issue for 2 reasons:

2. There's no reason you can't sit on the same WAN and connect back to the Sophos box. Especially for testing, not sure what the rationale is for this, other than *maybe* it thinks the incoming client is on a corporate Network being NATted out to the internet - so it puts the internal addresses in scope.

If you don't have "SSL VPN" enabled on WAN in device access, the .ovpn file that the device will deliver to you will not have the WAN interface as a target. Hence, you will only get the LAN interfaces in the file.

The WFA configuration URL set has an outdated URL.

Even if the WFA section was untouched, provisioning will validate and save the current options on screen for all the sections, irrespective of the section that was actually changed.

3a8082e126