Project

General

Profile

Actions

Bug #13624

open

Only one alias in local network of OpenVPN Server works in 2.6.0

Added by Florian Bat over 1 year ago. Updated about 2 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:
amd64

Description

Issue #2668 implemented the possibility to have host/network aliases in the OpenVPN local/remote/tunnel network fields.

When using host aliases in the local network field, it seems only the hosts of the very first alias are pushed to the client as local network. all other aliases seem to be ignored.

Example:
Let's say I have 3 host alias lists (named alias1, alias2 and alias3) with 2 hosts defined in each alias.

Using this as "local network" in the OpenVPN Server definition only pushes the ips of the alias1 list.

alias1, alias2, alias3

This only pushes the hosts of alias2:

alias2, alias3, alias1

And this would push the two hosts of alias1 plus the 192.168.1.0/24 and 192.168.2.0/24 networks as local networks.

alias1, alias2, 192.168.1.0/24, alias3, 192.168.2.0/24

I am using
2.6.0-RELEASE (amd64)
built on Mon Jan 31 19:57:53 UTC 2022
FreeBSD 12.3-STABLE

Actions #1

Updated by Jim Pingle over 1 year ago

Not saying this shouldn't be looked into, but in most cases only one alias is necessary -- create a new alias which itself contains the other three, and then only reference the one alias in OpenVPN.

For example if you have alias1, alias2, and alias3, then create alias_1_3 which has alias1, alias2, and alias3 as entries.

Actions #2

Updated by Florian Bat over 1 year ago

Yes, i can confirm. Only using one alias, which contains the other aliases works and expands all of them.
Ok, this "fixes" it for me, although this is not expected behaviour, since the explanation of the field "local networks" states:

...Expressed as a comma-separated list of one or more CIDR ranges or host/network type aliases...

So I thought i could enter several aliases.

If someone still wants to look into this - it must be the code that expands the aliases:

Looking into /var/etc/openvpn/server1/config.ovpn it looks like this for my first example above

push "route 1.2.3.4 255.255.255.0" 
push "route 1.2.3.5 255.255.255.0" 
push "route alias2 0.0.0.0" 
push "route alias3 0.0.0.0" 

So the first alias1 is replaced with the correct ips, the other aliases are simply not expanded to the list of hosts.

Actions #3

Updated by Jim Pingle over 1 year ago

That is definitely undesirable behavior, but at least it's fairly simple to work around. I'm surprised OpenVPN even accepted those route statements rather than failing to run entirely.

Actions #4

Updated by Florian Bat over 1 year ago

A note about the "workaround":

If you have setup a "meta"-alias, that holds the subaliases as suggested by Jim, adding a host afterwards in one of the aliases will NOT update the local network config.

Only if you ALSO edit/save the master alias afterwards (just open and save it) the expansion of all the hosts will happen in the openvpn config.

Actions #5

Updated by Dean Arnold about 1 year ago

I also discovered this issue in 2.7.0 & 22.x with alias parsing in the all OpenVPN configuration page network fields.

It appears the issues only occurs if there is a proceeding space before the alias e.g. "alias1, alias2, alias3..." then only alias1 is substituted. If you remove the spaces "alias1,alias2,alias3..." all the alias are processed correctly.

This make me believe the alias processing in the OpenVPN pages is not trimming spaces after the comma delimited list has been parsed.

Note, using ", " with IP Networks works as expected.

Jim, as you note, nested aliases definitions are also a valid work around, but only if they are used on their own, or in a comma delimited list without a proceeding space.

Hopefully this is a simple to resolve, and a fix would be greatly appreciated. It took many hours to figure out what was going wrong with recent changes to our multi-site VPN configurations.

Actions #6

Updated by Dean Arnold 12 months ago

Also ran into the sub-alias not updating the parent alias issue as described by Florian Bat.

This had one of our engineers troubleshooting for many hours. It was by chance he resaved the parent alias and connectivity was restored.

It’s difficult to teach an team of engineers these workaround and have them consistently remember.

Jim Pingle any chance of an update/patch for both of these issues?

Actions #7

Updated by aleksei prokofiev about 2 hours ago

The same behaviour on 23.09.1

Actions

Also available in: Atom PDF