The missing part is to confirm whether creating a file in /etc/systemd/system/[email protected]/ succeeds without any problem (in case the directory does not exists or something like this).

The behaviour is not super-obvious, as there are multiple scenarios of TUN device failing

1. VPN goes down but TUN device exists
2. VPN goes down and TUN device disappears

The current behaviour of the border router is not very obvious (or logically explainable) with respect to it's autorecovery capabilities - in all the cases it keeps running, but in some of them even after VPN is back, SCION is not coming back till border router is restarted.

Having UDEV rules installed means there is an automatic recovery in case the VPN interface comes back again. The behaviour is as follows

• border router is running only if TUN device is working properly
• TUN device going down means border router goes down
• TUN device reappearing means border router starts again

I'm a bit scared of the complexity that is added here... Maybe we could use a simpler solution; either allow the router to bind to 0.0.0.0 and completely eliminate this problem (scionproto/scion#3395) or fix the router to shut down or retry properly on on fatal errors

I completely agree with above. This code in here is just a workaround for the issue because (1) I do not believe at the moment it will be fixed upstream any time soon and (2) the current behaviour is severely flawed

Note: the BR behaviour has been improved (a long time ago) to die properly in the case an interface goes down. This makes this issue a lot less severe.