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

[ZebMcKayhan]

* No internet access through wg11's assigned wifi network (which uses YazFi). Other than assigning the 192.168.6.x to it, I didn't change any YazFi settings in the router admin panel so everything is defaulted to "no" except the enabled radio button.

Ok, so the rule is for wg21. Probably ok then.

Looks like wgm removes all rules and still yazfi Clients can't connect to wan? This is something that yazfi should setup by itself. Sound like a yazfi problem and not a wgm problem.
- have you updated yazfi lately?
- try create a new guest network and see if that can connect to wan (without adding anything).

//Zeb

 

[paulmorabi]

Ok, so the rule is for wg21. Probably ok then.

Looks like wgm removes all rules and still yazfi Clients can't connect to wan? This is something that yazfi should setup by itself. Sound like a yazfi problem and not a wgm problem.
- have you updated yazfi lately?
- try create a new guest network and see if that can connect to wan (without adding anything).

//Zeb

I'm running latest YazFi (4.2.1) and have another guest network that is working fine.

 

[ZebMcKayhan]

I'm running latest YazFi (4.2.1) and have another guest network that is working fine.

If your ip rule looks like this:

paul@RT-AX88U-6948:/tmp/home/root# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

And everything but 192.168.6.x can access wan something is really strange. Try to revert everything you have done that would affect 192.168.6.x network.
Or start over with another guest network and add piece by piece. Hopefully you find which piece that is preventing this subnet from accessing wan.

//Zeb

 

[paulmorabi]

If your ip rule looks like this:

paul@RT-AX88U-6948:/tmp/home/root# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

And everything but 192.168.6.x can access wan something is really strange. Try to revert everything you have done that would affect 192.168.6.x network.
Or start over with another guest network and add piece by piece. Hopefully you find which piece that is preventing this subnet from accessing wan.

//Zeb

When wg11 is disabled, clients in 182.168.6.x can access WAN. When wg11 is enabled, it doesn't work.

 

[ZebMcKayhan]

When wg11 is disabled, clients in 182.168.6.x can access WAN. When wg11 is enabled, it doesn't work.

According to your post #308 I enterpreted this as this was working. When did it stop?

//Zeb

 

[paulmorabi]

@ZebMcKayhan So, I basically started again, and reimported the wireguard config from scratch.

1. Added the wifi guest network. It works fine when not linked to a wireguard connection.
2. Imported the config, set auto=p and Guest2VPN rule with up/down script. Wifi connection has no LAN or internet.
3. Added ToLocalUseWan rule. Works!

Client  Auto  IP               Endpoint              DNS             MTU  Public                                        Private                                       Annotate
wg11    P     10.64.55.179/32  x.x.x.x:51820  x.x.x.x        # N/A

    Selective Routing RPDB rules
ID  Peer  Interface  Source          Destination     Description
2   wg11  WAN        0.0.0.0/0       192.168.0.0/16  ToLocalUseWan
1   wg11  VPN        192.168.6.0/24  Any             Guest2VPN

paul@RT-AX88U-6948:/tmp/home/root# ip rule
0:    from all lookup local
9910:    from all to 192.168.0.0/16 lookup main
9911:    from 192.168.6.0/24 lookup 121
32766:    from all lookup main
32767:    from all lookup default

Then I went into YazFi and enabled two way access between the Wifi network and LAN (192.168.1.x). That now works also.

WAN IP on guest wifi is VPN's IP while 192.168.1.x has WAN IP from my ISP. I can't access router 192.168.1.1 from WG11 Wifi network as you predicted but I can look into what I need for this.

I'm curious as why ToLocalUseWan is required but otherwise, I've started and stopped several times and it looks like it is fine.

wg21 is still not working with LAN or WAN access. @chongnt did you define any specific routing rules for it? I can see "9810: from all fwmark 0xd2 lookup 210" in rules but have nothing else set.

 

[ZebMcKayhan]

I can't access router 192.168.1.1 from WG11 Wifi network as you predicted but I can look into what I need for this.

I'm curious as why ToLocalUseWan is required but otherwise, I've started and stopped several times and it looks like it is fine

I'm glad that got sorted out.
I'm not sure why this rule is needed in your case. Hopefully you figure it out as you go. I added it on my system on routine so I never tried without it.

I added this in yazfi custom config (same file as the other) to allow subnet to access router:

#allow guest wifi 2 to access local services
iptables -I YazFiINPUT -i wl1.2 -j ACCEPT

Good luck with your server!

//Zeb

 

[paulmorabi]

I'm glad that got sorted out.
I'm not sure why this rule is needed in your case. Hopefully you figure it out as you go. I added it on my system on routine so I never tried without it.

I added this in yazfi custom config (same file as the other) to allow subnet to access router:

#allow guest wifi 2 to access local services
iptables -I YazFiINPUT -i wl1.2 -j ACCEPT

Good luck with your server!

//Zeb

So that last rule will allow access to 192.168.1.1 from the wg11 guest wifi?

Thanks so much for your help. I'll keep working at this and update the thread as I make progress.

 

[ZebMcKayhan]

So that last rule will allow access to 192.168.1.1 from the wg11 guest wifi?

Yes, it will allow the 192.168.6.x subnet to access router gui, ssh, smb share or any other service that are local to router itself.

//Zeb

 

[chongnt]

wg21 is still not working with LAN or WAN access. @chongnt did you define any specific routing rules for it? I can see "9810: from all fwmark 0xd2 lookup 210" in rules but have nothing else set.

I just re-test my wg21 connection from my phone. Looks like I got it wrong. My phone cannot access to my LAN 192.168.1.x, but can access to internet via WAN. I disconnect from wg21 and connect to openvpn server on router, my phone have access to 192.168.1.x. Next I disconnect from ovpn server, reconnect to wg21, now my phone can access to devices that I had access before in ovpn connection. My phone still cannot access 192.168.1.y that I did not access in opvn earlier. LAN part is not working correctly. Device that go through WAN can ping to my phone in 10.50.1.2. Home device that I have put to route via public VPN is searching for 10.50.1.2 in the public VPN. Lets put this aside first.

I did not define any rules for wg21. When you run peer in wgm, there is a summary of wg21, wg11 and Device. Make sure your phone/laptop that used to peer to wg21 has the same settings on IP, DNS and allowed IPs. I have allowed IP set to 0.0.0.0/0.

 

[ZebMcKayhan]

@chongnt
"Device that go through WAN can ping to my phone in 10.50.1.2."
- yes, this is because these devices uses wan/main table were all routes are defined

"Home device that I have put to route via public VPN is searching for 10.50.1.2 in the public VPN."
- yes, these devices use wg11 table and there are no routes to that destination there.

If your wg server subnet is 10.50.1.x, try adding this rule in wg11:

peer wg11 add rule wan 0.0.0.0/0 10.50.1.1/24 comment ToWgServerUseWan

Wan rules will have higher priority so this will be used before the vpn rules.

This would by the way solve your dns problem if you want to have another go

Don't know what's up with your lan access. Sounds like route cache would be involved in this. If you flush it after accessing devices via openVPN can you still access these routes via wg server?

//Zeb

 

[chongnt]

@chongnt
"Device that go through WAN can ping to my phone in 10.50.1.2."
- yes, this is because these devices uses wan/main table were all routes are defined

"Home device that I have put to route via public VPN is searching for 10.50.1.2 in the public VPN."
- yes, these devices use wg11 table and there are no routes to that destination there.

If your wg server subnet is 10.50.1.x, try adding this rule in wg11:

peer wg11 add rule wan 0.0.0.0/0 10.50.1.1/24 comment ToWgServerUseWan

Wan rules will have higher priority so this will be used before the vpn rules.

This would by the way solve your dns problem if you want to have another go

Don't know what's up with your lan access. Sounds like route cache would be involved in this. If you flush it after accessing devices via openVPN can you still access these routes via wg server?

//Zeb

You are definitely right. So it was working as expected.
On my LAN, I can access everything other than two devices. I don’t know what went wrong in my test earlier.
The weird one is my desktop 192.168.1.2. I can ping from router but cannot traceroute to it. So it is a different issue. The other one is a tp-link router acting as access point 192.168.1.9. I can access it when I dial-in from ovpn but not from wg21. Other than that I can access to other LAN devices. I guess can consider it is working.

Update: Desktop working fine now. Turns up it is firewall setting that mess it up.
Update2: Tp-link router is working too. By default it only reply to 192.168.1.x network. I have to add 10.50.1.x and 10.50.2.x, and subnet used for ovpn server connection so that it will reply properly. It was something not right that make it works earlier. One of my ovpn server acted strange, ping packet from my phone appears to come from 192.168.1.1 when it is send to TP-link, this is how I manage to connect to it with ovpn. After reboot the router, connection from ovpn server is correctly shown as 10.21.1.x.

 

[paulmorabi]

You are definitely right. So it was working as expected.
On my LAN, I can access everything other than two devices. I don’t know what went wrong in my test earlier.
The weird one is my desktop 192.168.1.2. I can ping from router but cannot traceroute to it. So it is a different issue. The other one is a tp-link router acting as access point 192.168.1.9. I can access it when I dial-in from ovpn but not from wg21. Other than that I can access to other LAN devices. I guess can consider it is working.
View attachment 34694

Update: Desktop working fine now. Turns up it is firewall setting that mess it up.
Update2: Tp-link router is working too. By default it only reply to 192.168.1.x network. I have to add 10.50.1.x and 10.50.2.x, and subnet used for ovpn server connection so that it will reply properly. It was something not right that make it works earlier. One of my ovpn server acted strange, ping packet from my phone appears to come from 192.168.1.1 when it is send to TP-link, this is how I manage to connect to it with ovpn. After reboot the router, connection from ovpn server is correctly shown as 10.21.1.x.

@chongnt In my case, DNS is 10.50.1.2. I can ping this from the wg21 connected client but not from any clients on 192.168.1.x (destination host unreachable). Likewise, I cannot get DNS or ping 192.168.1.x or WAN IP's from wg21.

I'm guessing that I don't have the right routing configured for this. Other than the 9810 rule, do you have any other rules for your wg21 connection?

And looking at more general wireguard guides, they seem to mention this as being needed:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Which would mean we need to point wg21 to br0? I tried this in the up and down scripts and it complained about duplicated rules and the rules table is unchanged:

0:    from all lookup local
9810:    from all fwmark 0xd2 lookup 210
9910:    from all to 192.168.0.0/16 lookup main
9911:    from 192.168.6.0/24 lookup 121
32766:    from all lookup main
32767:    from all lookup default

I tried also:

iptables -t nat -I POSTROUTING -s 10.50.1.0/24 -o br0 -j MASQUERADE

But it complained about 10.50.1.0/24 as being a bad address.

Assuming from above, I have the necessary rules, is there anywhere I can check for possible firewall or other rules that could be blocking?

 

[ZebMcKayhan]

@chongnt In my case, DNS is 10.50.1.2. I can ping this from the wg21 connected client but not from any clients on 192.168.1.x (destination host unreachable). Likewise, I cannot get DNS or ping 192.168.1.x or WAN IP's from wg21.

I'm guessing that I don't have the right routing configured for this. Other than the 9810 rule, do you have any other rules for your wg21 connection?

And looking at more general wireguard guides, they seem to mention this as being needed:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Which would mean we need to point wg21 to br0? I tried this in the up and down scripts and it complained about duplicated rules and the rules table is unchanged:

0:    from all lookup local
9810:    from all fwmark 0xd2 lookup 210
9910:    from all to 192.168.0.0/16 lookup main
9911:    from 192.168.6.0/24 lookup 121
32766:    from all lookup main
32767:    from all lookup default

I tried also:

iptables -t nat -I POSTROUTING -s 10.50.1.0/24 -o br0 -j MASQUERADE

But it complained about 10.50.1.0/24 as being a bad address.

Assuming from above, I have the necessary rules, is there anywhere I can check for possible firewall or other rules that could be blocking?

Ip route and iptables are 2 completally different things.

Ip manages routing tables and rules on when to use which. Basically to find out were to send a package with a specific destination adress. If you create device wl1.2 with a subnet 192.168.6.x the kernel will create this in main routing table:

192.168.6.0/24 dev wl1.2 proto kernel scope link src 192.168.6.1

So when any package that has the destination of 192.168.6.x this entry will tell that this package should be sent out on wl1.2 interface.

Now the iptables is actually the firewall which contain access rules and package handling rules. So if a package is routed to go from br0 to wl1.1 iptables can block this by denying access (filter). Iptables is also used for adress translation (masquarading) (nat), package size or mark handling (mangle).

You can check i.e the filter table to see what it contain by:

iptables -t filter -L -v

Or more specific filter table in the FORWARD chain:

iptables -t filter -L FORWARD -v

I like this picture about how the tables are arranged:

But I wouldnt mess around to much without knowing what you are doing since you could put your network completally open from the internet if you put the wrong rule in the wrong place.

Some good info here: https://www.booleanworld.com/depth-guide-iptables-linux-firewall/

//Zeb

 

[paulmorabi]

Ip route and iptables are 2 completally different things.

Ip manages routing tables and rules on when to use which. Basically to find out were to send a package with a specific source adress. If you create device wl1.2 with a subnet 192.168.6.x the kernel will create this in main routing table:

192.168.6.0/24 dev wl1.2 proto kernel scope link src 192.168.6.1

So when any package that has the destination of 192.168.6.x this entry will tell that this package should be sent out on wl1.2 interface.

Now the iptables is actually the firewall which contain access rules and package handling rules. So if a package is routed to go from br0 to wl1.1 iptables can block this by denying access (filter). Iptables is also used for adress translation (masquarading) (nat), package size or mark handling (mangle).

You can check i.e the filter table to see what it contain by:

iptables -t filter -L -v

I like this picture about how the tables are arranged:
View attachment 34721

But I wouldnt mess around to much without knowing what you are doing since you could put your network completally open from the internet if you put the wrong rule in the wrong place.

Some good info here: https://www.booleanworld.com/depth-guide-iptables-linux-firewall/

//Zeb

Thank you for this @ZebMcKayhan! It makes more sense now. I can see there are iptables entries for wg21 when its running but they are all ACCEPT and have either all or wg21 alternating as source and destination. I can't see how it could be these blocking any access to either the 192.168.1.x subnet or WAN. I'll keep digging and looking into this.

 

[chongnt]

@chongnt In my case, DNS is 10.50.1.2. I can ping this from the wg21 connected client but not from any clients on 192.168.1.x (destination host unreachable). Likewise, I cannot get DNS or ping 192.168.1.x or WAN IP's from wg21.

I'm guessing that I don't have the right routing configured for this. Other than the 9810 rule, do you have any other rules for your wg21 connection?

And looking at more general wireguard guides, they seem to mention this as being needed:

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Which would mean we need to point wg21 to br0? I tried this in the up and down scripts and it complained about duplicated rules and the rules table is unchanged:

0:    from all lookup local
9810:    from all fwmark 0xd2 lookup 210
9910:    from all to 192.168.0.0/16 lookup main
9911:    from 192.168.6.0/24 lookup 121
32766:    from all lookup main
32767:    from all lookup default

I tried also:

iptables -t nat -I POSTROUTING -s 10.50.1.0/24 -o br0 -j MASQUERADE

But it complained about 10.50.1.0/24 as being a bad address.

Assuming from above, I have the necessary rules, is there anywhere I can check for possible firewall or other rules that could be blocking?

The rules should be fine. Lets verify if the client can properly peer with wg21. By default, wg21 ip is 10.50.1.1 (can cross check from ifconfig wg21). In your client device wg program, the interface address should be something like 10.50.1.2/32. Once connected successfully, client should be able to ping 10.50.1.1. Are you able to ping this address? Is there any data sent and received?

 

[paulmorabi]

The rules should be fine. Lets verify if the client can properly peer with wg21. By default, wg21 ip is 10.50.1.1 (can cross check from ifconfig wg21). In your client device wg program, the interface address should be something like 10.50.1.2/32. Once connected successfully, client should be able to ping 10.50.1.1. Are you able to ping this address? Is there any data sent and received?

The rules should be fine. Lets verify if the client can properly peer with wg21. By default, wg21 ip is 10.50.1.1 (can cross check from ifconfig wg21). In your client device wg program, the interface address should be something like 10.50.1.2/32. Once connected successfully, client should be able to ping 10.50.1.1. Are you able to ping this address? Is there any data sent and received?

Yep, I can see the connection is successful and interface address is as you say. There is a few kB of data transferred only (1kb up, 38kb down). I get an IP in the 10.50.1.x range (the IP allocated to my device). When connected, I can’t ping 10.50.1.1 (request timeout) or any WAN address.

 

[chongnt]

Yep, I can see the connection is successful and interface address is as you say. There is a few kB of data transferred only (1kb up, 38kb down). I get an IP in the 10.50.1.x range (the IP allocated to my device). When connected, I can’t ping 10.50.1.1 (request timeout) or any WAN address.

I have experience this. I delete and recreate device with same name but did not update in my client config. In my client it say connected but there is no connection. Perhaps can try recreate device and import the new config to client wg program again?

 

[ZebMcKayhan]

Is there any way from the server (router) side to check if and how many Clients connected to the server?

//Zeb

 

[chongnt]

Is there any way from the server (router) side to check if and how many Clients connected to the server?

//Zeb

I just found this command today

wg show

or more specific

wg show wg21

. I don't know a clear way to tell. With persistent keepalive set to 25secs, the latest handshake timer will be under 2 minutes for an active connection before it gets refreshed. If the latest handshake is much longer that means the client has disconnected for some time. Or if a configured peer device has never attempted a connection to the server, there is not latest handshake info at all.
Here I have two servers. wg21 has two peer devices configured in wgm. wg22 has a single peer device configured. In server wg21, the first peer device is connected and active while the second device has not make any connection yet. In the second server wg22, the device has disconnected for a few minutes

admin@RT-AC86U-DBA8:/tmp/home/root# wg show wg21
interface: wg21
  public key: vxNz9BE4j+kwNHOeAky7P5wMgdnds5khE/Wskqo31xk=
  private key: (hidden)
  listening port: 54321

peer: cf7OoApHobMWd8rtku19FkOBhZjQ560Fmw3fwBdc7S4=
  endpoint: xx:65261
  allowed ips: 10.50.21.3/32
  latest handshake: 1 minute, 23 seconds ago
  transfer: 13.38 MiB received, 739.15 MiB sent

peer: jyCgh9zXijYdjFCxSvDECd9NzhsTkVlShwZN9E3E0=
  allowed ips: 10.50.21.2/32
admin@RT-AC86U-DBA8:/tmp/home/root# 

admin@RT-AC86U-DBA8:/tmp/home/root# wg show wg22
interface: wg22
  public key: hkkZYYdYgq8rjzBJCYTXfdg3AIYhjpovHfJM6rjrNWSg=
  private key: (hidden)
  listening port: 54320

peer: cbm0bS2GyiGqZhkedX7Whqn+KtyJqUjyQfoqNRic+TI=
  endpoint: xx:58796
  allowed ips: 10.50.22.2/32
  latest handshake: 8 minutes, 57 seconds ago
  transfer: 589.94 KiB received, 13.77 MiB sent