Problems & Suggestions for incomplete OpenVPN document

Bug #1870120 reported by Steve Valliere
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Server Guide
New
Undecided
Unassigned

Bug Description

Situation: clean install of Ubuntu 18.04.4

Experience: followed steps in https://help.ubuntu.com/lts/serverguide/openvpn.html to the letter (with a second person double checking each step and marking them when completed.)

Problem #1: It can be quite difficult to determine which commands must be entered as root or as regular user. Most explanations that use a similar format always include either the '#' or '$' prefix to indicate that the command should be entered as root or regular user (respectively). This page occasionally says to do something as root, but never seems to say when to STOP being root, though there must be times when that is appropriate because there are some sudo commands and root doesn't need to use sudo (does it?)

Problem #2: When I reached the 'Now start the OpenVPN client:', the server failed to start because of a missing ta.key file. This key command was omitted:

openvpn --genkey --secret ta. key

Problem#3: Various different IP networks used without explanation. For example, all of these are used in the document:

10.8.0.0/24
10.8.0.1
10.8.0.2
10.8.0.4
192.168.122.1/255.255.255.0
10.8.0.6
10.8.0.5
192.168.42.0/255.255.255.0
192.168.0.0/16
10.0.0.0/255.0.0.0
10.0.0.2
10.1.0.2
10.0.1.100/24
10.0.1.1
10.0.0.4/255.255.255.0
10.0.0.128
10.0.0.254

Very little is actually explained about things like pushing routes or dhcp-options (at least links to documentation about these activities and commands are necessary.)

Problem #4: After following the steps in Advanced bridged VPN configuration on server, these messages appeared in the syslog every time I tried to start openvpn (time & hostname removed):

systemd-udevd[1455]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
systemd-udevd[1455]: Could not generate persistent MAC address for tap0: No such file or directory

The only fix I could find on line was to

cp /lib/systemd/network/99-default.link /etc/systemd/network/99-default.link

and then change MACAddressPolicy from persistent to none. Unfortunately, I have no idea what ELSE this may impact.

From that point on, things went reasonably well, except that once the client connects to the server, it cannot perform ANY communication using the new VPN. It cannot ping the server or any addresses on the bridged network.

I believe that the document may be missing one or more critical steps about routing and/or activation of the tap0 device that are required for the bridged configuration to work. After following the document to the letter, the tap0 device still shows as state DOWN with an ip a command, even when a client is connected!

I really, REALLY think that these documents should be actually tested instead of just cobbled together from different sources without any actual verification of correctness. The effort is appreciated (especially the netplan part, since no one except Ubuntu appears to support that -- certainly not the OpenVPN folks [they told me so, flat out.])

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.