You only need to provide LAN IP addresses, not remote IP addresses. That means however that if you have site-specific routing for some clients, there's no escaping - the client will need to be completely excluded from flow caching.
Wireguard Session Manager (4th) thread
- Thread starter Martineau
- Start date
lluke
Occasional Visitor
Hi all,
I've switched from OpenVPN to WireGuard to create a site2site connection between 2 RT-AC86U and I'm facing issues (on both routers) with the internet connectivity in some specific situations.
Whenever there is a connectivity re-connect (also done from the scmerlin add-on Internet Connection restart action) or a VPN change (e.g., updating and saving the IPSec VPN Server config) then every service on the router is properly working (Unbound DNS, WireGuard tunnel, IPSec Server, Yazfi Networks) but the internet connectivity is not working anymore for any client connected to the network.
I've checked the 'iptables -vnL FORWARD | grep wg' rules as described in the first page of this thread but I see the same entries before and after triggering the issue.
I've also tried to apply the "sleep" workaround suggested for the firewall-start script but the issue is still here.
My current setup on both routers is:
YazFi v4.4.2
Unbound Manager v3.22
ntpMerlin v3.4.5
scMerlin v2.4.0
WireGuard Mgr v4.18
Any advice on how to better investigate (and hopefully solve) the issue would be more than welcome.
I've switched from OpenVPN to WireGuard to create a site2site connection between 2 RT-AC86U and I'm facing issues (on both routers) with the internet connectivity in some specific situations.
Whenever there is a connectivity re-connect (also done from the scmerlin add-on Internet Connection restart action) or a VPN change (e.g., updating and saving the IPSec VPN Server config) then every service on the router is properly working (Unbound DNS, WireGuard tunnel, IPSec Server, Yazfi Networks) but the internet connectivity is not working anymore for any client connected to the network.
I've checked the 'iptables -vnL FORWARD | grep wg' rules as described in the first page of this thread but I see the same entries before and after triggering the issue.
I've also tried to apply the "sleep" workaround suggested for the firewall-start script but the issue is still here.
My current setup on both routers is:
YazFi v4.4.2
Unbound Manager v3.22
ntpMerlin v3.4.5
scMerlin v2.4.0
WireGuard Mgr v4.18
Any advice on how to better investigate (and hopefully solve) the issue would be more than welcome.
ZebMcKayhan
Very Senior Member
Are you sure this is a Wireguard issue? If you put your peers in auto=N and redo the same thing wont you get the same result?
If not, the only thing coming to mind is that you disable WGM killswitch if that somehow is messing with your wan access. Check with wgm command
vx and disable the killswitch if it is enabled. Long time ago I had issues with the killswitch in combination with YazFi but I thought that was resolved. I dont recommend using wgm killswitch unless on some special cases.https://github.com/ZebMcKayhan/WireguardManager#manage-killswitch
If the killswitch is not it and the router has wan access but not lan clients its not a routing issue. Its probably something in the FORWARD filter chain. Try to list ALL entries and not just wgm ones to see what is blocking access
Last edited:
lluke
Occasional Visitor
@ZebMcKayhan thanks for the response, I was connecting the issue to Wireguard since the first time I've experienced connectivity issues was after its installation, but I guess you're right it's not an issue related to it!
I confirm you the killswitch is disabled and that the router has full wan access (I did some tries with wget directly on the router).
So I moved to analyse the forward chain and the only difference before and after a connection issue (or even manual restart from scmerlin) are the following 2 rules:
pkts bytes target prot opt in out source destination
0 0 YazFiDNSFILTER_DOT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:853
105 190 YazFiFORWARD all -- * * 0.0.0.0/0 0.0.0.0/0
This 2 rules are missing from the 'iptables -vnL FORWARD', so I guess I've to continue this discussion on the YazFi thread, correct?
ZebMcKayhan
Very Senior Member
These rules would only affect clients on YazFi guest network. I did not think it would have any effect on lan clients, but I could be wrong. But the fact that they are missing means that something is not right.
YazFi should give a syslog entry on reconnect that firewall has been restarted and YazFi sleeps for 10s ? After that it should display that it has re-applied all rules.
Even though Im not convinced these rules are the issue but its a place to start. So please post in YazFi thread and see if you could get YazFi to restart properly first.
ludespeedny
Regular Contributor
Is there a list of routers this currently works with? I have seen some say that it works on arm v7 routers, and others saying only the ax models.
ZebMcKayhan
Very Senior Member
Last edited:
ludespeedny
Regular Contributor
Thanks! I just got a ac3100 thinking it would work for this but guess not. I'll keep an eye out for one of those models. I actually have an ac68u how can I tell if it is v4?
ZebMcKayhan
Very Senior Member
numminorih
Occasional Visitor
Hi to everybody,
after a few month of succesful work, i faced with problem:
1. AX86U fw 388.1
2. las dev wireguard
Problem:
...a few weeks ago I installed UPS on the whole house and now the blackouts are completely "invisible", but my ISP equipment loses power (on their side) for 1-2 minutes and reboots, thus temporarily losing connection with my router. After that, my rules for wg tunel stop to work ("unbound"s IP to wg11). Helps only wgmExpo "restart wg11" or full router reboot. (It doesn't matter if the dualWan is on or not), only "sh /jffs/addons/wireguard/Scripts/wg11-up.sh" doesn't work... in the same time peer wg11 in wg_manager shows that all as usual and should work.
nano /jffs/scripts/nat-start
E:Option ==> peer wg11
nano /jffs/addons/wireguard/Scripts/wg11-up.sh
nano /jffs/addons/wireguard/Scripts/wg11-down.sh
Please advise how to proceed...
after a few month of succesful work, i faced with problem:
1. AX86U fw 388.1
2. las dev wireguard
Problem:
...a few weeks ago I installed UPS on the whole house and now the blackouts are completely "invisible", but my ISP equipment loses power (on their side) for 1-2 minutes and reboots, thus temporarily losing connection with my router. After that, my rules for wg tunel stop to work ("unbound"s IP to wg11). Helps only wgmExpo "restart wg11" or full router reboot. (It doesn't matter if the dualWan is on or not), only "sh /jffs/addons/wireguard/Scripts/wg11-up.sh" doesn't work... in the same time peer wg11 in wg_manager shows that all as usual and should work.
nano /jffs/scripts/nat-start
Code:
#!/bin/sh
############################################################
# required for serialization when reentry is possible
LOCK="/tmp/$(basename $0).lock"
acquire_lock() { while ! mkdir $LOCK &>/dev/null; do sleep 2; done; }
release_lock() { rmdir $LOCK &>/dev/null; }
exit_0() { release_lock; exit 0; } # exit (any concurrent instance(s) may now run)
############################################################
acquire_lock # one instance at a time
logger -t $(basename $0) "Started"
##
## Put existing nat-start directives here
##
IPSET_LIST="unblockip" #List of ipsets to restore
DIR="/mnt/sd/entware/home" #directory for store ipset
MAX_TRIES=30 #Retries to find usb every second [MAX_TRIES] amount of times.
## Normally nothing need to be changed below ##
TRIES="0"
while [ "$TRIES" -lt "$MAX_TRIES" ]; do
if [ -d "$DIR" ]; then
for IPSET_NAME in $IPSET_LIST; do
if [ "$(ipset list -n "$IPSET_NAME" 2>/dev/null)" != "$IPSET_NAME" ]; then #if ipset does not already exist
if [ -s "$DIR/$IPSET_NAME" ]; then #if a backup file exists
ipset restore -! <"$DIR/$IPSET_NAME" #restore ipset
cru a "$IPSET_NAME" "0 2 * * * ipset save $IPSET_NAME > $DIR/$IPSET_NAME" >/dev/null 2>&1 # create cron job for autosave
logger -t $(basename $0) "IPSET restored: $IPSET_NAME"
fi
fi
done
break
else
sleep 1
TRIES=$((TRIES + 1))
if [ "$TRIES" -eq "$MAX_TRIES" ]; then
logger -t $(basename $0) "Warning: Failed to detect mounted USB-Drive within $MAX_TRIES seconds! IPSET not restored!"
fi
fi
done
############################################################
logger -t $(basename $0) "Completed [$@]"
exit_0E:Option ==> peer wg11
Code:
Client Auto IP Endpoint DNS MTU Annotate
wg11 P X.X.X.X/24,X:X:X::X/64 X.X.X.X:63665 8.8.8.8,8.8.4.4 Auto # N/A
No RPDB Selective Routing/Passthru rules for 'client' Peer wg11
IPSet Enable Peer FWMark DST/SRC
unblockip Y wg11 0x1000 dst
WireGuard® ACTIVE Peer Status: Clients 1, Servers 1nano /jffs/addons/wireguard/Scripts/wg11-up.sh
Code:
#!/bin/sh
iptables -t nat -I POSTROUTING -s 10.50.1.0/24 -o wg11 -j MASQUERADE -m comment --comment "WireGuard 'client wg21 to wg11'"nano /jffs/addons/wireguard/Scripts/wg11-down.sh
Code:
#!/bin/sh
iptables -t nat -D POSTROUTING -s 10.50.1.0/24 -o wg11 -j MASQUERADE -m comment --comment "WireGuard 'client wg21 to wg11'"Please advise how to proceed...
Last edited:
I noticed you have added iptables rule to passthru wg21 to wg11. Is this broken?
By right once WAN reconnect, firewall-start script will run and wg will restart. I’m not sure if unplug the WAN cable and reconnect can reproduce the issue. If can, probably you can check the syslog what happen. Also, getting the output of
Code:
iptables-save | grep wgI'm struggling to get macOS client to work. Can someone give me a dumb guide how to connect macOS client to the Wireguard? Can it even be done through wg_manager?
edit.
Like always. When you ask help you got it solved. 1. Create a peer 2. Get the peer conf details "8 peer_name config" 3. import to macOS app 4. profit
edit.
Like always. When you ask help you got it solved. 1. Create a peer 2. Get the peer conf details "8 peer_name config" 3. import to macOS app 4. profit
Last edited:
numminorih
Occasional Visitor
as I noticed, only the following lines disappear:
-A POSTROUTING -s 192.168.0.0/24 -o wg11 -m comment --comment "WireGuard \'client\'" -j MASQUERADE
-A POSTROUTING -s 10.50.1.0/24 -o wg11 -m comment --comment "WireGuard \'client wg21 to wg11\'" -j MASQUERADE
Code:
worked---
ASUSWRT-Merlin RT-AX86U 388.1_0 Sat Dec 3 18:16:12 UTC 2022
admin@RT-AX86U-DD98:/tmp/home/root# iptables-save | grep wg
-A POSTROUTING -s 192.168.0.0/24 -o wg11 -m comment --comment "WireGuard \'client\'" -j MASQUERADE
-A POSTROUTING -s 10.50.1.0/24 -o wg11 -m comment --comment "WireGuard \'client wg21 to wg11\'" -j MASQUERADE
-A PREROUTING -i wg11 -m comment --comment "WireGuard \'client\'" -j MARK --set-xmark 0x1/0x7
-A PREROUTING -i wg21 -m comment --comment "WireGuard \'server\'" -j MARK --set-xmark 0x1/0x7
-A FORWARD -o wg11 -m comment --comment "WireGuard \'client\'" -j MARK --set-xmark 0x1/0x7
-A FORWARD -i wg11 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'client\'" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o wg11 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'client\'" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o wg21 -m comment --comment "WireGuard \'server\'" -j MARK --set-xmark 0x1/0x7
-A FORWARD -i wg21 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'server\'" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o wg21 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'server\'" -j TCPMSS --clamp-mss-to-pmtu
-A INPUT -i wg21 -m comment --comment "WireGuard \'server\'" -j ACCEPT
-A FORWARD -i wg+ -m comment --comment "Wireguard ACL" -j WGM_ACL_F
-A FORWARD -i br0 -o wg21 -m comment --comment "LAN to WireGuard \'server clients\'" -j ACCEPT
-A FORWARD -i wg21 -m comment --comment "WireGuard \'server\'" -j ACCEPT
-A OUTPUT -o wg21 -m comment --comment "WireGuard \'server\'" -j ACCEPT
not worked---
ASUSWRT-Merlin RT-AX86U 388.1_0 Sat Dec 3 18:16:12 UTC 2022
admin@RT-AX86U-DD98:/tmp/home/root# iptables-save | grep wg
-A PREROUTING -i wg11 -m comment --comment "WireGuard \'client\'" -j MARK --set-xmark 0x1/0x7
-A PREROUTING -i wg21 -m comment --comment "WireGuard \'server\'" -j MARK --set-xmark 0x1/0x7
-A FORWARD -o wg11 -m comment --comment "WireGuard \'client\'" -j MARK --set-xmark 0x1/0x7
-A FORWARD -i wg11 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'client\'" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o wg11 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'client\'" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o wg21 -m comment --comment "WireGuard \'server\'" -j MARK --set-xmark 0x1/0x7
-A FORWARD -i wg21 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'server\'" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o wg21 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "WireGuard \'server\'" -j TCPMSS --clamp-mss-to-pmtu
-A INPUT -i wg21 -m comment --comment "WireGuard \'server\'" -j ACCEPT
-A FORWARD -i wg+ -m comment --comment "Wireguard ACL" -j WGM_ACL_F
-A FORWARD -i br0 -o wg21 -m comment --comment "LAN to WireGuard \'server clients\'" -j ACCEPT
-A FORWARD -i wg21 -m comment --comment "WireGuard \'server\'" -j ACCEPT
-A OUTPUT -o wg21 -m comment --comment "WireGuard \'server\'" -j ACCEPT
Last edited:
It appears only POSTROUTING rules are missing after WAN reconnect. And the rules get reapplied after manually restart the client. Have you check syslog what are the sequence of event happen during WAN disconnect/reconnect?
numminorih
Occasional Visitor
Please advice how can I check it?
...there was no power outage today, but my rules "POSTROUTING" missing again.
It should be stored in /tmp/syslog.log and /tmp/syslog.log-1. There is a possibility that old logs can be rollover.
numminorih
Occasional Visitor
doesn't work => connect to router via ssh => wgmExpo "restart wg11"
Code:
IP hidden - IPWGSERVERremote / ASUSwanIP
Jan 29 17:01:21 dropbear[1243503]: Child connection from 192.168.0.3:2123
Jan 29 17:01:26 dropbear[1243503]: Password auth succeeded for 'admin' from 192.168.0.3:2123
Jan 29 17:04:33 (wg_manager): 1244233 v4.19b4 Restarting Wireguard® 'client' Peer (wg11)
Jan 29 17:04:34 lldpd[1662]: removal request for address of 10.66.66.2%32, but no knowledge of it
Jan 29 17:04:34 wg_manager-clientwg11: Removing IPSet 'unblockip' routing through VPN 'client' Peer wg11
Jan 29 17:04:34 wg_manager-clientwg11: Executing Event:wg11-down.sh
Jan 29 17:04:34 wg_manager-clientwg11: WireGuard® VPN 'client' Peer (wg11) to IPWGSERVERremote:63665 (# N/A) Terminated
Jan 29 17:04:34 (wg_manager): 1244233 v4.19b4 Initialising Wireguard® VPN 'client' Peer (wg11)
Jan 29 17:04:34 wg_manager-clientwg11: Initialising WireGuard® VPN client Peer (wg11) in Policy Mode to IPWGSERVERremote:63665 (# N/A)
Jan 29 17:04:34 wg_manager-clientwg11: Warning: No Selective Routing rules found
Jan 29 17:04:35 wg_manager-clientwg11: Adding IPv4 IPSet 'unblockip' route through VPN 'client' Peer wg11
Jan 29 17:04:35 wg_manager-clientwg11: Executing Event:wg11-up.sh
Jan 29 17:04:35 wg_manager-clientwg11: Initialisation complete.
test url that should be opened (ublock list) via wg11
Jan 29 17:06:16 kernel: blog_link:overwriting ct_p=ffffffc02d1871a0, new_ct=ffffffc029b19970 idx=0
Jan 29 17:06:16 kernel: NFCT: ct<0xffffffc02d1871a0>, master<0x (null)>
Jan 29 17:06:16 kernel: F_NAT<ffffffc0295b5cf8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
Jan 29 17:06:16 kernel: help<0x (null)> helper<NONE> status=8000018e refcnt=4 zone=0
Jan 29 17:06:16 kernel: tuple ffffffc02d187238: 17 ASUSwanIP:57395 -> IPWGSERVERremote:63665
Jan 29 17:06:16 kernel: tuple ffffffc02d187270: 17 IPWGSERVERremote:63665 -> ASUSwanIP:57395
Jan 29 17:06:16 kernel: STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
Jan 29 17:06:16 kernel: NFCT: ct<0xffffffc029b19970>, master<0x (null)>
Jan 29 17:06:16 kernel: F_NAT<ffffffc0295b51f8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
Jan 29 17:06:16 kernel: help<0x (null)> helper<NONE> status=80000198 refcnt=2 zone=0
Jan 29 17:06:16 kernel: tuple ffffffc029b19a08: 6 192.168.0.3:2158 -> 185.41.185.73:80
Jan 29 17:06:17 kernel: tuple ffffffc029b19a40: 6 185.41.185.73:80 -> 10.66.66.2:2158
Jan 29 17:06:17 kernel: STATUS[ IPS_CONFIRMED_BIT IPS_SRC_NAT_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
Jan 29 17:06:17 kernel: blog_link:overwriting ct_p=ffffffc02d1871a0, new_ct=ffffffc029b19970 idx=0
Jan 29 17:06:17 kernel: NFCT: ct<0xffffffc02d1871a0>, master<0x (null)>
Jan 29 17:06:17 kernel: F_NAT<ffffffc0295b5cf8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
Jan 29 17:06:17 kernel: help<0x (null)> helper<NONE> status=8000018e refcnt=4 zone=0
Jan 29 17:06:17 kernel: tuple ffffffc02d187238: 17 ASUSwanIP:57395 -> IPWGSERVERremote:63665
Jan 29 17:06:17 kernel: tuple ffffffc02d187270: 17 IPWGSERVERremote:63665 -> ASUSwanIP:57395
Jan 29 17:06:17 kernel: STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]
Jan 29 17:06:17 kernel: NFCT: ct<0xffffffc029b19970>, master<0x (null)>
Jan 29 17:06:17 kernel: F_NAT<ffffffc0295b51f8> keys[0x00000000 0x00000000] dir<DIR_ORIG>
Jan 29 17:06:17 kernel: help<0x (null)> helper<NONE> status=8000019e refcnt=3 zone=0
Jan 29 17:06:17 kernel: tuple ffffffc029b19a08: 6 192.168.0.3:2158 -> 185.41.185.73:80
Jan 29 17:06:17 kernel: tuple ffffffc029b19a40: 6 185.41.185.73:80 -> 10.66.66.2:2158
Jan 29 17:06:17 kernel: STATUS[ IPS_SEEN_REPLY_BIT IPS_ASSURED_BIT IPS_CONFIRMED_BIT IPS_SRC_NAT_BIT IPS_SRC_NAT_DONE_BIT IPS_DST_NAT_DONE_BIT IPS_BLOG_BIT ]reconect ISP cable
Code:
IP/mac hidden - localpcIP2.5G / localpcmac2.5G
Jan 29 17:19:29 kernel: NOTE: Using Port Grouping for IMP ports : [ 0 --> 4 ] [ 1, 2 --> 5 ] [ 3, 7 --> 8 ]
Jan 29 17:19:29 kernel: eth5 (Ext switch port: 7) (Logical Port: 15) (phyId: 1e) Link DOWN.
Jan 29 17:19:29 kernel: br0: port 5(eth5) entered disabled state
Jan 29 17:19:32 kernel: NOTE: Using Port Grouping for IMP ports : [ 0 --> 4 ] [ 1, 2, 3 --> 5 ] [ 7 --> 8 ]
Jan 29 17:19:32 kernel: eth5 (Ext switch port: 7) (Logical Port: 15) (phyId: 1e) Link Up at 2500 mbps full duplex
Jan 29 17:19:32 kernel: br0: port 5(eth5) entered listening state
Jan 29 17:19:32 kernel: br0: port 5(eth5) entered listening state
Jan 29 17:19:32 kernel: eth0 (Int switch port: 3) (Logical Port: 3) (phyId: c) Link DOWN.
Jan 29 17:19:34 kernel: br0: port 5(eth5) entered learning state
Jan 29 17:19:36 kernel: br0: topology change detected, propagating
Jan 29 17:19:36 kernel: br0: port 5(eth5) entered forwarding state
Jan 29 17:19:36 dnsmasq-dhcp[3914]: DHCPDISCOVER(br0) localpcIP2.5G localpcmac2.5G
Jan 29 17:19:36 dnsmasq-dhcp[3914]: DHCPOFFER(br0) localpcIP2.5G localpcmac2.5G
Jan 29 17:19:36 dnsmasq-dhcp[3914]: DHCPREQUEST(br0) localpcIP2.5G localpcmac2.5G
Jan 29 17:19:36 dnsmasq-dhcp[3914]: DHCPACK(br0) localpcIP2.5G localpcmac2.5G solar
Jan 29 17:19:37 kernel: eth0 (Int switch port: 3) (Logical Port: 3) (phyId: c) Link Up at 1000 mbps full duplex
Jan 29 17:19:38 kernel: NOTE: Using Port Grouping for IMP ports : [ 0 --> 4 ] [ 1, 2 --> 5 ] [ 3, 7 --> 8 ]
Jan 29 17:19:38 kernel: eth5 (Ext switch port: 7) (Logical Port: 15) (phyId: 1e) Link DOWN.
Jan 29 17:19:38 kernel: br0: port 5(eth5) entered disabled state
Jan 29 17:19:43 kernel: NOTE: Using Port Grouping for IMP ports : [ 0 --> 4 ] [ 1, 2, 3 --> 5 ] [ 7 --> 8 ]
Jan 29 17:19:43 kernel: eth5 (Ext switch port: 7) (Logical Port: 15) (phyId: 1e) Link Up at 2500 mbps full duplex
Jan 29 17:19:43 kernel: br0: port 5(eth5) entered listening state
Jan 29 17:19:43 kernel: br0: port 5(eth5) entered listening state
Jan 29 17:19:43 WAN_Connection: WAN was restored.
Jan 29 17:19:43 custom_script: Running /jffs/scripts/nat-start
Jan 29 17:19:43 nat-start: Started
Jan 29 17:19:43 nat-start: Completed []
Jan 29 17:19:45 kernel: br0: port 5(eth5) entered learning state
Jan 29 17:19:47 kernel: br0: topology change detected, propagating
Jan 29 17:19:47 kernel: br0: port 5(eth5) entered forwarding state
Jan 29 17:19:50 dnsmasq-dhcp[3914]: DHCPDISCOVER(br0) localpcIP2.5G localpcmac2.5G
Jan 29 17:19:50 dnsmasq-dhcp[3914]: DHCPOFFER(br0) localpcIP2.5G localpcmac2.5G
Jan 29 17:19:50 dnsmasq-dhcp[3914]: DHCPREQUEST(br0) localpcIP2.5G localpcmac2.5G
Jan 29 17:19:50 dnsmasq-dhcp[3914]: DHCPACK(br0) localpcIP2.5G localpcmac2.5G solartest url that should be opened (ublock list) via wg11 => doesn't work
iptables-save | grep wg => POSTROUTING rules are missing
Code:
#!/bin/sh
############################################################
# required for serialization when reentry is possible
LOCK="/tmp/$(basename $0).lock"
acquire_lock() { while ! mkdir $LOCK &>/dev/null; do sleep 2; done; }
release_lock() { rmdir $LOCK &>/dev/null; }
exit_0() { release_lock; exit 0; } # exit (any concurrent instance(s) may now run)
############################################################
acquire_lock # one instance at a time
logger -t $(basename $0) "Started"
##
## Put existing nat-start directives here
##
IPSET_LIST="unblockip" #List of ipsets to restore
DIR="/mnt/sd/entware/home" #directory for store ipset
MAX_TRIES=30 #Retries to find usb every second [MAX_TRIES] amount of times.
## Normally nothing need to be changed below ##
TRIES="0"
while [ "$TRIES" -lt "$MAX_TRIES" ]; do
if [ -d "$DIR" ]; then
for IPSET_NAME in $IPSET_LIST; do
if [ "$(ipset list -n "$IPSET_NAME" 2>/dev/null)" != "$IPSET_NAME" ]; then #if ipset does not already exist
if [ -s "$DIR/$IPSET_NAME" ]; then #if a backup file exists
ipset restore -! <"$DIR/$IPSET_NAME" #restore ipset
cru a "$IPSET_NAME" "0 2 * * * ipset save $IPSET_NAME > $DIR/$IPSET_NAME" >/dev/null 2>&1 # create cron job for autosave
logger -t $(basename $0) "IPSET restored: $IPSET_NAME"
fi
fi
done
break
else
sleep 1
TRIES=$((TRIES + 1))
if [ "$TRIES" -eq "$MAX_TRIES" ]; then
logger -t $(basename $0) "Warning: Failed to detect mounted USB-Drive within $MAX_TRIES seconds! IPSET not restored!"
fi
fi
done
############################################################
logger -t $(basename $0) "Completed [$@]"
exit_0So, when you restart wg11 again, does the rules get reapply?
The output from wgmExpo "restart wg11" looks normal. Is there any firewall-start and wg_firewall in syslog when WAN was restored? I don't know how to read the kernel output though. You also mention dual WAN in previous post, I don't have this in my setup.
What I can think of is try to get the time the rules are removed. From there, we can match the time in syslog and see what event happened around that time. Hopefully that can help zoom in to find out what causes this behavior. Start a separate ssh session and run this, the output will refresh every second with timestamp.
Code:
watch -n 1 'date; iptables-save | grep wg'numminorih
Occasional Visitor
Yes
I dosn't use it
It's turned off for test
No, I don't see any "POSTROUTING "
...wg11 not fully recovering after WAN reconnect as I understand...
Can you check again if you have this file
/jffs/scripts/firewall-start?It should have this in firewall-start:
Code:
/jffs/addons/wireguard/wg_firewall # WireGuardI understand that it does not recover after WAN reconnect. The command is to start when everything is working before WAN disconnect. So we can keep monitoring the output every second. Then we reproduce the issue again. The idea is to find out at what time the rules get removed. It is a bit tedious. It could be helpful to get the time and cross check with syslog and find out what event happen during that time.
Similar threads
Similar threads
Similar threads
-
New Addon - ChatAI - have a chat session with Googles Gemini AI Bot- Started by JGrana
- Replies: 2
-
Solved How do I remove WG Manager from amtm without resetting amtm?
- Started by DJones
- Replies: 2