What's new

Wireguard Session Manager - Discussion thread (CLOSED/EXPIRED Oct 2021 use http://www.snbforums.com/threads/session-manager-discussion-2nd-thread.75129/)

  • 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!

Thanks for the assist.

So I believe I have everything setup correctly (or maybe not) since I can't use the internet at all.

Here is the output fo peer wg11:

Code:
E:Option ==> peer wg11

    Peers (Auto=P - Policy, Auto=X - External i.e. Cell/Mobile)

Client  Auto  IP               Endpoint              DNS  MTU  Public                                        Private                                       Annotate
wg11    P     10.100.0.162/32  199.115.117.81:51820            Wm/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=  mxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=  # N/A

    Selective Routing RPDB rules
ID  Peer  Interface  Source         Destination  Description
1   wg11  VPN        192.168.1.222  Any          wg test pc


     WireGuard ACTIVE Peer Status: Clients 1, Servers 0

This is what I get for IP Rule:

Code:
admin@GT-AX11000-xxxx:/tmp/home/root# ip rule
0:    from all lookup local
9911:    from 192.168.1.222 lookup 121
9990:    from all fwmark 0x8000/0x8000 lookup main
9995:    from all fwmark 0x1000/0x1000 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

wg show wg11:

Code:
E:Option ==> wg show wg11

    WireGuard Userspace Tool:

interface: wg11
  public key: dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
  private key: (hidden)
  listening port: 51820

peer: Wm/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
  preshared key: (hidden)
  endpoint: 199.115.117.81:51820
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 6.65 KiB sent
  persistent keepalive: every 25 seconds

ENABLED    WireGuard ACTIVE Peer Status: Clients 1, Servers 0

ifconfig wg11:

Code:
dmin@GT-AX11000-xxxx:/tmp/home/root# ifconfig wg11
wg11      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.100.0.162  P-t-P:10.100.0.162  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:86 errors:0 dropped:1145 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:12728 (12.4 KiB)
One of the suspect is in peer wg11 output, the DNS entry is empty. Perhaps can add
Code:
peer wg11 dns 192.168.1.1
as @ZebMcKayhan and @Torson mentioned above.

Edit: Just noticed there is no Rx for the wg11 interface. It seems the peering connection is not up yet. If you have wireguard installed on your test pc, you can try enter the same config in your pc wireguard. The log tab is quite helpful that we can handshake messages. Once the configuration is working on your pc wireguard, then you can copy the same into your wg11.conf file. I think this could be easier.
 
Last edited:
One of the suspect is in peer wg11 output, the DNS entry is empty. Perhaps can add
Code:
peer wg11 dns 192.168.1.1
as @ZebMcKayhan and @Torson mentioned above.
It's odd because I have added the rule succesfully:
Code:
peer wg11 dns 192.168.1.1

Code:
E:Option ==> peer wg11 dns 192.168.1.1

    [✔] Updated DNS


ENABLED    WireGuard ACTIVE Peer Status: Clients 1, Servers 0

However, when I run 'peer wg11', the DNS and MTU show empty.
 
It's odd because I have added the rule succesfully:
Code:
peer wg11 dns 192.168.1.1

Code:
E:Option ==> peer wg11 dns 192.168.1.1

    [✔] Updated DNS


ENABLED    WireGuard ACTIVE Peer Status: Clients 1, Servers 0

However, when I run 'peer wg11', the DNS and MTU show empty.
In my output, I can see DNS entry. MTU is empty.

DNS aside, I suspect the peer to your VPN provider is not up yet with your current configuration. You can try to use the same configuration settings in your test pc wireguard client first. Once we get this up and working, then we can copy the same configuration to your router. The GUI in PC Wireguard could be easier to see.

2021-09-21 11_11_15-WireGuard (out of date).png

This is a not working case. No RX.

2021-09-21 11_14_09-WireGuard (out of date).png

In non working case, the logs show sending handshake initiation.


2021-09-21 11_29_27-WireGuard (out of date).png

This is a good working connection. There is handshake and received packets.

2021-09-21 11_18_09-WireGuard (out of date).png

In working case, there is sending and received handshake response.
 
One important aspect to consider is that the manually generated .conf files have a relatively short time to live. I've seen anything between a few hours and a few days - depending on the provider.
In other words, the .conf file can work well initially, then you stop the client, come back 2 days later and it will not connect again - in some cases. You'll need to generate a new one...

You did not mention if you've tested the .conf file with the Wireguard client before importing it.
Whether the client is on the PC or phone is irrelevant - the test is. The reason I suggested the phone is because the one on the PC once connected will drop any running SSH/SCP sessions you may have active.

So, back to square one - run:
Code:
peer wg11 del
confirm the deletion and start over with a new tested .conf file.
If still no-go (i.e. RX and/or TX show as 0 or B as opposed to KiB or MiB) run diagin the wgm interface, clean-up and post the output.
 
cant explain why DNS ant MTU does not show in wgm but it might be just a sign that the peer is not working correctly. the MTU might not be a part of the config always which means that it gets autoconfigured and might not show up until you make it part of the config (peer wg11 mtu 1420)

as the ifconfig shows proper MTU the connection is setup which means that the problem is on a lower level than DNS or routing. even without DNS or any routing you should at least get a couple of bytes from the handshakes. there is no connection to server, not even handshake replies.
kind of wish that wireguard clients would display this better. the same apparently goes for Android, it tells you are connected even though the handshake fails or there are no data.

I believe @Torson is right (I had no idea some providers were this crappy, or non-transparent).

//Zeb
 
Code:
import wg11
peer wg11 rule add 192.168.1.xxx comment wg test pc - replace 'xxx' as appropriate
peer wg11 auto=p
4 wg11
3 

peer wg11 rule add 192.168.1.1 comment Router to WAN
peer wg11 rule add 192.168.1.0/24 comment LAN to VPN
peer wg11 - you'll see 3 lines there - make note of the ID number of the original rule
peer wg11 rule del <ID> - ID is the number from the previous step (1 probably)
peer wg11 auto=y
peer wg11 dns=192.168.1.1
6 wg11
FYI, for most menu options you can also issue the fullword command as displayed in the menu (unfortunately 7 is qrcode :rolleyes:) rather than the terse numeric shortcut

This makes documenting procedures a little more human-friendly
e.g. the following should be easier to follow than the original
Code:
import wg11
peer wg11 rule add 192.168.1.xxx comment wg test pc - replace 'xxx' as appropriate
peer wg11 auto=p
start wg11
list

peer wg11 rule add 192.168.1.1 comment Router to WAN
peer wg11 rule add 192.168.1.0/24 comment LAN to VPN
peer wg11 - you'll see 3 lines there - make note of the ID number of the original rule
peer wg11 rule del <ID> - ID is the number from the previous step (1 probably)
peer wg11 auto=y
peer wg11 dns=192.168.1.1
restart wg11
 
Last edited:
I appreciate all the assistance from everyone.

I finally was able to get my PC working with wgm.

I will add my other policy rules, 1 by 1. Let's hope I don't break anything.

Just the a fast.com test and the results are pretty impressive 'wg' enabled.

Here is the results from 'diag'

Code:
E:Option ==> diag

         WireGuard VPN Peer Status
interface: wg11
  public key: xxxxxxxxxxxxxxxxxxx
  private key: (hidden)
  listening port: 42921

peer: xxxxxxxxxxxxxxxxxxxxx
  preshared key: (hidden)
  endpoint: xxx.xxx.xxx.73:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 11 seconds ago
  transfer: 187.83 MiB received, 30.69 MiB sent
  persistent keepalive: every 25 seconds

    DEBUG: Routing info MTU etc.

34: wg11: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet xx.xxx.0.234/32 scope global wg11
       valid_lft forever preferred_lft forever

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface

    DEBUG: RPDB rules

0:    from all lookup local
9911:    from 192.168.1.222 lookup 121
9990:    from all fwmark 0x8000/0x8000 lookup main
9995:    from all fwmark 0x1000/0x1000 lookup ovpnc1
10010:    from 192.168.1.1/27 lookup main
10210:    from 192.168.1.0/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

    DEBUG: Routing Table 121 (wg11) # N/A

0.0.0.0/1 dev wg11 scope link
128.0.0.0/1 dev wg11 scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

    DEBUG: Routing Table main


    DEBUG: UDP sockets.

udp        0      0 0.0.0.0:42921           0.0.0.0:*                           -
udp        0      0 :::42921                :::*                                -

    DEBUG: Firewall rules


    DEBUG: -t filter

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 77058 packets, 35M bytes)
num   pkts bytes target     prot opt in     out     source               destination        

    DEBUG: -t nat

Chain PREROUTING (policy ACCEPT 692 packets, 113K bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      592 46317 WGDNS1     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* WireGuard 'client1 DNS' */
2        1    60 WGDNS1     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 /* WireGuard 'client1 DNS' */

Chain POSTROUTING (policy ACCEPT 1690 packets, 129K bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1      890  127K MASQUERADE  all  --  *      wg11    192.168.1.0/24       0.0.0.0/0            /* WireGuard 'client' */

Chain WGDNS1 (2 references)
num   pkts bytes target     prot opt in     out     source               destination        
1      427 35267 DNAT       all  --  *      *       192.168.1.222        0.0.0.0/0            /* WireGuard 'client1 DNS' */ to:10.100.0.1

    DEBUG: -t mangle

Chain FORWARD (policy ACCEPT 187K packets, 216M bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1    75762   29M MARK       all  --  *      wg11    0.0.0.0/0            0.0.0.0/0            /* WireGuard 'client' */ MARK xset 0x1/0x7
2      410 21320 TCPMSS     tcp  --  wg11   *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
3      412 21424 TCPMSS     tcp  --  *      wg11    0.0.0.0/0            0.0.0.0/0            tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU

Chain PREROUTING (policy ACCEPT 339K packets, 415M bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1     113K  190M MARK       all  --  wg11   *       0.0.0.0/0            0.0.0.0/0            /* WireGuard 'client' */ MARK xset 0x1/0x7


Use command 'diag sql [ table_name ]' to see the SQL data (might be many lines!)

       Valid SQL Database tables: clients  devices  fwmark   ipset    policy   servers  session  traffic

             e.g. diag sql traffic will show the traffic stats SQL table


     WireGuard ACTIVE Peer Status: Clients 1, Servers 0
 
looking good @Kingp1n!

noticing you have the
Code:
9990:    from all fwmark 0x8000/0x8000 lookup main

remember that packages marked with 0x8000 originating from the clients you route out wireguard will NOT go through WAN since the wireguard policy tables have higher priority, thus they will end up going out wireguard interfaces.

I dont know if you are using this mark, but if you are it is a good idea to alter it's priority or add an additional, identical rule with higher priority. so you dont end up chasing connection errors because of this.

//Zeb
 
looking good @Kingp1n!

noticing you have the
Code:
9990:    from all fwmark 0x8000/0x8000 lookup main

remember that packages marked with 0x8000 originating from the clients you route out wireguard will NOT go through WAN since the wireguard policy tables have higher priority, thus they will end up going out wireguard interfaces.

I dont know if you are using this mark, but if you are it is a good idea to alter it's priority or add an additional, identical rule with higher priority. so you dont end up chasing connection errors because of this.

//Zeb
What would the best way to delete this?

Code:
9990:    from all fwmark 0x8000/0x8000 lookup main

Also, I didn't have to use the following DNS rule:

Code:
peer wg11 dns=192.168.1.1

It's currently using the DNS provided from the conf.file from VPNUnlimited. This should be ok correct? Everything is working without any issues.
 
<<What would the best way to delete this?>>
- are you not using it? if no packages are marked then it should not matter, you could leave it. it is created by X3mrouting I guess so if you need/want to delete it you should look at X3mrouting config.
if you make a duplicate with higher prio I would just leave it, it does not do any harm. I create the duplicate in wgm user scripts so if I bring wireguard down the other rule is still there for open VPN (if I were to use OVPN that is).
if you just delete it chances are that X3mrouting will re-apply it on some event.

<<It's currently using the DNS provided from the conf.file from VPNUnlimited. This should be ok correct?>>
- well, yes, of course. but you are bypassing router dnsmasq so ip harvesting through DNSmasq wont work (X3mrouting does this as dns method). so all in all it depends on how you want to use it.
some VPN providers blocks you from using any other DNS servers so for them, this is the easiest way (if not the only way).

//Zeb
 
<<What would the best way to delete this?>>
- are you not using it? if no packages are marked then it should not matter, you could leave it. it is created by X3mrouting I guess so if you need/want to delete it you should look at X3mrouting config.
if you make a duplicate with higher prio I would just leave it, it does not do any harm. I create the duplicate in wgm user scripts so if I bring wireguard down the other rule is still there for open VPN (if I were to use OVPN that is).
if you just delete it chances are that X3mrouting will re-apply it on some event.

<<It's currently using the DNS provided from the conf.file from VPNUnlimited. This should be ok correct?>>
- well, yes, of course. but you are bypassing router dnsmasq so ip harvesting through DNSmasq wont work (X3mrouting does this as dns method). so all in all it depends on how you want to use it.
some VPN providers blocks you from using any other DNS servers so for them, this is the easiest way (if not the only way).

//Zeb
Thanks for all information and taking the time to assist with wgm.

Last question for the day...

I noticed some of my streaming apps while using 'wg' now detect I'm using a VPN. Is there a way to get my streaming apps working again?

When I used OPVN, I had x3mRouting setup with option 3, and with the ipsets setup, I was still able to stream without issues and VPN setup.
 
Thanks for all information and taking the time to assist with wgm.

Last question for the day...

I noticed some of my streaming apps while using 'wg' now detect I'm using a VPN. Is there a way to get my streaming apps working again?

When I used OPVN, I had x3mRouting setup with option 3, and with the ipsets setup, I was still able to stream without issues and VPN setup.
Did you route your ipset to WAN? I had exactly the same issue before. Looks like you have to add the rule as @ZebMcKayhan mentioned earlier.

Here is the detail: create wg11-route-up.sh and wg11-route-down.sh in /jffs/addons/wireguard/Scripts/

Code:
#!/bin/sh

logger -t $(basename $0) "WireGuard VPN Client 1 coming up ..."

ip rule del prio 9900 2>/dev/null
ip rule add from 0/0 fwmark "0x8000/0x8000" table main prio 9900        # WAN   fwmark
logger -t $(basename $0) "ip rule 9900 added"

Code:
#!/bin/sh

logger -t $(basename $0) "WireGuard VPN Client 1 going down ..."

ip rule del prio 9900 2>/dev/null
logger -t $(basename $0) "ip rule 9900 deleted"

After that make sure to make both files executable. Since your wg11 is already up, you will need to restart wg11 once to make it take effect.
Code:
chmod +x wg11-route-up.sh
chmod +x wg11-route-down.sh
 
Last edited:
Did you route your ipset to WAN? I had exactly the same issue before. Looks like you have to add the rule as @ZebMcKayhan mentioned earlier.

Here is the detail: create wg11-route-up.sh and wg11-route-down.sh in /jffs/addons/wireguard/Scripts/

Code:
#!/bin/sh

logger -t $(basename $0) "WireGuard VPN Client 1 coming up ..."

ip rule del prio 9900 2>/dev/null
ip rule add from 0/0 fwmark "0x8000/0x8000" table main prio 9900        # WAN   fwmark
logger -t $(basename $0) "ip rule 9900 added"

Code:
#!/bin/sh

logger -t $(basename $0) "WireGuard VPN Client 1 going down ..."

ip rule del prio 9900 2>/dev/null
logger -t $(basename $0) "ip rule 9900 deleted"

After that make sure to make both files executable. Since your wg11 is already up, you will need to restart wg11 once to make it take effect.
Code:
chmod +x wg11-route-up.sh
chmod +x wg11-route-down.sh
I appreciate this.. got it working. I also had to use "US streaming conf" file from VPNUnlimited to help with HBOMax. All is working flawlessly.

If I restart the router, wg should automatically start working, I'm assuming. I dont want to reset router to test but I might just have too.

Thanks again!!!! Much appreciated.
 
Last edited:
I appreciate this.. got it working. I also had to use "US streaming conf" file from VPNUnlimited to help with HBOMax. All is working flawlessly.

If I restart the router, wg should automatically start working, I'm assuming. I dont want to reset router to test but I might just have too.
Great!

Everything should pop back but there is only one true way to find out... reboot...

//Zeb
 
Great!

Everything should pop back but there is only one true way to find out... reboot...

//Zeb
I rebooted the router, and wg didn't not start automatically.

I had to ssh into wgm and input 'restart wg11'.

This brought everything back up for me.

Any idea why this might have happened?

I looked at syslog and it shows I have Kill-switch enabled, but I haven't set it up yet. Can this be the cause?

Thanks!

Update:

I did a 2nd reboot and the router did come back up automatically. I'll keep an eye out on this but ALL is gtg!
 
Last edited:
I rebooted the router, and wg didn't not start automatically.

I had to ssh into wgm and input 'restart wg11'.

This brought everything back up for me.

Any idea why this might have happened?

I looked at syslog and it shows I have Kill-switch enabled, but I haven't set it up yet. Can this be the cause?

Thanks!
That's wierd. You mean wg kill switch? I have the same altough wgm shows it as disabled.
Can you verify If the connection is setup after reboot, like:
Code:
wgm show wg11

If you see tx/rx bytes this would mean that the connection is established but either some rules failed to apply or some other script is preventing access and start order will matter.
Are you sure you are not using ovpn killswitch?? Any other script that might be doing this??

//Zeb

Edit: while checking peer connection also check "ip rule" so everything looks as before you rebooted.
 
Last edited:
That's wierd. You mean wg kill switch? I have the same altough wgm shows it as disabled.
Can you verify If the connection is setup after reboot, like:
Code:
wgm show wg11

If you see tx/rx bytes this would mean that the connection is established but either some rules failed to apply or some other script is preventing access and start order will matter.
Are you sure you are not using ovpn killswitch?? Any other script that might be doing this??

//Zeb
All is good now after a reboot. I have rebooted a few times now and wg starts to work again.

At this time, I have ovpn disabled and no other script running. I was previosly using swinson script (w/unbound) but I have removed since it seems is no longer required. I removed it before installing wgm.
 
All is good now after a reboot. I have rebooted a few times now and wg starts to work again.

At this time, I have ovpn disabled and no other script running. I was previosly using swinson script (w/unbound) but I have removed since it seems is no longer required. I removed it before installing wgm.
Ok, great!

So was the problem ovpn? Or do you know what caused issue the first time?

//Zeb
 
Ok, great!

So was the problem ovpn? Or do you know what caused issue the first time?

//Zeb
I'm not sure what may have caused the issue.

This is what "About Configuration" shows:

Code:
E:Option ==> ?

    v4.10 WireGuard Session Manager (Change Log: https://github.com/MartineauUK/wireguard/commits/main/wg_manager.sh)
    MD5=c54f076d5fffaa530ca8335138ac6797 /jffs/addons/wireguard/wg_manager.sh

    [✔] arch=aarch64

   
   

    [✔] WireGuard Module is LOADED


    Warning: Reboot required for (dmesg) WireGuard 1.0.20210219

    MD5=eb43094e89f7cc80798ae4809f9f312a wireguard-kernel_1.0.20210219-k51_1_aarch64-3.10.ipk
    MD5=09697c508bf4a54203efe11a26a15b46 wireguard-tools_1.0.20210315-1_aarch64-3.10.ipk

    [✔] DNSmasq is listening on ALL WireGuard interfaces 'wg*'

    [✔] nat-start is monitoring WireGuard Firewall rules

    [✔] WAN KILL-Switch is ENABLED
    [✖] UDP monitor is DISABLED
    [✔] Statistics gathering is ENABLED

ENABLED    WireGuard ACTIVE Peer Status: Clients 1, Servers 0

This is where I'm seeing WAN kill-switch is enabled.

However, the opvn is off/disabled so I'm wondering where else this can be coming from.
 
I'm not sure what may have caused the issue.

This is what "About Configuration" shows:

Code:
E:Option ==> ?

    v4.10 WireGuard Session Manager (Change Log: https://github.com/MartineauUK/wireguard/commits/main/wg_manager.sh)
    MD5=c54f076d5fffaa530ca8335138ac6797 /jffs/addons/wireguard/wg_manager.sh

    [✔] arch=aarch64

  
  

    [✔] WireGuard Module is LOADED


    Warning: Reboot required for (dmesg) WireGuard 1.0.20210219

    MD5=eb43094e89f7cc80798ae4809f9f312a wireguard-kernel_1.0.20210219-k51_1_aarch64-3.10.ipk
    MD5=09697c508bf4a54203efe11a26a15b46 wireguard-tools_1.0.20210315-1_aarch64-3.10.ipk

    [✔] DNSmasq is listening on ALL WireGuard interfaces 'wg*'

    [✔] nat-start is monitoring WireGuard Firewall rules

    [✔] WAN KILL-Switch is ENABLED
    [✖] UDP monitor is DISABLED
    [✔] Statistics gathering is ENABLED

ENABLED    WireGuard ACTIVE Peer Status: Clients 1, Servers 0

This is where I'm seeing WAN kill-switch is enabled.

However, the opvn is off/disabled so I'm wondering where else this can be coming from.
Well, you could always turn it off:
Code:
E:Option ==> killswitch off

You should really consider to update to the latest dev build, it is more stable:
Code:
E:Option ==> uf dev
However, the database has been updated for improved stats,
Check post #321 to update your database without starting over:
http://www.snbforums.com/threads/session-manager.70787/post-696141

//Zeb
 

Latest threads

Sign Up For SNBForums Daily Digest

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