-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wireguard: not fully configured after reboot #7148
Comments
I have the same behavior with Wireguard interfaces. Just saving a rule without changing anything and reloading the firewall restores functionality. Unfortunately I have not found and log entries suggesting some kind of error. |
This has been known to happen for unknown reasons unfortnately. Can you post Cheers, |
I have captured Can I send you the logs via e-mail or such? Appending sensitive information on a public issue doesn't seem like the best idea :) |
Sorry, the file is You can send it to franco@opnsense.org Thanks! |
Yep, that one works :)
Done. |
Hello, I have the same issue as boomer41. If there is something I can provide as well let me know franco. Regards, |
I posted this on my thread on the forums, however if someone is wanting a quick emergency fix, have a quick look at this gist. https://gist.github.com/Westie/5557cffd927dd32de93255e5ac4a22e0 Feel free to adjust as needed! |
It appears that the current code has issues with assigned wireguard instances and you can try this patch on 24.1 and above: 9e01b27
I'm not 100% sure it solves the issues reported, but it will bring us to a more consistent outcome after reload which can reveal another underlying issue better. Cheers, |
I have applied your patch, but the issue still persists the same way :( |
@boomer41 from your output that seemed to be the obvious issue and I could reproduce. Can you send me the new data gathered the same way but with the patch applied? The rules looked good in both cases (no diff between them) so I suspect a more fundamental issue relating to VIPs or DNS resolution or requiring overlap in connectivity (boiling down to route complexity) which I can't see from these files gathered, but step by step will do it. So just to be clear after reboot it doesn't work and then you do "x" and it works? What is "x" in precise terms again so I can focus on this. Thanks, |
Logs sent via mail with the patch applied. As stated in the email, I just log on to the management UI, edit & save some arbitrary rule to get the "Apply changes"-Button. After hitting that apply button, things start working. |
Can you confirm that running
Does the same thing? |
Can confirm. Running that command fixes the issue the same way as the UI way does. |
…alls its own routes, we are not able to track them properly. If that's the case and the user reconfigures, drop all interface addresses instead of removing the interface (and creating it again). There is a small chance of remnants after the fact, but dropping the interface is more problematic to recover from as it will invalidate filter rulesets as well. The user is still able to force a stop/start using the reload action, which also reloads the filter after the fact. proposal for #7148
Here is a backport of our recent efforts which adds cleanly to 24.1.2 7d35204f2a, to apply:
Cheers, |
I've tried the patch on 24.1.2 sadly didn't fix the problem for me. After the reboot issue still present.
Regards, |
Reversed all debug patches and applied this one. |
@SeimusS what was "the problem" again? There have been overlapping issues but some are beyond our control, especially with DNS-based endpoints and dynamic connections. @boomer41 ok, that's good. We'll be adding this to 24.1.3 to bring us closer to being able to identify other issues then. Cheers, |
@boomer41 @fichtner When hitting the apply button in FW > NAT > Outbound or using "configctl filter reload" it starts to work normally again. edit: I use RA setup, DNS is not OPNsense but on RPi. Regards, |
The wireguard logs with the patch applied might help pin this down further. Basically it tries to retain wireguard interfaces so that NAT et al are applied correctly all the time. Not sure where the issue now lies. Are your endpoint addresses using hostnames instead of IPs? |
@SeimusS Ok, it would be better to start with the basics as described in #7148 (comment) sent to franco AT opnsense DOT org |
Done, logs generated (& sent to you) as per the comment mentioned after reboot, pre and post reapplying the NAT rules/"configctl filter reload" Let me known if you need anything else from my OPNsense box. Regards, |
…alls its own routes, we are not able to track them properly. If that's the case and the user reconfigures, drop all interface addresses instead of removing the interface (and creating it again). There is a small chance of remnants after the fact, but dropping the interface is more problematic to recover from as it will invalidate filter rulesets as well. The user is still able to force a stop/start using the reload action, which also reloads the filter after the fact. proposal for #7148
In accordance with @SeimusS we're closing this issue and wait for other user reports or code changes to make the problem more visible. The main problem reported here, however, has been fixed since 24.1.3. Cheers, |
Hallo Franco I do still have issues with Wireguard from surfshark. Every update (OPNsense 24.1.7) i am applying this opnsense-patch 7d35204 and it works but is this the way i have to make my wireguard wotk? cheers |
@illum1n4ti it depends how old your initial setup is and what "have issues" means? There have been a lot of individual cases that were cleared up and re-applying the patch just removes it so you are going backwards in time... |
@fichtner Thank u for your replay thanks to the patch i still can use Surfshark VPN with WireGuard, but i am afraid with the patch i am using old protocol plus maybe there are bugs for security reasons I hope u could give me some advise |
Common mistake was that assigned wireguard interface had IPv4 mode not set to "none" (IPv6 mode too) which is now prohibited and IP address needs to be set in instance as "tunnel address". Brought it back to life for most people. |
I had the same issue with 24.1.10, seems to be related to NAT. I was able to get things working by following Step 4(b) in the documentation (even though it says this step is not necessary) - https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-4-b-create-an-outbound-nat-rule |
The problem is still not solved. Automatic NAT rules are still not added to the Wireguard interface, they appear in the GUI but they are not in the debug files. Only after restarting the rules via GUI or console they are added. Does anyone have any solution? Maybe you @fichtner would have a solution? I have manual rules set but I wonder why the automatic ones don't work. |
@itsMaxio If I remember correctly I have the same problem or similar problem you reported. Basicaly WG is working but only able to access LAN related stuff not able to access Internet as the Automatic NAT rules are missing when checking the debug. Tried to Tshoot it with Franco's help but I couldn't find why its happening. So I have currently a permanent workaround in place that reloads the filter 2s after boot. 1. Create a file in the rc.syshook.d/start/ called 92-wireguard-firewall-workaround 2. Put in
This basically makes sure in case the device gets rebooted the Wireguard will work as intended. You also may want to open a new Ticket for this WG issue as this thread was closed with a PR fix. Regards, |
Even when i did add your workaround script to Opnsense i still need to manually reload Wireguard service each Opnsense restart :( |
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
Describe the bug
Hello I have a bug.
I have a wireguard tunnel for friends and family to reach my services.
I didnt change any rules for weeks everything was fine I just updated and rebooted and then my rules didnt apply anymore.
I just need to add a new one, delete the rule and apply so anything is as before and everything is working...
on the top the green ones are the rules after adding a dummy rule and delete it...
See Screenshots:
wireguard connection is also stable and connected
my aliases debiandocker contains: 192.168.189.3
httphttps: 80, 443
DNS: 53, 853
see screenshot
I use a VM running on proxmox
The text was updated successfully, but these errors were encountered: