Wireguard Session Manager (4th) thread

[ZebMcKayhan]

reconect ISP cable

Looks like your WAN event triggers a nat-start and not a firewall-start.

Originally Wgm peers was restarted in nat-start but this created conflicts with YazFi. So the author decided to move this to firewall-start.

Merlin firmware documentation says that firewall rules should be in nat-start except for filter table which should be in firewall-start. WGM populates rules in mangle, nat and filter tables so ideally it would be in both.

Normally firewall-start comes last so it works. Appearently there are some events that only generates nat-start and no firewall-start.

Try adding this to nat-start, after your ipsets have been restored (right after the final done):

/jffs/addons/wireguard/wg_firewall            # WireGuard

Edit: as a side-effect of this Wireguard peers would be restarted twice during a normal event, like boot. First when nat-start is executed then restarted when firewall-start is executed. However this is no real problem as Wireguard is connection less so the server may not even be aware. You will mostly notice it in the logs.

 

[numminorih]

Can you check again if you have this file /jffs/scripts/firewall-start?

Yes,

nano /jffs/scripts/firewall-start

#!/bin/sh


/jffs/addons/wireguard/wg_firewall            # WireGuard

I will test it more with watch -n 1 'date; iptables-save | grep wg' and post after find a trigger....

THX

 

[numminorih]

Looks like your WAN event triggers a nat-start and not a firewall-start.

Originally Wgm peers was restarted in nat-start but this created conflicts with YazFi. So the author decided to move this to firewall-start.

Merlin firmware documentation says that firewall rules should be in nat-start except for filter table which should be in firewall-start. WGM populates rules in mangle, nat and filter tables so ideally it would be in both.

Normally firewall-start comes last so it works. Appearently there are some events that only generates nat-start and no firewall-start.

Try adding this to nat-start, after your ipsets have been restored (right after the final done):

/jffs/addons/wireguard/wg_firewall            # WireGuard

Edit: as a side-effect of this Wireguard peers would be restarted twice during a normal event, like boot. First when nat-start is executed then restarted when firewall-start is executed. However this is no real problem as Wireguard is connection less so the server may not even be aware. You will mostly notice it in the logs.

THX i Will try this.

 

[numminorih]

Yes,

nano /jffs/scripts/firewall-start

#!/bin/sh


/jffs/addons/wireguard/wg_firewall            # WireGuard

I will test it more with watch -n 1 'date; iptables-save | grep wg' and post after find a trigger....

THX

Strange, but just trying to catch the problem with watch -n 1 'date; iptables-save | grep wg' everything works without problems, and disconnecting the cable for 5 minutes, and a quick (1 second) reconnection... All is start and work w/o any problem...

 

[ZebMcKayhan]

Strange, but just trying to catch the problem with watch -n 1 'date; iptables-save | grep wg' everything works without problems, and disconnecting the cable for 5 minutes, and a quick (1 second) reconnection... All is start and work w/o any problem...

So did you get anywhere with this? I mean its unlikely the problem got resolved by itself (its extremly rare).

Did you add the entry in nat-start?

What is your long term solution? Running "watch" every second continously, forever (joke (I hope))?

 

[numminorih]

So did you get anywhere with this? I mean its unlikely the problem got resolved by itself (its extremly rare).

not at all

Did you add the entry in nat-start?

yes

What is your long term solution? Running "watch" every second continously, forever (joke (I hope))?

over the past two days i noticed that i stopped sending wg11, but yesterday, i rebooted the router, via http interface, and it started for more than 10 minutes, even on lan...., which was very strange, and after that a couple of hours later when i checked the availability of wg11 - it did not work, but after rebooting "vg restart" via http addon, - everything was restored, and again it works stably, at least for now

 

[ZebMcKayhan]

not at all


yes



over the past two days i noticed that i stopped sending wg11, but yesterday, i rebooted the router, via http interface, and it started for more than 10 minutes, even on lan...., which was very strange, and after that a couple of hours later when i checked the availability of wg11 - it did not work, but after rebooting "vg restart" via http addon, - everything was restored, and again it works stably, at least for now

Could you see in the logs the nat-start execution and restart of wireguard peers?

Still the same firewall rules missing?

 

[ZebMcKayhan]

@numminorih

I was thinking if we cant solve your issue using nat-start and firewall-start perhaps a reactive solution would ease your issue, well atleast you dont have to go into router to restart the peers.

Ive created a script that checks nat postrouting table for WireGuard rules and if they are missing it will restart your peers:

Create a script file:

nano /jffs/scripts/wgm_monitor.sh

and populate the file with:

#!/bin/sh
if [ -z "$(iptables -L POSTROUTING -t nat | grep WireGuard)" ] ; then  #if nat postrouting table contains no WireGuard entries
    logger -t $(basename $0) "NAT rules missing!! restarting Wireguard peers."
    wg_manager restart #Restart Wgm peers
fi

Save and exit.

convert endings to unix style (just in case) and make the file executable:

dos2unix /jffs/scripts/wgm_monitor.sh
chmod +x /jffs/scripts/wgm_monitor.sh

you could test the script by manually stopping wgm peers then execute the script, the peers should be restarted (I think wgm should restart even stopped peers if they are auto=Y/P)

If the script is working, we can let a cron job execute it every 5 min, ie:

nano /jffs/addons/wireguard/Scripts/wg11-up.sh

and add the cron job:

cru a "wgm_monitor" "*/5 * * * * /jffs/scripts/wgm_monitor.sh" # create cron job

save and exit.

and remove when stopped:

nano /jffs/addons/wireguard/Scripts/wg11-down.sh

and add

cru d "wgm_monitor"

you may need to restart wg11 to have the cron job added. There may be an error when stopping wg11 the first time as there is no cron job to delete, but it should only be the first time.

If working as intended it should take a maximum of 5min before your issue gets corrected by the router itself. Maybe you could find this acceptable.

 

[johndoe85]

Must i go through WireGuard manager in amtm in order to setup killswitch for my vpn clients?

 

[ZebMcKayhan]

Must i go through WireGuard manager in amtm in order to setup killswitch for my vpn clients?

What do you mean? As oppose to running wireguard in firmware? Or are you experiencing problems with wgm?

 

[johndoe85]

What do you mean? As oppose to running wireguard in firmware? Or are you experiencing problems with wgm?

1.
Yes running wireguard in the firmware/GUI method. I don't see any kill switch function in the GUI.

2.
And when i had setup Wigreguard client and server in the GUI i had some problems. Can't remember exactly what now except it is bogus somehow.
For the wireguard client in the stock firmware i get disconnect from WAN all the time, and it kicks me out from WiFI.

3.
In asuswrt merlin i have problems when setting up the wireguard server, and here is what i don't remember what the issue was since this was some weeks ago.
But i installed wgm in amtm and it created several instances of wireguard client server, like a copy of each. Saying one is from the gui and the other it did not explicit say what it was from (i think) but it was no doubt what is what created from.

I could not delete and redo the GUI created server/client in the wgm so i just factory reseted it.
Now im afraid of using wireguard server and client both so i have openvpn server setup instead.
And i don't want to install wgm either since it created several instances for it. In my mind there should only have been the GUI presented there. They had diffrent names too, like wgs for server (GUI one)? instead of wg11 or wg21. And wgc for client (GUI one) instead of wg11 or wg21. I can't remeber which number was for client and server (wg11/wg21).

So now i just want a killswitch for the GUI side. I figured the issues will go away as the code and implementations matures over time.

I hope this makes any sense.

 

[ZebMcKayhan]

1.
Yes running wireguard in the firmware/GUI method. I don't see any kill switch function in the GUI.

No, there are none. It is typically not needed. It is also complicated to do since Wireguard is connection-less. There is no autentication or anything to build it on.

For the wireguard client in the stock firmware i get disconnect from WAN all the time, and it kicks me out from WiFI.

Sounds like a firmware issue, perhaps a fresh start would help. Wireguard has nothing to do with the wifi.

But i installed wgm in amtm and it created several instances of wireguard client server, like a copy of each. Saying one is from the gui and the other it did not explicit say what it was from (i think) but it was no doubt what is what created from.

I was not aware that wgm imported firmware peers. Are you sure it was not showing them? Wgm clients are wg11, wg12 aso. Wgm servers are wg21, wg22. Firmware clients are wgc1, wgc2 aso. Firmware server are wgs1, wgs2.

I dont know but I think wgm just showed you the firmware peers. You dont need to enable them.

If it has not changed lately wgm killswitch is a firewall rule that prevents ALL access between lan and wan so it would only make sense to use with Auto=Y and not very appropriate for Policy routing.

As it is a firewall rule it is applied when wgm starts, before that packets could slip through. It could also be overridden by other firewall rules. But it is actually put into place before wgm starts and directly from jffs so it will be applied even if say your usb drive dies.

As Wireguard is connection-less there are no dependencies that could make it fail to start (in wgm's case a broken usb drive could perhaps, but not the firmware). Both firmware and wgm are completally oblivious to wheter the peer works or not, it just kicks it off. If it does not work clients will have a broken connection.

How would you imagine a kill-switch would work? What would it do and when?

 

[johndoe85]

No, there are none. It is typically not needed. It is also complicated to do since Wireguard is connection-less. There is no autentication or anything to build it on.


Sounds like a firmware issue, perhaps a fresh start would help. Wireguard has nothing to do with the wifi.


I was not aware that wgm imported firmware peers. Are you sure it was not showing them? Wgm clients are wg11, wg12 aso. Wgm servers are wg21, wg22. Firmware clients are wgc1, wgc2 aso. Firmware server are wgs1, wgs2.

I dont know but I think wgm just showed you the firmware peers. You dont need to enable them.

If it has not changed lately wgm killswitch is a firewall rule that prevents ALL access between lan and wan so it would only make sense to use with Auto=Y and not very appropriate for Policy routing.

As it is a firewall rule it is applied when wgm starts, before that packets could slip through. It could also be overridden by other firewall rules. But it is actually put into place before wgm starts and directly from jffs so it will be applied even if say your usb drive dies.

As Wireguard is connection-less there are no dependencies that could make it fail to start (in wgm's case a broken usb drive could perhaps, but not the firmware). Both firmware and wgm are completally oblivious to wheter the peer works or not, it just kicks it off. If it does not work clients will have a broken connection.

How would you imagine a kill-switch would work? What would it do and when?

Aha okey. Yeah i guess is a firmware issue because i did not have this problem in the earlier version when wireguard was implemented, but not yet in the GUI side from ASUS.
And i don't know why but when setting up wireguard server and wireguard client, when the wireguard client is connecting the WAN cannot connect, it gets into some kind of loop. If i disconnect the WAN cable it gets more stable, but still problematic. Like i still have to hurry but have enough time to disconnect the VPN.
I have no idea what is going on. This is on stock firmware. But its not problem free on asuswrt Merlin either.

For the kill switch i wanted it to block internetaccess for my LAN devices that is forced to go through the VPN. So i can surf safely. But not for the rest of the devices.

 

[ZebMcKayhan]

For the kill switch i wanted it to block internetaccess for my LAN devices that is forced to go through the VPN. So i can surf safely. But not for the rest of the devices.

Why don't you feel that you can surf safely? What are you afraid will happen? Wireguard will not disconnect, it will break. It will not fail to start as there are no external dependencies.

But ok, if you really feel you need it. Whatever we do it should not be associated with Wireguard at all, thus if wireguard is stopped for ANY reason it should not be removed. This will permanently break your connection to selected clients, even if you manually stop wg clients. Any attempt to remove the rules when the client stops would again risk that the rules are removed when you dont want it.

The most straigtforward way would be to add firewall rules to prevent access in firewall-start scripts. To minimize packets slipping out after firewall is started the rules should be first in firewall-start.

As always there is a chance that other scripts may override the rules by adding rules with higher priority.

The rule(s) could look like:

iptables -I FORWARD -s 192.168.x.y -o $(ip route | awk '/^default/{print $NF}') -j REJECT

You need to duplicate the rule and change the ip for each VPNDirector rule (each computers ip you have set to use vpn).

The rule will block access to wan from the ip you use in the rule.

But I must emphasize that I think its a mistake to add the rules. You are trying to solve an issue that does not exist and the penalty would be added complexity and more difficult to maintain. In years from now when you decide to skip vpn you will be frustated why everything has internet except your computer and create a long posting here about why the router wont give internet to this particular device.

I have used Wireguard via wgm for years now and it has not failed even a second. Whenever there have been issues with my vpn the connection have broken, never reverted to wan.

Anyhow, your choice.

 

[johndoe85]

Why don't you feel that you can surf safely? What are you afraid will happen? Wireguard will not disconnect, it will break. It will not fail to start as there are no external dependencies.

But ok, if you really feel you need it. Whatever we do it should not be associated with Wireguard at all, thus if wireguard is stopped for ANY reason it should not be removed. This will permanently break your connection to selected clients, even if you manually stop wg clients. Any attempt to remove the rules when the client stops would again risk that the rules are removed when you dont want it.

The most straigtforward way would be to add firewall rules to prevent access in firewall-start scripts. To minimize packets slipping out after firewall is started the rules should be first in firewall-start.

As always there is a chance that other scripts may override the rules by adding rules with higher priority.

The rule(s) could look like:

iptables -I FORWARD -s 192.168.x.y -o $(ip route | awk '/^default/{print $NF}') -j REJECT

You need to duplicate the rule and change the ip for each VPNDirector rule (each computers ip you have set to use vpn).

The rule will block access to wan from the ip you use in the rule.

But I must emphasize that I think its a mistake to add the rules. You are trying to solve an issue that does not exist and the penalty would be added complexity and more difficult to maintain. In years from now when you decide to skip vpn you will be frustated why everything has internet except your computer and create a long posting here about why the router wont give internet to this particular device.

I have used Wireguard via wgm for years now and it has not failed even a second. Whenever there have been issues with my vpn the connection have broken, never reverted to wan.

Anyhow, your choice.

Mm ok.
Well the reason is i was avoiding a ban on a forum by loggin in to a second account. After some time they discoverd this, im guessing when my damn VPN went down, and they banned me again. This time with the reason multiply accounts

Now im on my 3rd account and im scared it will happend again.
It's no biggie, its just one of swedens largest discuss forum and it can get heated in there from time to time, making the mods go ape on every emotional creature on the internet.

 

[archiel]

Thanks!

I could see Wireguard.c writes to

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.

But its not really something quick and easy to add on to wgm, probably needs to be integrated into wgm but dont know if @Martineau are motivated to update wgm with this?

Hi @ZebMcKayhan and @Martineau. Further to the above and @RMerlin 's reply in the subsequent post, 388.2_alpha is now available for RT-AX88U and I have installed it onto my router. If you would like to explore whether the (firmware Wireguard) solution can be adapted to work with WireGuard Manager, I am happy to test any solutions that you may suggest.

As previously discussed I am sticking with WGM as the inbuilt Wireguard solution does not support IPv6.

If you do not wish to pursue this, it is not a major issue. Currently my ISP only offers 80/20 and I use Cake so having / not having FlowCache enabled makes no practical speed difference to my connection. I am hoping that substantially faster link options will become available later in the year, at which time if WGM does not support selective application of Flow Cache, I will look at running Wireguard elsewhere, either in a VM or a DIY device (I have some spare components which I could utilise either as a ubuntu device or similar to offload Wireguard plus possibly, Unbound and an IDS solution). Thanks Archiel.

 

[ZebMcKayhan]

388.2_alpha is now available for RT-AX88U and I have installed it onto my router.

Could you check the content of these files after you made some dummy wg client in the gui and some dummy rule in vpndirector to use the dummy wg client?

/proc/blog/skip_wireguard_port
/proc/blog/skip_wireguard_network

Are there other skip_wireguard_xxyyzx file here?

Then maybe its just as easy as adding source ips in the file?

Dont know if @Martineau has interest/time/motivation to continue develop wgm, but even if not it should be possible with using up/down scripts.

But as @RMerlin stated it basically only works for source based rules. Ever changing ipsets or destination based rules will not work. Or perhaps you could test make some dummy destination rule and se what happens in the files...

 

[archiel]

Could you check the content of these files after you made some dummy wg client in the gui and some dummy rule in vpndirector to use the dummy wg client?

/proc/blog/skip_wireguard_port
/proc/blog/skip_wireguard_network

Are there other skip_wireguard_xxyyzx file here?

Then maybe its just as easy as adding source ips in the file?

Dont know if @Martineau has interest/time/motivation to continue develop wgm, but even if not it should be possible with using up/down scripts.

But as @RMerlin stated it basically only works for source based rules. Ever changing ipsets or destination based rules will not work. Or perhaps you could test make some dummy destination rule and se what happens in the files...

Walking this back a bit

• As I am already running WGM, do I need to disable (or even uninstall) before creating the dummy firmware/vpn director version?
• Server, connection to external VPN provider or both?
• The aim is to support IPv6, currently done via ipset as the (public) IPv6 address will be changing over time. The MAC can be static, and the link-local IPV6 (fe80:...) will also be static unless & until the routed device or the router are restarted, or is this dead in the water from the start?

Added

* I could test purely for IPv4 as this may assist others who want to keep using WGM for other (non-IPv6) reasons. I will need to setup an IPv4 only VM for testing.

 

[ZebMcKayhan]

As I am already running WGM, do I need to disable (or even uninstall) before creating the dummy firmware/vpn director version?

Nope, you could just add it on top.

Server, connection to external VPN provider or both?

Just a client... i dont think it even has to work. And your rule could be some ip you dont use.

The aim is to support IPv6, currently done via ipset as the (public) IPv6 address will be changing over time. The MAC can be static, and the link-local IPV6 (fe80:...) will also be static unless & until the routed device or the router are restarted, or is this dead in the water from the start?

I know and it may be possible to scan the ipset, extract the ips and add them to the file since they dont change very often. But it would take some work

 

[ZebMcKayhan]

* I could test purely for IPv4 as this may assist others who want to keep using WGM for other (non-IPv6) reasons. I will need to setup an IPv4 only VM for testing.

Merlin have not implemented vpn for ipv6 and it may be possible that bypass for ipv6 also not implemented. Or perhaps its just to add ipv6 ips in the file as well but we wont know that untill someone tests.