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 30 days 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


Files

OpenVPNAliasError.png (101 KB) OpenVPNAliasError.png Georgiy Tyutyunnik, 03/25/2024 12:12 PM
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 about 1 year 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 1 month ago

The same behaviour on 23.09.1

Actions #8

Updated by Kris Phillips about 1 month ago

  • File OpenVPNAliasError.png added

Reproduced this with a customer. The root of the issue appears to be that OpenVPN is sometimes passing the NAME of the Alias, rather than the CONTENTS of the alias to the client. This results in the OpenVPN client giving a "router parameter network/IP must be a valid address" because it's not either. It's just text. Picture of client's logs attached with redacted OpenVPN server IP.

Actions #9

Updated by Craig Coonrad about 1 month ago

  • File deleted (OpenVPNAliasError.png)
Actions #10

Updated by Craig Coonrad about 1 month ago

  • File OpenVPNAliasError.png added

Re-upload of image provided by Kris with additional information redacted.

Actions #11

Updated by Sean Huggans 30 days ago

Kris Phillips wrote in #note-8:

Reproduced this with a customer. The root of the issue appears to be that OpenVPN is sometimes passing the NAME of the Alias, rather than the CONTENTS of the alias to the client. This results in the OpenVPN client giving a "router parameter network/IP must be a valid address" because it's not either. It's just text. Picture of client's logs attached with redacted OpenVPN server IP.

FYI, I don't believe this is the same issue. The following are the total list of aliases provided in the OpenVPN server config, in order. As you can see, the first one is also in the same state, not passing the contents of the alias either. If I go into each one of these and save it, they start passing the contents of the alias properly. I can also see in the saved status of the openvpn server that we have the contents of the aliases resolved and pushed as routes vs. alias names after saving the aliases. If I reboot the pfsense box the issue re-occurs until I resave the aliases again (I don't have to change anything, just save them).

RemoteAccessVPN_routedurls,CernerRoutes_Main,CernerRoutes_HealthServices

Actions #12

Updated by Georgiy Tyutyunnik 30 days ago

  • File deleted (OpenVPNAliasError.png)
Actions

Also available in: Atom PDF