I'd be willing to buy that reason if it weren't for the fact that a simple restart of the OpenVPN service 2 minutes after the firewall is restarted fixes the issue. This reeks to me of OpenVPN starting before something it depends on being ready, but that's just an outsiders perspective.
Looking at the OpenVPN logs, I noticed 1 line in the logs that isdifferent between when it starts at startup, and when I restart the service. When it fails, I see this additional line in the error log:
GDG: problem writting to routing socket: No such process (errno=3)
If I turn up the log level, I also see a bunch of these in the log at firewall startup:
GET INST BY VIRT: 00:00:5e:00:01:0a@0 [failed]
read from TUN/TAP returned 109
Compared to when I restart the service:
read from TUN/TAP returned 86
Also, if you have an article somewhere explaining why bridged VPN is bad, I'd like to read it, and see if the downsides are relevant for my use-case.
Looking at the OpenVPN logs, I noticed 1 line in the logs that isdifferent between when it starts at startup, and when I restart the service. When it fails, I see this additional line in the error log:
GDG: problem writting to routing socket: No such process (errno=3)
If I turn up the log level, I also see a bunch of these in the log at firewall startup:
GET INST BY VIRT: 00:00:5e:00:01:0a@0 [failed]
read from TUN/TAP returned 109
Compared to when I restart the service:
read from TUN/TAP returned 86
Also, if you have an article somewhere explaining why bridged VPN is bad, I'd like to read it, and see if the downsides are relevant for my use-case.