Wireguard config after sysupgrade

[Peacefuleight]

wifi only cause when the router is up after reboot and upgrade, I can access to 192.168.1.1 for LuCi via web browser but I don't have wifi to browse on internet and it is about wireguard only

[psherman]

remove the metric on the wan interface. Stop the wireguard interface, then restart the wan interface.

@Peacefuleight

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'
        option metric '1024'
        option peerdns '0'
        list dns '1.1.1.1'
        list dns '1.0.0.1'

[Peacefuleight]

I did it so I can try a sysupgrade to see the result

[Peacefuleight]

also maybe you can check here, if the problem is here;

[Peacefuleight]

after sysupgrade, same, I needed to re enter new config

[psherman]

You didn't mention that you were using PBR... you'll neeed to change the policy if WG isn't working.

[psherman]

I still have difficulty believing that this is truly required...

However, another possible issue is that the router may have the wrong time. If the time is wrong, WG will not connect.

[Peacefuleight]

but the policy about Strict Enforcement is DO not enforce...

before I used the open wrt ntp but an hour ago I tried google ip address, same

[Peacefuleight]

maybe I would need to put a delay on wireguard like we did on dd wrt

[psherman]

Initiate wireguard after NTP success

OpenWRT forums RIP, not sure where to post a feature request/bug for the next LEDE / Wireguard release. Most of our consumer/entry LEDE routers do not have a battery keeping date/time. The current NTP client method in LEDE is prohibitive of correct and reliable wireguard working. Since Wireguard is highly dependent on correct date/time, please make sure: The NTP client is redesigned to load at the very beginning of LEDE bootup, before all else. The NTP client is redesigned to not bug as desc…

[Peacefuleight]

I domt know if I could do something with that to adapt to our situation with wireguard to delay.

As for /etc/rc.conf:

    Check that there is no reference or use of ntpdate(8) anymore
    add:
    ntpd_enable="YES"
    ntpd_sync_on_start="YES"

and

Further testing shows that over time (about an hour), the ntpd time sync brings down the time gap enough to allow the windguard client-server handshake to succeed. So a revised problem statement would be "After reboot, Wireguard client-server handshake fails due to client system clock being out of sync. Handshake eventually succeeds, but results in a too long window of inactive connectivity."

Regarding the rc.d service execution order, adding condition 'REQUIRE: NETWORKING ntpd' to file '/usr/local/etc/rc.d/wireguard' makes ntpd start before wireguard.

rcorder /etc/rc.d/* /usr/local/etc/rc.d/

/etc/rc.d/DAEMON
/etc/rc.d/ntpd
/usr/local/etc/rc.d/wireguard

[ninjanoir78]

I see many solutions on that link, which one would be the best to add delay to wireguard during ntp time?
thanks

[psherman]

This general thing has been on my to-do list, but I haven't yet tried any specific solutions for launching wireguard after ntp succeeds.

my hunch, though, is that the most efficient method of doing this is the method that calls a script from rc.local... it will wait until there has been ntp success and then will call ifup to your wireuard interface. You'll setup your WG interface to not come up on boot so that it doesn't start until it is called by the script.

[ninjanoir78]

maybe with hotplug

/etc/hotplug.d/ntp/90-wireguard

#!/bin/sh
 
[ "$ACTION" = stratum ] || exit 0
ubus call network.interface.WireGuard up

[Bill]

@psherman

However, another possible issue is that the router may have the wrong time. If the time is wrong, WG will not connect.

@Peacefuleight

Further testing shows that over time (about an hour), the ntpd time sync brings down the time gap enough to allow the windguard client-server handshake to succeed. So a revised problem statement would be "After reboot, Wireguard client-server handshake fails due to client system clock being out of sync. Handshake eventually succeeds, but results in a too long window of inactive connectivity."

Chasing this issue down to correct time, question, has your customization of rc.local made your systupgrade a smooth and reboots successful?

@ninjanoir78

I see many solutions on that link, which one would be the best to add delay to wireguard during ntp time?

I install ntpdate on OpenWrt for the sake of a commercial WireGuard key renewal script. Alongside a rc.local command that was picked up in another thread about the "Chicken/Egg" issue.

Having just accidentally unplugged my router a few hours ago, I looked at the system log:

log snip

Sun Jan 29 13:22:26 2023 daemon.info dnsmasq[1]: read /etc/hosts - 4 addresses
Sun Jan 29 13:22:26 2023 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Sun Jan 29 13:22:26 2023 daemon.info dnsmasq[1]: read /tmp/hosts/odhcpd - 0 addresses
Sun Jan 29 13:22:26 2023 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Sun Jan 29 15:03:32 2023 daemon.notice ntpdate[2492]: step time server 69.89.207.99 offset +6064.732919 sec
Sun Jan 29 15:03:32 2023 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/network
Sun Jan 29 15:03:32 2023 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/wireless
Sun Jan 29 15:03:32 2023 user.notice ucitrack: Setting up /etc/config/luci-splash reload dependency on /etc/config/firewall
Sun Jan 29 15:03:32 2023 user.notice ucitrack: Setting up /etc/config/qos reload dependency on /etc/config/firewall
Sun Jan 29 15:03:32 2023 user.notice ucitrack: Setting up /etc/config/miniupnpd reload dependency on /etc/config/firewall
Sun Jan 29 15:03:32 2023 user.notice ucitrack: Setting up /etc/config/odhcpd reload dependency on /etc/config/dhcp
Sun Jan 29 15:03:33 2023 user.notice ucitrack: Setting up non-init /etc/config/fstab reload handler: /sbin/block mount
Sun Jan 29 15:03:33 2023 user.notice ucitrack: Setting up /etc/config/system reload trigger for non-procd /etc/init.d/led
Sun Jan 29 15:03:33 2023 user.notice ucitrack: Setting up /etc/config/luci_statistics reload dependency on /etc/config/system
Sun Jan 29 15:03:33 2023 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/system
Sun Jan 29 15:03:33 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 203.114.74.17
Sun Jan 29 15:03:33 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.123
Sun Jan 29 15:03:33 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.123: offset:+0.009553 delay:0.036000 status:0x24 strat:3 refid:0x5a099d0a rootdelay:0.003449 reach:0x01
Sun Jan 29 15:03:34 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 203.114.74.17: offset:+0.018368 delay:0.304106 status:0x24 strat:3 refid:0xdc738195 rootdelay:0.051331 reach:0x01
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 203.114.74.17
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.123
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.123: offset:+0.007741 delay:0.033348 status:0x24 strat:3 refid:0x06085e0a rootdelay:0.003449 reach:0x03
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S96led: setting up led Internet
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S96led: setting up led LAN1
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S96led: setting up led LAN2
Sun Jan 29 15:03:35 2023 daemon.notice procd: /etc/rc.d/S96led: setting up led LAN3

[Peacefuleight]

[quote="Bill, post:25, topic:149666, full:true"]

Chasing this issue down to correct time, question, has your customization of rc.local made your systupgrade a smooth and reboots successful?

no, I dont know very well rc.local and scripts, but my sysupgrade are successful except wireguard

I install ntpdate on OpenWrt for the sake of a commercial WireGuard key renewal script. Alongside a rc.local command that was picked up in another thread about the "Chicken/Egg" issue.

ntpdate, needs some setting ?

[Bill]

Been seeing this blank reply on my side since you posted. Thought I break out the toolbag...

So the answer is ntpdate is seen in the log file entry rectifying the time discrepancy on it's on (without user side config), before the custom rc.local command picks up time several lined down.

That command is:

ntpd -d -n -q -N -I XXX -p 162.159.200.123 -p 203.114.74.17

Where "XXX' is my wan ip device and the ip's are just time servers.

[Bill]

@Bill

Alongside a rc.local command that was picked up in another thread about the "Chicken/Egg" issue.

This is the thread and solution I mimic to alleviate who's gonna win.

Local time keeps changing on router reboot/power off&on

Having had this issue, and following the links: Race Condition to the Forum I used @sammo suggestion w/ @lleachii's IP suggestion and made a rc.local scheduled task. On top of that I added ntpdate package. The picture demonstrates (in my case), that the last edited file on my system was quite dated (Fri Jun 1 time). Yet, the wg0 interface came online (sswg), time was restored, time was checked again by ntpd and what is not see thereafter is not important because I'm running online, VPN Wir…

[Peacefuleight]

Finaly after wg configuration, and sysupgrade / reboot, no wifi causing by wg, but I really think the problem is with torgard vpn provider.

[Bill]

After all the work done concerning having correct time; as it has been determined from several post and reading several threads that this issue is main culprit in case that the key exchange fails.

Stating this to start, as it would be incumbent to monitor the newly flashed router via cable to watch the known triggers for failure before exclaiming wifi or Torguard is the culprit. Wifi is but one of two methods in internet access.

Two items come to mind.

• Did the router have correct time corrections in the log and how soon after reboot? Remember the wg0 peer key exchange happen over a default gateway. And you have known good keys!
• Did you pay any attention to the PBR Gui and try any of the steps in toggle the service status. Can you delay the service start or disable this service across sysupgrades.

Looking back at the configs you posted, I see you have setup wg0 in the wan firewall zone. This passes all traffic thru the wg0 interface as you know, meaning that PBR is not necessary to manage your traffic. As it appears that you want all your browsing going thru TorGuard's wg0 interface.

If this is true in all but a few cases, you had a 1024 metric in the wan zone which in my case makes perfect sense as it allows you to run ifup wg0 and ifdown wg0 to shut the tunnel down an browse "naked" on the ISP.

If you can, do your testing via cable and continue to monitor the time.

---

Question: Assuming you have gotten back online via TorGuard with the old trick: get new keys and IP (assuming that's an endpoint) AND YOU ARE NOW ONLINE
.. what happens if you drop your old network stanza's for wg0 into your active connection and
uci commit network; /etc/init.d/network restart

That scenario would effectively test the known connected internet with against the previously known good keys. Proving that this is not some rouge expiring key glitch or TorGuard.