Wireguard drops 2-3 times a day

HI,

I would like to know if we can check a log to see if wireguard is the problem? I mean, since a week, I loose wifi, and the problem seems to be wireguard..

thanks

Wireguard doesn't really log things, but you might look at the main log to see if anything is there.

What are your specific symptoms and how have you been testing? And what is the Wireguard connection used for (for example: connect to a commercial VPN service? Road-warrior type to connect back to your home? site-to-site?, etc)?

Let's have a look at your configuration, too.

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

thank you.

yep wg with torguard vpn, pretty stable servers from their side.
I'M using pbr too, also, in pbr, I don't have strict enforcement as killswitch, so I don't know why I loose wifi on all my devices.

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

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

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '5 0t'

config device
	option type 'bridge'
	option name 'br-guest'

config interface 'guest'
	option proto 'static'
	option device 'br-guest'
	option ipaddr '192.168.3.1'
	option netmask '255.255.255.0'

root@OpenWrt:~# 


root@OpenWrt:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option flow_offloading '1'

config zone 'lan'
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone 'wan'
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include 'qcanssecm'
	option type 'script'
	option path '/etc/firewall.d/qca-nss-ecm'
	option family 'any'
	option reload '1'

config include 'bcp38'
	option type 'script'
	option path '/usr/lib/bcp38/run.sh'
	option family 'IPv4'
	option reload '1'

config rule 'wg'
	option name 'Allow-WireGuard'
	option src 'wan'
	option dest_port '51820'
	option proto 'udp'
	option target 'ACCEPT'

config redirect 'dns_int'
	option name 'Intercept-DNS'
	option src 'lan'
	option src_dport '53'
	option proto 'tcp udp'
	option target 'DNAT'

config include 'pbr'
	option fw4_compatible '1'
	option type 'script'
	option path '/usr/share/pbr/pbr.firewall.include'

config zone 'guest'
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config forwarding 'guest_wan'
	option src 'guest'
	option dest 'wan'

config rule 'guest_dns'
	option name 'Allow-DNS-Guest'
	option src 'guest'
	option dest_port '53'
	option proto 'tcp udp'
	option target 'ACCEPT'

config rule 'guest_dhcp'
	option name 'Allow-DHCP-Guest'
	option src 'guest'
	option proto 'udp'
	option family 'ipv4'
	option target 'ACCEPT'
	option dest_port '67-68'

root@OpenWrt:~# 


It is a bad idea to self-reference the dns on your wan. If you don't want to use the DHCP advertised DNS, use a trusted public DNS server.

Meanwhile, I don't see any wireguard configuration at all.

3 Likes

lol, you're right

I changed the router this morning to try a snapshot build..
here we go..

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

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'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '5 0t'

config device
	option type 'bridge'
	option name 'br-guest'

config interface 'guest'
	option proto 'static'
	option device 'br-guest'
	option ipaddr '192.168.3.1'
	option netmask '255.255.255.0'

config interface 'wg'
	option proto 'wireguard'
	option private_key 'iBy3I1CxxxxxxxxxxxxxxxxxLg06is2QEY='
	option listen_port '55042'
	list addresses '10.xx.xx.xx/24'

config wireguard_wg
	option public_key 'InNeWAKxxxxxxxxxxxxxxxxxxxxxx8A+V7Kq7QE='
	list allowed_ips '0.0.0.0/0'
	list allowed_ips '::/0'
	option route_allowed_ips '1'
	option endpoint_host '146.xx.xx.82'
	option endpoint_port '1443'
	option persistent_keepalive '25'

root@OpenWrt:~# 


root@OpenWrt:~# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
	option flow_offloading '1'

config zone 'lan'
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone 'wan'
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wg'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include 'qcanssecm'
	option type 'script'
	option path '/etc/firewall.d/qca-nss-ecm'
	option family 'any'
	option reload '1'

config include 'bcp38'
	option type 'script'
	option path '/usr/lib/bcp38/run.sh'
	option family 'IPv4'
	option reload '1'

config rule 'wg'
	option name 'Allow-WireGuard'
	option src 'wan'
	option dest_port '51820'
	option proto 'udp'
	option target 'ACCEPT'

config redirect 'dns_int'
	option name 'Intercept-DNS'
	option src 'lan'
	option src_dport '53'
	option proto 'tcp udp'
	option target 'DNAT'

config include 'pbr'
	option fw4_compatible '1'
	option type 'script'
	option path '/usr/share/pbr/pbr.firewall.include'

config zone 'guest'
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config forwarding 'guest_wan'
	option src 'guest'
	option dest 'wan'

config rule 'guest_dns'
	option name 'Allow-DNS-Guest'
	option src 'guest'
	option dest_port '53'
	option proto 'tcp udp'
	option target 'ACCEPT'

config rule 'guest_dhcp'
	option name 'Allow-DHCP-Guest'
	option src 'guest'
	option proto 'udp'
	option family 'ipv4'
	option target 'ACCEPT'
	option dest_port '67-68'

remove the listen port.

remove this firewall rule, as it has no purpose (since your WG connection is outbound to another endpoint)

I don't see anything obviously wrong here, but I would recommend setting up a unique firewall zone for your wireguard nework. It can use the same basic settings as the wan zone, and then make sure each zone only contains the respective network.

PBR could be a potential culprit, but we still don't know what the symptoms are of your issue and what specific tests you have run to determine that the wg connection is dropping.

1 Like

but it is what torguard give me as a port in the config file.

about firewall, I did what torguard tuto said..
about test, I did not run test, exept check in the open wrt log

Unless they are connecting to you (unlikely), it is unnecessary (at least in all the experience I have had with WG... maybe torguard is different). Try removing it and see if it still works.

Well, the firewall is setup to allow connections on port 51820, and the listen port is set to 55042... so this would never work. You don't have anything listening on 51820, and as I said before, unless they are connecting to you, a listen port is not typically necessary (and may cause problems instead). The listen port and firewall rule is used for inbound connections, not outbound.

Well, you can get info about the connection by issuing:

wg show

but that's limited in what it will show. You should be running various types of connectivity tests (such as pings, traceroutes, etc.) to determine if the tunnel is actually broken.

1 Like

yes, before, torguard had always the port 51820, dont know now why they changed it

so I can leave empty the port and leave firewall like it is for now.

yes, but I would remove the firewall rule since it is not needed... common practice is to only open ports that are actually needed/used.

1 Like

I could you use that I guess

# Restart services
/etc/init.d/log restart; /etc/init.d/network restart; sleep 10
 
# Log and status
logread -e vpn; netstat -l -n -p | grep -e "^udp\s.*\s-$"
 
# Runtime configuration
pgrep -f -a wg; wg show; wg showconf vpn
ip address show; ip route show table all
ip rule show; ip -6 rule show; nft list ruleset
 
# Persistent configuration
uci show network; uci show firewall; crontab -l

Sure, you could... but I'd recommend that you determine:

  1. is the WG connection actually the problem
  2. if it is, why is it dropping.

One possible reason is if your wan has a short DHCP lease.
what is the output of:
logread -e udhcp (be sure to redact your IP address)

root@OpenWrt:~# logread -e udhcp
Mon Jan  2 17:46:08 2023 daemon.notice netifd: wan (14917): udhcpc: received SIGTERM
Mon Jan  2 17:46:08 2023 daemon.notice netifd: wan (14917): udhcpc: unicasting a release of 24.xx.xxx.0.19 to 172.30.2.2
Mon Jan  2 17:46:08 2023 daemon.notice netifd: wan (14917): udhcpc: sending release
Mon Jan  2 17:46:08 2023 daemon.notice netifd: wan (14917): udhcpc: entering released state
Mon Jan  2 17:46:11 2023 daemon.notice netifd: wan (29712): udhcpc: started, v1.35.0
Mon Jan  2 17:46:11 2023 daemon.notice netifd: wan (29712): udhcpc: broadcasting discover
Mon Jan  2 17:46:11 2023 daemon.notice netifd: wan (29712): udhcpc: broadcasting select for xx.xx.xx.19, server 172.30.2.2
Mon Jan  2 17:46:11 2023 daemon.notice netifd: wan (29712): udhcpc: lease of 24.xx.xx.19 obtained from 172.30.2.2, lease time 3600
Mon Jan  2 18:16:11 2023 daemon.notice netifd: wan (29712): udhcpc: sending renew to server 172.30.2.2
Mon Jan  2 18:16:11 2023 daemon.notice netifd: wan (29712): udhcpc: lease of 24.xx.xxx.19 obtained from 172.30.2.2, lease time 7200
Mon Jan  2 19:16:11 2023 daemon.notice netifd: wan (29712): udhcpc: sending renew to server 172.30.2.2
Mon Jan  2 19:16:12 2023 daemon.notice netifd: wan (29712): udhcpc: lease of 24xx.xx.xx.19 obtained from 172.30.2.2, lease time 7200
root@OpenWrt:~# 


Well, this is possibly why you're having problems. Your lease time is 3600 or 7200 seconds (1 or 2 hours).

Your WAN went down (from the ISP) for 3 seconds or so when one of the renewal attempts didn't succeed before the lease fully expired.

Each time wan goes down and/or your IP changes, you need to restart the wireguard connection.

Take a look at watchcat -- you can use this to restart the WG interface when a new(-ish) IP is issued (it appears you got the same IP as you had previously, but whenever the wan goes down because of the DHCP release, the IP is 'new' from the perspective of the interface which briefly had no address).

is it possible to renew lease time every 24 hours?
but before some days, it was ok..

That's up to your ISP. They control the DHCP server. The server provides a lease and a lease time, and you cannot control or override it. You can ask them if they can make a change to increase the length of the lease, but I'd guess they will say no.

1 Like

Try watchcat and see if that resolves your issue.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

The DHCP is not the problem here. Regardless of how short is the leasetime offered by the ISP, the client initiates a renew at half time of the lease interval. And from the logs it is evident that when the leasetime is 1 hour, the client made a renew at 30 minutes. Same for the 2 hour leasetime, it made a renew at 1 hour. So the DHCP lease never expired.

2 Likes

Ok?

So do you see something to do about it?
Thanks