What's new

Wireguard Session Manager (4th) thread

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

So for ordinary policy routing based on source or destination ip it for sure seems do-able. Altough not sure how to handle when routing is based on ipset which could be thousands of destination ips or ips and port combinations.
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.
 
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.
 
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.
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:
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

@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?
 
This 2 rules are missing from the 'iptables -vnL FORWARD', so I guess I've to continue this discussion on the YazFi thread, correct?
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.
 
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.
 
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.
It works on hnd- routers

RT-AC86U
RT-AC2900 (same firmware as RT-AC86U)
GT-AC2900
RT-AX88U
GT-AX11000
RT-AX56U
RT-AX58U V1
RT-AX3000 V1 (same firmware as RT-AX58U)
RT-AX86U
RT-AX86S (same firmware as RT-AX86U)
RT-AX68U
RT-AC68U V4 (same firmware as RT-AC68U)
GT-AXE11000
GT-AX6000
ZenWiFi Pro XT12
GT-AX11000_PRO
GT-AXE16000
RT-AX86U_PRO

Not sure about the @GNUton hnd models.
 
Last edited:
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?
 
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

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_0

E: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 1

nano /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:
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

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_0

E: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 1

nano /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...
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 wg
before and after may help to see if any rules are missing after the event.
 
I'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
 
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 wg
before and after may help to see if any rules are missing after the event.

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:
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
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?
 
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?
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.

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 solar

test 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_0
 
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 solar

test 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_0
So, 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'
While it is running, you can try some test scenario like unplug WAN, wait a while and then reconnect. I think the rules will get wiped off when WAN is restored, then when wg restarted by itself, the rules will get applied. Then something happened that these rules get removed again.
 
So, when you restart wg11 again, does the rules get reapply?
Yes

Is there any firewall-start and wg_firewall in syslog when WAN was restored?
I dosn't use it

You also mention dual WAN in previous post, I don't have this in my setup.
It's turned off for test

While it is running, you can try some test scenario like unplug WAN, wait a while and then reconnect. I think the rules will get wiped off when WAN is restored, then when wg restarted by itself, the rules will get applied.
No, I don't see any "POSTROUTING "

...wg11 not fully recovering after WAN reconnect as I understand...
 
Yes


I dosn't use it


It's turned off for test


No, I doesn'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            # WireGuard

I 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.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top