You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When having a gateway configured with a fixed address on a dynamic configured interface, there is a chance a host route is being set before the actual service (such as OpenVPN) has had the chance to configure the device.
This may lead to errors in OpenVPN as described in the log section below.
To Reproduce
Configure a new style OpenVPN server, then update the gateway to contain the other end's ip address and enable monitoring. Next reboot the machine and witness OpenVPN not being able to start. The legacy OpenVPN's seem to be started slightly earlier, in which case such a race condition does not seem to appear.
Expected behavior
To prevent OpenVPN's ifconfig failing, the host route should not exist (as it overlaps with the tunnel). Skipping the host route in these cases is likely the best option.
To avoid the race condition, my suggestion is to check for existence of at least an address on the device in question for the protocol chosen before pushing the host route.
Describe alternatives you considered
none
Relevant log files
Relevant log data from OpenVPN:
Exiting due to fatal error
FreeBSD ifconfig failed: external program exited with error status: 1
/sbin/ifconfig ovpnsX x.x.x.x x.x.x.x mtu 1500 netmask x.x.x.x up
@fichtner I think it is, yes. if you only specify a monitor you may still end up with an expected host route when the service is configured after the monitor.
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Describe the bug
When having a gateway configured with a fixed address on a dynamic configured interface, there is a chance a host route is being set before the actual service (such as OpenVPN) has had the chance to configure the device.
This may lead to errors in OpenVPN as described in the log section below.
To Reproduce
Configure a new style OpenVPN server, then update the gateway to contain the other end's ip address and enable monitoring. Next reboot the machine and witness OpenVPN not being able to start. The legacy OpenVPN's seem to be started slightly earlier, in which case such a race condition does not seem to appear.
Expected behavior
To prevent OpenVPN's
ifconfig
failing, the host route should not exist (as it overlaps with the tunnel). Skipping the host route in these cases is likely the best option.To avoid the race condition, my suggestion is to check for existence of at least an address on the device in question for the protocol chosen before pushing the host route.
Describe alternatives you considered
none
Relevant log files
Relevant log data from OpenVPN:
Additional context
Relevant code sections:
core/src/etc/inc/plugins.inc.d/dpinger.inc
Lines 234 to 241 in 1c86776
core/src/etc/inc/system.inc
Lines 527 to 548 in 1c86776
Environment
OPNsense 24.1.x (amd64).
The text was updated successfully, but these errors were encountered: