pfSense

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.

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

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.

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.

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.

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.

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?

The same behaviour on 23.09.1

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