Is wireguard available on RT-AC86U ?

[Jherb]

Is there a way to check for a specific rule that was set by your script from the command line? This way, I can try to narrow down where things are being overwritten, etc.

 

[ZebMcKayhan]

Something still bothers me. Even if the firewall did restart, which almost always calls nat-start as well, the nat-start script would have restarted the wg script.

Just fyi, when YazFi restarts it waits 12sec as previously stated then it restarts firewall without nat-start event. So only the filter chain gets wiped but thats enough to bork a server peer.

This made the author of wg_manager to move from restarting peers in nat-start to firewall-start instead.

But there have been reported events (altough only 1) where nat-start events happens on reboot of isp equipment (like a power outage) which did not generate a firewall-start.

According to Merlin, all custom firewall rules should go in nat-start except for filter rules which should go in firewall-start. You are populating rules in both so peers should ideally be reset on both events.

And if, then it could be a good idea to build in a lock-file detection so you dont end up executing your restart script multiple times simultaneously.

 

[ZebMcKayhan]

Is there a way to check for a specific rule that was set by your script from the command line? This way, I can try to narrow down where things are being overwritten, etc.

You can list all rules in a particular chain and table by:

iptables -nvL CHAIN -t table

i.e:

iptables -nvL POSTROUTING -t nat
iptables -nvL FORWARD -t filter

But you will need to find which rule you are interested in. You could further filter the result using i.e grep, like:

iptables -nvL POSTROUTING -t nat | grep wg

This would only output the lines containing wg.

You could also output info to your syslog from your script:

logger -t $(basename $0) "Wireguard Peer restarted!"

Then you could track in syslog what is happening after. Handy sometimes.

 

[Jherb]

Just fyi, when YazFi restarts it waits 12sec as previously stated then it restarts firewall without nat-start event. So only the filter chain gets wiped but thats enough to bork a server peer.

This made the author of wg_manager to move from restarting peers in nat-start to firewall-start instead.

But there have been reported events (altough only 1) where nat-start events happens on reboot of isp equipment (like a power outage) which did not generate a firewall-start.

According to Merlin, all custom firewall rules should go in nat-start except for filter rules which should go in firewall-start. You are populating rules in both so peers should ideally be reset on both events.

And if, then it could be a good idea to build in a lock-file detection so you dont end up executing your restart script multiple times simultaneously.

Thanks. How do you do a lock check in the script?

 

[ZebMcKayhan]

Thanks. How do you do a lock check in the script?

The following script was created by @eibgrad and works good:

#!/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 (any concurrent instance(s) may now run) 
exit_0() { release_lock; exit 0; } 

# one instance at a time 
acquire_lock 
logger -t $(basename $0) "Started [$@]" 

## existing scripts ## 

logger -t $(basename $0) "Completed [$@]" 
exit_0

you will need to wrap this around your existing script and it will make sure multple executions are executed consecutively.

 

[Jeffrey Young]

You can list all rules in a particular chain and table by:

iptables -nvL CHAIN -t table

i.e:

iptables -nvL POSTROUTING -t nat
iptables -nvL FORWARD -t filter

But you will need to find which rule you are interested in. You could further filter the result using i.e grep, like:

iptables -nvL POSTROUTING -t nat | grep wg

This would only output the lines containing wg.

You could also output info to your syslog from your script:

logger -t $(basename $0) "Wireguard Peer restarted!"

Then you could track in syslog what is happening after. Handy sometimes.

Thanks @ZebMcKayhan for answering. Got busy with another job there today. I saw the post, but could not step away.

 

[Jeffrey Young]

Just fyi, when YazFi restarts it waits 12sec as previously stated then it restarts firewall without nat-start event. So only the filter chain gets wiped but thats enough to bork a server peer.

This made the author of wg_manager to move from restarting peers in nat-start to firewall-start instead.

But there have been reported events (altough only 1) where nat-start events happens on reboot of isp equipment (like a power outage) which did not generate a firewall-start.

According to Merlin, all custom firewall rules should go in nat-start except for filter rules which should go in firewall-start. You are populating rules in both so peers should ideally be reset on both events.

And if, then it could be a good idea to build in a lock-file detection so you dont end up executing your restart script multiple times simultaneously.

It is good that you bring this up. I have often thought about how best to run this as iptable rules for both the nat table and the filter table are being used here. Back in 2019, the original concept used only the nat-start at the time. At the time, I did a quick look at the syslogs and noted that nat-start seemed to get called right after firewall start, so nat-start seemed to be a good spot to do everything Did not think much of it at the time and this script (actually, it is a derivative of the original script) has worked flawlessly now for for going on three years. Then again, my set up is only one setup (my WAN uses a static IP setup).

 

[Jeffrey Young]

The following script was created by @eibgrad and works good:

#!/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 (any concurrent instance(s) may now run)
exit_0() { release_lock; exit 0; }

# one instance at a time
acquire_lock
logger -t $(basename $0) "Started [$@]"

## existing scripts ##

logger -t $(basename $0) "Completed [$@]"
exit_0

you will need to wrap this around your existing script and it will make sure multple executions are executed consecutively.

@Jherb If I get a chance this week, I will play around with this. I have my own locking scheme, but the above looks good as well.

 

[Jherb]

cool. thanks

 

[Jeffrey Young]

@Jherb

Here is the new script with the lock file code. You will need to put the same code that you put into /jffs/scripts/nat-start into /jffs/scripts/firewall-start

This is by far not an elegant way to handle this as most cases both firewall-start and nat-tart scripts get called one right after the other (most cases that I can see in the syslog). I know there there is a back end reason why there has to be a separate nat-start from the fire-wall start, but I don't know why.

In the meantime, this script will check to see if a duplicate call has already been made, and if so, wait 5 seconds and try again. If after 60 seconds the lock file has not been cleared, the script will kill the first instance and carry on. When I get some more time, I want to look into a better way doing this. For now, it should work - it just means the script will get called twice in a lot of situations.

I took out the logging stuff. If you want to keep the logging turned on, you can insert logger statements in the script, or call the script from wan-event, nat-start, and firewall-start as /jffs/addons/wireguard/start_wg1.sh 2>&1 | tee /tmp/wiregaurd-server-start-log.txt

Spoiler: Wireguard Server Script

#!/bin/sh

set -x # enable debugging. Comment out when debugging is not needed

date

KERNEL=$(uname -r)
WGaddress=10.100.10.1/24
WGport=51006

# Check for lock file. If exists, loop for 60 seconds, then delete stuck process and continue
while [ -f "/tmp/$(basename $0).lock" ]; do
ageoflock=$(($(date +%s) - $(date +%s -r /tmp/$(basename $0).lock)))
if [ "$ageoflock" -gt 60 ]; then
# "Stale lock file found (>60 seconds old) - kill stuck process and purge lock"
kill "$(sed -n '1p' /tmp/$(basename $0).lock)" >/dev/null 2>&1
rm -f "/tmp/$(basename $0).lock" 2>/dev/null
# we will sleep for a couple of seconds to give the old process time to kill and cleanup
sleep 4
else
# "Lock file found (age: $ageoflock seconds) - pause for 5 seconds and recheck"
sleep 5
fi
done

# create lock file
echo "$$" > "/tmp/$(basename $0).lock"

modprobe xt_set
modprobe wireguard

ip link del dev wg1 2>/dev/null
ip link add dev wg1 type wireguard
wg setconf wg1 /jffs/addons/wireguard/wg1.conf
ip address add dev wg1 $WGaddress
ip link set up dev wg1
#ifconfig wg1 mtu 1380 # origional set by setup script
ifconfig wg1 mtu 1380
ifconfig wg1 txqueuelen 1000

iptables -t mangle -D PREROUTING -i wg1 -j MARK --set-xmark 0x01/0x7 2>/dev/null
iptables -t mangle -D FORWARD -o wg1 -j MARK --set-xmark 0x01/0x7 2>/dev/null
iptables -t mangle -D FORWARD -i wg1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 2>/dev/null
iptables -t mangle -D FORWARD -o wg1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 2>/dev/null

iptables -D INPUT -p udp --dport $WGport -j ACCEPT 2>/dev/null
iptables -D INPUT -i wg1 -j ACCEPT 2>/dev/null
iptables -D FORWARD -i wg1 -j ACCEPT 2>/dev/null
iptables -D FORWARD -o wg1 -j ACCEPT 2>/dev/null
iptables -D OUTPUT -o wg1 -j ACCEPT 2>/dev/null
iptables -t nat -D PREROUTING -p udp --dport $WGport -j ACCEPT 2>/dev/null

iptables -t mangle -I FORWARD -o wg1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -I FORWARD -i wg1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -I FORWARD -o wg1 -j MARK --set-xmark 0x01/0x7
iptables -t mangle -I PREROUTING -i wg1 -j MARK --set-xmark 0x01/0x7

iptables -I INPUT -p udp --dport $WGport -j ACCEPT
iptables -I INPUT -i wg1 -j ACCEPT
iptables -I FORWARD -i wg1 -j ACCEPT
iptables -I FORWARD -o wg1 -j ACCEPT
iptables -I OUTPUT -o wg1 -j ACCEPT
iptables -t nat -I PREROUTING -p udp --dport $WGport -j ACCEPT

# Cleanup lock file
rm -f "/tmp/$(basename $0).lock" 2>/dev/null

 

[Jherb]

Great, thank you. I will give it a try.
Thanks again for the great help.

 

[ZebMcKayhan]

This is by far not an elegant way to handle this

You wouldnt need to tear down the peers and back up. If you sectionize the script you could call it from nat-start with an argument i.e start_wg1.sh nat and the script only re-applies nat and mangle rules.

Similar with arg start_wg1.sh firewall would only reapply filter rules.

Perhaps would be neater?

Continuing adding arguments like start and stop and ofcource checking if peer is up before reapplying any rules.

Before you know it you will have a full-fledged script ready for the addon-section ;-)!

 

[Jeffrey Young]

You wouldnt need to tear down the peers and back up. If you sectionize the script you could call it from nat-start with an argument i.e start_wg1.sh nat and the script only re-applies nat and mangle rules.

Similar with arg start_wg1.sh firewall would only reapply filter rules.

Perhaps would be neater?

Continuing adding arguments like start and stop and ofcource checking if peer is up before reapplying any rules.

Before you know it you will have a full-fledged script ready for the addon-section ;-)!

Well, you know what they say.... "great minds think alike"

I came up with the same idea while walking the dog.

Should not take long to do. It will bug me just enough that I will likely put off my wordpress project one more day.

Stay tuned

 

[Jeffrey Young]

You wouldnt need to tear down the peers and back up.

Are you sure? A while ago when I was setting up a custom VLAN on my AC86U, I discovered that whenever the firewall was restarted all the my custom VLAN interfaces were nuked. I had to add my VLAN script into the firewall-start script to rebuild the VLAN interfaces.

 

[ZebMcKayhan]

Are you sure?

Not in the sense as I have actually tested it. But Wireguard is a virtual interface setup by the kernel modules. I hardly think the firmware would remove it.

Only one way to find out....

 

[Jherb]

Hi
I had a followup question when setting up a client. What goes in the DNS field?
Right now I have the public DNS as below, but is it supposed to be something I get from the router?
Thank you

Address = 10.100.10.2/24
DNS = 1.1.1.1

 

[Jeffrey Young]

I usually set it to a DNS server of the host network so that local intranet machines on the server can be resolved. So, in my case, my router is 192.168.189.2 and it is the DNS server for my local services. By pointing DNS server there, I can resolve my machines inside my private network. If you don't need internal resolution, you don't need to worry about setting it.

I am nearly done rewriting my script so that it acts much like the traditional wg-quick tool. Hope to publish shortly.

 

[Jherb]

That’s awesome about the script. Can’t wait to try it.

regarding the dns server, I’m using a windows client and tried setting dns to the router address. I couldn’t access anything on the internet. I’m not sure why.

 

[Jeffrey Young]

That’s awesome about the script. Can’t wait to try it.

regarding the dns server, I’m using a windows client and tried setting dns to the router address. I couldn’t access anything on the internet. I’m not sure why.

What are you using for allowed IPs?

 

[Jherb]

I had 0.0.0.0/0.
is that correct?