Automatically re-resolve DNS in Wireguard

Installing and Using OpenWrt Network and Wireless Configuration
1

Hey guys,
and Sorry for my English translator.
I'm running OpenWRT on a Fritzbox3370 and want to connect via Wireguard client to a remote pfSense, which serves as a Wireguard server and is connected to a DSL connection with changing IP.
A DynDNS account is set up on the pfSense, which is entered in the OpenWRT Wireguard client.
The Wireguard connection works without any problems until the point at which the provider is forced to disconnect from the pfSense. After that, the Wireguard client request probably goes to nirvana until I restart the OpenWRT router/Wireguard.
The problem is known and there are also solutions for it under Linux.

Unfortunately, the description here refers to 'systemd', which unfortunately is not part of the OpenWRT standard. I don't know if there is a way to transfer this to the 'init.d' system.
Has anyone here in the forum had this problem before or can send me a link to it.
Maybe a simple cron job will suffice, but I don't know how to fix the problem with my limited Lunux knowledge.
Thanks in advance for any tip...
hello orca

Routerdaten

Hostname Leonardo
Model AVM FRITZ!Box 3370 Rev. 2 (Micron NAND)
Architecture xRX200 rev 1.1
Firmware Version OpenWrt 21.02.0-rc4 r16256-2d5ee43dc6 / LuCI openwrt-21.02 branch git-21.188.55099-e52e1de
Kernel Version 5.4.137
2

That should help.

https://openwrt.org/docs/guide-user/services/vpn/wireguard/extras#dynamic_address

2 Likes
3

Hello Pavel,
thank you for your help.
This is probably exactly what I was looking for in vain.
Greetings Peter

4

Did it help?
The script is not updating the IP address:

wg owrt
wg owrt1363Ă—511 39.3 KB 

root@OpenWrt:~# wg
peer: ***
  preshared key: (hidden)
  endpoint: x.x.x.130:4454
  allowed ips: 10.10.0.1/32, 192.168.10.0/24
  transfer: 0 B received, 2.89 KiB sent
root@OpenWrt:~# /usr/bin/wireguard_watchdog
root@OpenWrt:~# wg
interface: wg0
  public key: ***
  private key: (hidden)
  listening port: 4454

peer: ***
  preshared key: (hidden)
  endpoint: x.x.x.130:4454
  allowed ips: 10.10.0.1/32, 192.168.10.0/24
  transfer: 0 B received, 2.89 KiB sent
root@OpenWrt:~# ping siteB.example.com
PING siteB.example.com (x.x.x.41): 56 data bytes
64 bytes from x.x.x.41: seq=0 ttl=62 time=9.946 ms
64 bytes from x.x.x.41: seq=1 ttl=62 time=9.952 ms
^C
--- siteB.example.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 9.946/9.949/9.952 ms

Thank you!

5

Hello,
and sorry for the late reply.
I first had to fix my camera system via OpenVPN between pfSense and Fritzbox3370/OpenWRT.
The Wireguard trials just took too much time.
Now for my result...
I currently have a stable Wireguard tunnel running between pfSense (DynDNS-WAN) and a Linksys E4200v2 (OpenWRT) with WAN on an LTE USB stick.
Here 2 x CG-NAT is done by the provider and the stick hardly allows any modification.
After changing the port from 51820 to a lower port and changing the tunnel network to a network in the IP range 172.16.xx.x/24, although the latter was probably not responsible.
I suspect port 51820 is blocked by the provider as the standard port of Wireguard.
The tunnel is now running until the moment I restart the pfSense. I have not yet tried whether it survives a forced disconnection with an IP change on the WAN of the pfSense.
When restarting pfSense, I can only reactivate the tunnel if I restart the OpenWRT router as Wireguard initiator.
I tried using the page linked by @Pawel, unfortunately with little success.
I also don't understand exactly how this is to be used, the 'inner workings' of OpenWRT are still too suspicious for me, even though my Linux knowledge is at a fairly good level. :wink:
Greetings Peter

6

Hi,
is this the solution to my problem?
Enter these commands on the console (logged in via ssh).
Or is there another approach.

Periodically re-resolve inactive peer hostnames for VPN peers with dynamic IP addresses.

# Periodically re-resolve inactive peers
cat << "EOF" >> /etc/crontabs/root
* * * * * /usr/bin/wireguard_watchdog
EOF
uci set system.@system[0].cronloglevel="9"
uci commit system
/etc/init.d/cron restart

The result in /etc/init.d/cron is as follows, Is that correct?

/etc/init.d/cron

start_service() {
        [ -z "$(ls /etc/crontabs/)" ] && return 1

         loglevel="$(uci_get "system.@system[0].cronloglevel")"                     (???)

        [ -z "${loglevel}" ] || {
                /sbin/validate_data uinteger "${loglevel}" 2>/dev/null
                [ "$?" -eq 0 ] || {
                        echo "validation failed"
                        return 1
                }
        }

It doesn't work.
Thanks for the help.
Greetings Peter

7

I went through the wireguard_watchdog script and found the problem. Somewhere along the way I forgot to activate persisent keep alive in the peer settings. After that it works as expected. The script checks if the peers have endpoints, are enabled and if the last handshake is more than 150 s ago. If all conditions are met, the wg tunnel command is rerun, hence, the dns is re-resolved.

8

Does manually run

/usr/bin/wireguard_watchdog

Re-resolve your endpoint?

(Wenn du das script /usr/bin/wireguard_watchdog einfach so ausfĂĽhrst, wird dann die endpoint IP neu gesetzt/aktualisiert?)

9

Hi Penguin,

(Wenn du das script /usr/bin/wireguard_watchdog einfach so ausfĂĽhrst, wird dann die endpoint IP neu gesetzt/aktualisiert?)

Warum nicht gleich so, kann ich mir den Translator ersparen.
Mein Schulenglisch und das biss'l dazu gelernte ist nicht so taufrisch. :rofl:
GruĂź Peter

10

Hi Penguin,
Persistent keep alive is set to 25, so that can't be the reason.
So if the script does its thing as it should, a forced disconnection due to a power failure or a reboot on the pfSense as a WG 'server' should also lead to the automatic restart of the WG on the OpenWRT router.
Have I understood that correctly?
But it doesn't. :smiling_face_with_tear:
Greetings Peter

PS: Perhaps it would be better to 'provoke' a restart of the router with the script. The only question is whether the script would do that if there was a change, or whether there is another error here?

11

And all other people around the world will be forced to use a translator to follow the discussion.
Therefore: english please.

Thanks! :slight_smile:

12

No Problem, tmomas. Can you help?
Greeting Peter

13

Hi,
Since the problem only occurred sporadically, troubleshooting was not easy.
The pfSense as the remote station finally reported sporadic packet loss on the WG-GW.
The OpenWRT router registered a sporadic failure of the WAN-LTE connection.
In the end, the failures happened more and more often until the router no longer allowed a WAN connection at all.
Problem solved, new LTE stick has been ordered.
Thank you for your help.
Greetings Peter

14

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.