Hi.
Item disappeared in the Cron task scheduler "Restart Wireguard service". This item was correct before. I had a task to restart Wireguard once a day. Now I can't create such a task because there is no corresponding item :(. What to do?
Seriously? This ist absolutly essential for WG tunnels. Why should that be deleted?
I'm still waiting with the update to 23.7 to avoid such "surprises"...
I do not know were that item went - but depending on what you want to achieve by that, you could probably use the "Renew DNS for Wireguard on stale connections". Probably this is what you want anyway.
Quote from: meyergru on September 01, 2023, 01:52:13 PM
I do not know were that item went - but depending on what you want to achieve by that, you could probably use the "Renew DNS for Wireguard on stale connections". Probably this is what you want anyway.
Yepp, sounds like a new name for same purpose..
Quote from: meyergru on September 01, 2023, 01:52:13 PM
you could probably use the "Renew DNS for Wireguard on stale connections"
I tried it and it didn't work. This item does not restart the service Wireguard - Connection is not reset, statistics are not reset
As I said: Depending on what you are trying to accomplish. The new service does exactly what the name says. And no, it does not restart the Wireguard service unconditionally.
Quote from: meyergru on September 01, 2023, 04:41:05 PM
Depending on what you are trying to accomplish.
As I wrote above, I need to completely restart the Wireguard service once a day. With connection reset and all statistics. Previously, this was possible using the "Restart the Wireguard service" item. This item has now disappeared. Am I explaining clearly?
Please return the item "Restart Wireguard service" :D
It's a little effort with the console but you can have your own cron jobs in OPNsense, I have one for resetting states (after scheduled firewall rules expire).
https://forum.opnsense.org/index.php?topic=10740.msg49334#msg49334
If you find the old cron job in the source code you can bring it back on your own... ;-)
Quote from: chemlud on September 01, 2023, 06:01:55 PM
If you find the old cron job in the source code you can bring it back on your own... ;-)
Oh... It's complicated. But anyway thanks for the advice. :)
Arbitrary hard restart via cron is not something we need following a better integration of WireGuard as a core VPN service. Besides this gets more and more complicated as there is no service to "restart" anymore with a native kernel interface.
Sure, you can clear the stats, but the downsides of disconnecting on a schedule are not worth it and lead to larger complaints.
Cheers,
Franco
Ok, thanks for the explanation
Quote from: franco on September 05, 2023, 09:32:57 AM
Besides this gets more and more complicated as there is no service to "restart" anymore with a native kernel interface.
Even if this is off-topic:
Will there still be means of forcing a reconnect on stale connections? This is a vital functionality with dynamic IPs, because some connections can only be initiated from one side with CGNAT. If the other side is dynamic IP and stale connections cannot be detected (and re-connected with DynDNS resolution of the new IP (which Wireguard does not do on its own), you are out of luck for a "permanent" site-to-site VPN.
> Will there still be means of forcing a reconnect on stale connections? This is a vital functionality with dynamic IPs
Is that a trick question? Did the protocol at hand design a solution for this? If yes good if not who is responsible to do the "vital" implementation if not the protocol itself?
As far as I understood the "renew" task can help. But the underlying issue is forcing ifconfig to resolve an address at runtime and writing the resulting IP address into the kernel. I'm not sure that's a great idea to begin with...
Cheers,
Franco
Then keeping the plugin is the better solution? Still waiting with 23.7 till I'm definitely sure I don't loose dynDNs and Wireguard site-to-site with dynamic IPs...
No, not a trick questtion at all but you gave the impression that the option of using my cron job to restart when the connection is stale would be removed. I sure hope you can still check if the connection is stale and restart it if not?
What does the new cron "Renew DNS for Wireguard in stale Connections" do?
Is it starting the script "reresolve-dns.sh" from the wireguard-tools provided by wireguard itself?
Then it should work!
@franco
The situation here is, that in germany for example many ISPs have dynamic IPs with forced reconnection once every 24 hours.
So we have to use a dyndns service for wireguard Connections!
> Is it starting the script "reresolve-dns.sh" from the wireguard-tools provided by wireguard itself?
Yes and no. It's the same idea but a different script to avoid bash. It should already work without a cron job on a dynamic connection like PPPoE or DHCP.
> The situation here is, that in germany for example many ISPs have dynamic IPs with forced reconnection once every 24 hours.
Kann ich nachvollziehen. ;)
Cheers,
Franco
Sorry for the late reply!
QuoteYes and no. It's the same idea but a different script to avoid bash. It should already work without a cron job on a dynamic connection like PPPoE or DHCP.
You mean the opnsense box will reresolve the dyndns address, when it self gets a new IP?
But to get the new IP of the peer (when changed) I need to run "Renew DNS for Wireguard in stale Connections" with cron. Am I right?
I now have set the cron to run every minute, so I can see today (the peers DSL is not very stable) or at least tomorrow (after the 24h reconnect) if it has worked ;)
QuoteKann ich nachvollziehen. ;)
Aha, da spricht jemand deutsch :)
But for other users here, I keep writing in english, even when I'm really bad at it :D
@franco
1. your renew script is working :)
2. I think I found the issue, why it resolves sometimes an old ip
I looked in the unbound stats and discovered that the url from the wireguard endpoint addess gets resolved with the unbound cache.
when this entry is old you get the old ip adress, even when the external dns server has the new ip.
Wouldn't it be better to always resolve the endpoint address of wireguard with the external dns server, that are setup @System/Settings/Gerneral ?
So no additional settings are necessary, to have the reresolve cronjob running.
That will only be a problem when you test it, but seldomly in the real world:
All DNS entries have a lifetime, which should be short for DynDNS. All name servers along the way will expire those records after the lifetime has passed. If the DNS records still points to the old peer, the cron job will restart the connection anyway and after a short while, the connection should be up again.
However, note that the cronjob should be called periodically - the python script just checks all wireguard connections once and restarts them if neccessary. I do this every 5 minutes.