Closed brandlit closed 1 year ago
It was found that the plugin does not register any "newwanip" event which means that once DHCP or PPPoE comes up WireGuard will not reconnect as it should. If anyone want's to take a stab at it please be my guest
CC @jkellerer @patschi @mimugmail
Ok, that means the phenomenon is completely normal at the moment and may be fixed in future updates.
Hi @fichtner, this means technically, in plugins.inc.d/wireguard.inc we need:
function wireguard_configure()
{
return [
'newwanip' => ['wireguard_reload'],
];
}
... and an implementation of wireguard_reload
in the same file?
@jkellerer Basically, yes. However, to avoid spurious reloads said wireguard_reload
function will receive as a parameter the interface name reloading at the moment. I was wondering if an optional interface name selection (multiple would be sane as well for multi-wan perhaps) and then try to reload only the the ones that are bound to said interface(s) to reload when an IP change is happening on them.
It's obviously not a key feature for the current user base so trying to keep it optional would be best?
(I don't have a setup to test but if unconditional reload does not disrupt the tunnelling that would be fine as well and a lot simpler)
I was wondering if an optional interface name selection (multiple would be sane as well for multi-wan perhaps) and then try to reload only the the ones that are bound to said interface(s) to reload when an IP change is happening on them.
I agree
I have tested this briefly by using non existing hostnames, editing the wireguard configuration files directly and starting the service.
Some findings:
If a tunnel has multiple peers and at least one of them fails dns resolution, the tunnel interface is not bringed up.
If there are multiple tunnels and at least one of them is up, the service is considered up in the webui, though service wireguard status
shows an error for the failed interface and returns 1.
You can't use any wg ... <interface>
command if the interface isn't up.
You can't use service wireguard reload
for the same reason.
The only way that I found is to use wg-quick up <interface>
, like wireguard_start
does in /usr/local/etc/rc.d/wireguard
If the interface already exists it just errors out doing nothing, otherwise it brings up the interface with its configuration.
To check which interfaces are up you can use wg show interfaces
, its output is just a line with interfaces separated by space.
Then there is the need to group the interface in the wireguard
group like implemented in /etc/rc.conf.d/wireguard
While looking at that I discovered a new bug which I'll report soon.
The script suggested in the forum resolve-dns.bash, which is meant to be run with cron won't work in this case because it uses wg
.
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
I just ran into this issue of WireGuard not connection properly at startup. As this issue seems not resolved, can we reopen it, please?
Likely fixed by https://github.com/opnsense/plugins/commit/af80514ad84 in 23.7.8.
I'm still experiencing this on OPNsense 23.7.12-amd64. If I use WireGuard with an FQDN it stalls during boot. If I use an IPv4 address it works fine. It would be nice to be able to use an FQDN instead of needing to use a static IP or risk the endpoint dynamic IP changing.
Your issue may be symptomatic to sloppy DNS resolution or intermittent reconnects depending on your WAN type. The result may be that WireGuard isn't up, but it's not the root cause. Given there is no more information it's impossible to speculate (and it doesn't fit this closed ticket).
Thank you, I was going to fill out a new bug report but upon testing this I discovered that my DNS server (AdGuard Home) wasn't up early enough in boot to resolve DNS. Upon testing using an external DNS server, WireGuard resolves as expected.
Ok, glad to hear. 😊
Hello everyone,
I have already reported the error in the Opnsense forum. Unfortunately without success.
Error: If a tunnel endpoint with an FQDN is set up in the Wireguard plugin, the Wireguard service does not start after a firewall reboot.
Reproduction: If I remove the FQDN from the VPN tunnel, the Wireguard service starts directly when the firewall boots.
I have already described everything in the following topic: https://forum.opnsense.org/index.php?topic=30981.0
Regards