openvpn starts before network is up in 16.04 this breaks networking in clouds

Bug #1598522 reported by Stas
48
This bug affects 8 people
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Confirmed
Undecided
Unassigned
openvpn (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hi,
there is a problem in 16.04(which comes with systemd) openvpn-2.3.10-1ubuntu2:
1)openvpn starts before physical interfaces are up
2)and because of this cloud-init(configuration script for all clouds: AWS, gcloud, azure etc) thinks that tun0 is the main interface(few syslog lines are attached).
3) cloud-init then tries to manage tun0 via /etc/network/interfaces.d/50-cloud-init.cfg
like:

auto tun0
iface tun0 inet dhcp

4) which obviously results in a failure to bring up networking:
dhclient[818]: Unsupported device type 65534 for "tun0"
and
localhost systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE

Because of this, in Ubuntu 16.04 on AWS(I actually checked on AWS) if you install and configure openvpn it works well before reboot, and after reboot instance is not reachable via network.

There are 2 possible solutions: fix cloud-init, however, if you think about it, it just iterates through interfaces and it has to take interfaces that are already UP(or default to eth0 if nothing is up). Because, most likely, those interfaces are important.
The second way is to start openvpn after networking is configured and up. I think this way makes more sens(hence creating this report in openvpn package). It is unlikely that you'll be able to use tunnels before physical network is UP, anyway.
I suggest adding
After=networking.service
into [Unit] section /lib/systemd/system/openvpn@.service

Revision history for this message
Stas (ivaschenko-stas) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openvpn (Ubuntu):
status: New → Confirmed
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

There were some recent (still ongoing?) changes on the startup behavior of cloud-init.
Adding a cloud-init task to get Scott/Ryan to comment if they expect that this might fix this issue.

It won't for sure fix the issue that openvpn starts too early, but maybe it should then pick up the right device.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cloud-init (Ubuntu):
status: New → Confirmed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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