Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • Replies 29 replies
  • Subscribers 34 subscribers
  • Views 64682 views
  • Users 0 members are here
Options
Suggested

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

Alok

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.

Overview

This Recommended Read reviews recent changes made in SFOS v19 related to SSL VPN IPv4.

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

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

As a result, there’s a change in the configuration of SSL VPN 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 values in v19. 

 SSLVPN Global config: 

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

Does the change impact me? What issue may I face? 

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

  • If you’re using SSL VPN before the v19 version and 
  • If you have allowed access of SSLVPN users using IP host object of limited range (same as SSLVPN global settings) in the firewall rule. 

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

How do we resolve this issue? 

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

Alternatively, you can use the system host available for SSLVPN IPv4 lease ##ALL_SSLVPN_RW. 

More details on Configure IPsec remote access VPN with Sophos Connect client



Updated links to latest
[edited by: Raphael Alganes at 2:23 PM (GMT -8) on 19 Nov 2024]
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.

  • in reply to Gurtej Sangha

    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??

  • in reply to Alok

    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?

  • in reply to Gurtej Sangha

    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. 

  • in reply to Alok

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

  • in reply to Alok

    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?

  • in reply to Lonnie Thibodeaux

    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.

  • in reply to Alok

    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

  • in reply to Lonnie Thibodeaux

    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.

  • in reply to Alok

    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
Unfiltered HTML