Cluster and route mode - possible?

[chort1]

Hi

I'm running a cluster with round-robin DNS, but I'm having problems understanding how to make routed mode work with this setup

In the admin web GUI, there an option that says:
Dynamic IP Address Network
When a user does not have a specific VPN IP address configured on the User Permissions page, the user's VPN client is assigned an address from this network.
From memory I think this defaults to 172.24.224.0/20 (in sacli this split into vpn.daemon.0.client.network and vpn.daemon.0.client.netmask_bits)

However, when I connect a client, it DOES NOT get an IP from this subnet, but rather from 172.24.240.0/20, which in sacli is vpn.server.group_pool.0 and does NOT seem to be available to change via the admin GUI. If I change it through sacli, it will change for both nodes, since it seems to be a global setting.

So if I'm NOT doing NAT on the access servers, and the clients are getting IPs from the same subnet regardless of which server they connect to, how can I configure return routing from my inside network?

[openvpn_inc]

Hello chort1,

Routed mode is not a supported use-case for cluster mode at this time. Only NAT is.

We do intend to add ability to set specific subnets for each cluster node so routing can work, but this is something for a future release of Access Server.

Kind regards,
Johan

[chort1]

Hi Johan

I understand. Thank you for the quick reply and clarification

[openvpn_inc]

And I have been annoying poor Johan with my nagging about this. It's a feature that a lot of large customers want. But he's rightfully focused on getting another important new feature ready, so I have to put up with it.

regards, rob0

[tarare]

Hi!
+1 to wishbox for this functionality)
I am currently looking for a VPN solution for a corporate network. Testing OpenVPN-AS. Everyone likes the solution, but we need a route mode in the cluster. It is not yet available in the latest version 2.10.3.
Correct me if I'm wrong, but it seems to me that in the code you can just leave the value "vpn.server.group_pool.0" in the local database ~/db/config_local.db, not transfer it to mysql when creating the cluster. Maybe there is a test assembly with such a value in the code for testing?
Thanks

[openvpn_inc]

Hi tarare,

I thought the same thing and tried it, but no, it gets overwritten by what's in mysql. I do think that the fix the reporter had in mind is indeed very similar to that idea, which is to move it out of "config" into "config_local".

How many concurrent connections are you needing? Perhaps you can hold off on moving to cluster simply by improving the resources allotted to your Access Server. 4 CPU cores and 4-8GB RAM, given adequate bandwidth, can handle a lot of clients.

For HA you could consider adding a UCARP failover peer.

regards, rob0

[tarare]

Hi rob0,

Thank you for the answer)
I don't know exactly the number of concurrent connections yet, the project is under development, according to forecasts ~ 100-200 ones.
It's more a question of geo-reserving nodes and reducing delays from clients to the VPN server through the DNS geolocation service. Nodes should be located in different countries where there are company resources and employees.
I have also tried writing directly to the mysql (as_config) and sqlite (config_local) databases, they are overwritten by the "sacli" working script. The question is just to edit the service code to make the "vpn.server.group_pool.0" parameter available only in the local config_local database, without transferring it to mysql, similarly like "vpn.daemon.0.client.network". This would allow assigning group addresses of clients independently on each node of the cluster to implement route mode.

[openvpn_inc]

Hi tarare,

My suggestion is then to stick with single nodes or failover pairs. You can share the single subscription license among as many Access Server instances as you need, and you can use site-to-site tunnels to make your geo-diverse VPNs all interconnected.

Probably in a year or two we should see this fixed. I can't promise when (I am not in the development team), but I expect that over time, nagging will increase.

Thanks for your interest in Access Server.

regards, rob0

[agirling]

+1 on this use case. I also am evaluating OpenVPN AS in a geo-diverse configuration. I'll try reconfiguring as single nodes in the interim.

[Safren]

Unfortunately this feature is not yet available in the latest version 2.11.3. But it can work if you don't use groups at all. Although it is not comfortable and not obvious.

[openvpn_inc]

Hello,

OpenVPN Access Server 2.12.0 now supports setting different group default address pools per node. That allows return routes to be setup and then routing can work.

Kind regards,
Johan

[misterm32]

Hello,

OpenVPN Access Server 2.12.0 now supports setting different group default address pools per node. That allows return routes to be setup and then routing can work.

Kind regards,
Johan

Hi,

Is it possible to have more information about that feature?
We just build a cluster and we do not have that function.

In the cluster setting, we see no options fir IP setting in the group Permissions.
In the node setting, the group Permission settings are grey out and we can't do any modfifications.

Thanks,

Michel

[openvpn_inc]

Hi,

That new feature is "Added option to specify group subnets per cluster node to allow routing to work in clustering"
And it is configurable under Configuration>VPN Settings>Group Default IP Address Network (Optional).
Subnet under Group permissions is not possible.

Regards,
.\kionci

[dsmoljan]

I have a followup question.

Is group access control able to work with routing in cluster mode? We have 3 node cluster and routing setup on each node; then in global group permissions we set the access control but it doesn't seem to have any effect.

[openvpn_inc]

Hello dsmoljan,

Yes, group access control works with routing in cluster mode. You say it doesn't seem to have any effect, but without knowing more about your situation it's hard to diagnose why it doesn't seem to work in your case. One thing to keep in mind is that access control works additive in Access Server. For example if you want to separate access rules between different groups so that group A gets access to subnet 1, and group B gets access to subnet 2, you'll need to ensure you haven't already given 'everyone' on the server access to subnet 1 and 2 already under VPN Settings. Because that inherits down to all groups and all users, making your attempt to separate it ineffective.

Kind regards,
Johan