Guest User!

You are not Sophos Staff.

SSL VPN "IPv4 lease range" changes OR global settings update gives error "You must enter a network IP address." in SFOS v19.

Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.

Hello Community,

This Recommended Read goes over recent changes made in SFOS v19 related to SSL VPN IPv4

What is the change in SFOS v19 related to SSLVPN IPv4 lease? 

SFOS v19 improves supported SSLVPN concurrent tunnels by 4-5x. 

As a result, there is a change in the configuration of SSLVPN IPv4 lease range. SFOS v19 uses IP subnet value, however, earlier versions used IP range and subnet. 

 Migration will convert the IP range and subnet config from old versions to subnet value in v19. 

 SSLVPN Global config: 

 

Admin has to update IP lease range from IP address to subnet once after migration to avoid error like "You must enter a network IP address." on global settings update.

Am I impacted due to the change? What issue I may face? 

On upgrading to SFOS v19, some users may notice that SSL VPN is connecting but resources are not accessible over SSLVPN for the following conditions: 

  • If you are using SSLVPN prior to v19 version, and 
  • If you have allowed access of SSLVPN users using IP host object of limited range (same as SSLVPN global settings) in firewall rule. 

As v19 changes the limited IPv4 lease range to the larger subnet, users who have got the IP addresses outside the limited range will be restricted by Firewall rule to access the resources. 

How to resolve this issue? 

Update the IP host object of limited range to a;sp include the new IP range (subnet). 

Alternatively, you can start using system host available for SSLVPN IPv4 lease ##ALL_SSLVPN_RW. 

More details on How to configure remote access SSL VPN with Sophos Connect client.



Updated Disclaimer
[edited by: Erick Jan at 1:39 PM (GMT -7) on 17 Apr 2023]
Parents
  • After updating to version 19, VPN users are not able to resolve internal host names. Do we need to make any configuration changes?

    I know work around is updating DNS server under Global VPN setting to our Onsite DNS server but before upgrading to version 19, DNS server for vpn users was IP of SSL VPN Server and it stopped resolving hostnames after update.

  • can you check if SSLVPN server IP is used on tun interface or not in CLI by running "ifconfig"? and which IP was used for SSLVPN server in your setup??

  • Prior to Version 19, first IP of the Range was used as IP of VPN Server, so it was 192.168.5.5. And no, after update, there is no server IP used on tun Interface. 

    Is there a way in GUI, where we can setup SSLVPN Server IP?

  • No that option is not available on UI.

    But as mentioned above we have moved to subnet from IP range, first IP of the subnet will be assigned as SSLVPN server IP. Now we have multiple instances and hence I will not suggest to use it as DNS IP. 

  • Thanks for confirming, so what's the Solution for DNS now?

  • So I just ran into this issue where I had a SSLVPN range defined as the same range I had in the SSLVPN settings and had issue with user not being able to access LAN resournces, all due to the change...I have adjust my VPN rule. But the question I have to ask is it is stated here that the 'first IP of the subnet will be assigned as SSLVPN server IP.'  I am assuming this to mean the SSLVPN DHCP server.  If so, on my connection I am seeing it as the LAST IP (.254). Am I missing something?

  • Hi Lonnie,

    In case of SSLVPN there is no separate DHCP server, openVPN manages the IP lease (dhcp) functionality. When we say "first iP of the subnet will be assign to SSLVPN server" it is used to bind on "tun" interface. 

    From v19 we have introduced multiple instance and hence each instance will create separate "tun" interface and sliced subnet from global config. 

    e.g. For two SSLVPN instance setup, subnet will be splitting into 2 and each one will be used for individual server.

    You can look for more details in the conf file. 

    Hence in this case First IP of both subnet will be used on "tun" interface respectively.

    Hope this clarifies your query.

  • Hi Alok,

    I appreciate and understand (somewhat) your explanation.  My apologies for thinking 'First IP of the subnet' meant DHCP server.  So I understand that now.  I have change the VPN FW rules on my all XGs to use ##ALL_SSLVPN_RW instead of my original IP range which mimiced the v18 SSLVPN assignment range.  That way when I upgrade the other XGs, there should be no issue. All good at this point. I am assuming that the ##ALL_SSLVPN_RW range will not let it assign the DHCP address as an endpoint IP.

    On last question. Are we going to see this same change in L2TP settings in the future, as it was set up similar to SSLVPN with explicit from & to IP range. In v19 it remains as it did in v18. 

    Very much appreciated.

    Lonnie

  • This change in SSLVPN had to introduce as we were not able to scale beyond the certain limit with single server architecture and hence we moved to a multi-instance approach to scale up SSLVPN capacity in terms of concurrent tunnel support as well throughput. 

    We are not planning to make any enhancement to L2TP/PPTP services at the moment so that will stay as is.

  • Hi Alok, so what's the Solution here for DNS?

    When I set DNS to default gateway of SSL VPN, it doesn't resolve hostname as it was prior to upgrade?

    We just have one Instance, so setting default gateway of SSL VPN shouldn't be a problem, but it doesn't work.

Reply Children