Question - anticipated timeline for fix of openvpn issues in 1.3?

Development
1

I’ve been very happy with VyOS since getting 1.2.5 setup in my home environment. Was hoping to help contribute with testing 1.3 rolling releases but encountered an issue with OpenVPN which I subsequently discovered already had a bug report for:

https://phabricator.vyos.net/T2113

I rely on OpenVPN for default policy routing of network traffic and so this issue makes 1.3 impossible for me to use. Any timeline for when this and other OpenVPN bugs will be fixed? I’m not trying to be demanding, just want to help with the testing/development cause and am unable to for the time being.

2

Did you perhaps link to the wrong Phabricator task?

I’m pretty sure rolling is still using Openvpn 2.4 so you should be able to use the workaround.

Also how does the bug you’ve linked to relate to routing at all?

3

The issue is that none of my OpenVPN connections will connect due to the bug listed in that entry. I get the very error listed in the bug report and see no way to work around it. Bug report indicates that VyOS could be coded to make “compat-names a configurable option that defaults to disable” but this doesn’t appear to have been implement as far as I can tell. So, if the OpenVPN connections won’t connect, I have no path to route through. What functional work around do you see in the big report?

4

I’m very sorry, I ended up reading and looking at ⚓ T1512 vyos 1.2 openvpn client names with spaces created incorrectly - the bug that was linked from the bug you posted. I do apologise for the confusion - I’m the one reading the wrong phabricator task.

You’re right - I see no way to work around this other than to manually hack at the Openvpn template file to remove that option.

5

As a really hacky workaround, you could try commenting out line 252 in

/usr/share/vyos/templates/openvpn/server.conf.tmpl and see if when you re-save your openvpn config in vyos it is generated without that line.

6

No worries. Glad to have someone confirm I’m not crazy. I’m using the same configuration from my working 1.2.5 instance so I’m not sure what has changed except the version of OpenVPN.

7

I’m not running a server, just a client to expressVPN. Based on the configuration file name, it would seem to only work for server configs. I’m not at the router in question right now so I’d have to check in a bit.

8

Are you sure the problem you’re hitting is related to that compat setting?
Be good to see the actual error output and your generated (vyos) openvpn config.

9

This is the error I am getting when I issue a “show log openvpn” command"

May 26 10:18:16 vyos systemd[1]: openvpn@vtun0.service: Service RestartSec=5s expired, scheduling restart.
May 26 10:18:16 vyos systemd[1]: openvpn@vtun0.service: Scheduled restart job, restart counter is at 5.
May 26 10:18:16 vyos openvpn-vtun0[8203]: DEPRECATED OPTION: --compat-names, please update your configuration. This will be removed in OpenVPN 2.5.
May 26 10:18:16 vyos openvpn-vtun0[8203]: Options error: you cannot use --verify-x509-name with --compat-names or --no-name-remapping
May 26 10:18:16 vyos openvpn-vtun0[8203]: Use --help for more information.
May 26 10:18:16 vyos systemd[1]: openvpn@vtun0.service: Main process exited, code=exited, status=1/FAILURE
May 26 10:18:16 vyos systemd[1]: openvpn@vtun0.service: Failed with result ‘exit-code’.

my config is as follows:

vyos@vyos# show interfaces openvpn vtun0
 authentication {
     password MINE
     username ME
 }
 description ExpressVPN_DC
 hash sha512
 mode client
 openvpn-option --fast-io
 openvpn-option "--tls-auth /config/auth/tls1.key"
 openvpn-option --persist-key
 openvpn-option --persist-tun
 openvpn-option --nobind
 openvpn-option --pull
 openvpn-option --remote-random
 openvpn-option "--comp-lzo no"
 openvpn-option --tls-client
 openvpn-option "--ns-cert-type server"
 openvpn-option "--verify-x509-name Server name-prefix"
 openvpn-option "--key-direction 1"
 openvpn-option "--route-delay 2"
 openvpn-option "--tun-mtu 1500"
 openvpn-option "--fragment 1300"
 openvpn-option "--mssfix 11200"
 openvpn-option "--verb 3"
 openvpn-option "--sndbuf 524288"
 openvpn-option "--rcvbuf 524288"
 openvpn-option --route-noexec
 persistent-tunnel
 protocol udp
 remote-host usa-washingtondc-2-ca-version-2.expressnetw.com
 remote-port 1195
 tls {
     ca-cert-file /config/auth/ca1.crt
     cert-file /config/auth/client1.crt
     key-file /config/auth/host1.key
 }

This exact config is working on my 1.2.5.

10

You should be able to remove this and have it then connect. Worth a try.
Also I think you might want to fix your mssfix 11200 because I think you might have either an extra 1 or an extra 0 there. Surely you mean 1200 or 1120?

1 Like
11

Apologize for not responding sooner. I updated the bad mssfix value, removed the openvpn-option “–verify-x509-name Server name-prefix” and added an option indicating that the protocol was UDP. Client connected and was passing data as expected. I know there’s the request for an OpenVPN client import feature like Ubiquiti has on their Edgemax line. Would add my 2 cents that this would be a great feature to see in VyOS.