Yes, it's getting updated as we speak.

Thanks!!

so in this scenario you'll lose up to 50% of the available IPs, and when you count them in the DHCP leases on XG, you'll find yourself with 16 IPs leased while you configured a range with 32 IPs.

Sound's like a nightmare to debug.

where is that doc change you were mentioning above? I could not find it in the interactive release notes today.

We are talking about "smallest" Network. If you are concern about the range, you can pump this value up to higher values without no problem. And DHCP works not like that in SSLVPN. Essentially SSLVPN works with Pools, you can see here. Not with DHCP Lease Ranges. See Documentation of OpenVPN. 

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.

Hi Gurtej,

when you say default gateway are you setting "tun0" interface IP as DNS server?

e.g. 192.168.5.1 if its (192.168.5.x/24 subnet)

-Alok

Hi Alok,

Yes, you are right. We are setting "tun0" interface IP as DNS Server. e.g. 192.168.5.1 if its (192.168.5.x/24 subnet)

It didn't allow us to save any changes to the IP or the lease. Nevermind, I got up with support and the agent enabled remote support and changed something from the background to resolve this.

When you update IP lease range it will automatically update system host value internally, no need to manually update for system hosts.

Thanks for the update. 

I agree and understand, however, I showcased this to support team too that if I try changing the value for "Assign IPv4 address" and then click save, it used to throw the error "You must enter a network IP address". Only once the support team made changes from the backend were we able to save the changes.