Wireguard Session Manager - Discussion (3rd) thread

[juanantonio]

You mean via your VPN Internet supplier? This is only possible if your VPN is opening ports to you which is usually not the case.

Well, my VPN supplier allows me to forward ports between my local devices and the public ip they are giving me

Any reason you are not running site2site between your trusted networks? That makes the networks more transparent and forwarding easier:
https://github.com/ZebMcKayhan/WireguardManager/blob/main/README.md#site-2-site
and
https://github.com/ZebMcKayhan/Wire...n/README.md#route-site-2-site-internet-access

I've just tried site2site.
Although seems to be a great solution, I think it cannot solve my problem, because in one of the endpoints I am using Android tethering to gain access to the Inet, and my router says there are no DDNS, because the WAN IP is not public (it's a private address in the range of 192.168.xxx.xxx), so at the moment of configure site2site it ask for the IP/DDNS of the two endpoints and I only have DDNS for one of them, the other is a random IP.

Anyhow, with your current setup portforwarding needs to be done in 2 steps, first forward (Port 8001?) from wg11 to your server client (10.50.1.2:8001?) Then to the final destination (192.168.50.123:8001?). Could look something like this:

My setup is like follows:

VPN Supplier (Public IP) <---> RT-AX86U Wireguard Client (IP 10.151.13.172) <---> RT-AX86U Wireguard Server (IP 10.50.1.1) <---> RT-AC86U Wireguard Client (IP 10.50.1.6) <---> Local Area Network (IP 192.168.0.0).

I've tried with:

RT-AX86U:

iptables -t nat -I PREROUTING -i wg11 -p tcp --dport 20500 -j DNAT --to-destination 10.50.1.1:20500
iptables -I FORWARD -i wg11 -p tcp -d 10.50.1.1 --dport 20500 -m state --state NEW -j ACCEPT

RT-AC86U:

iptables -t nat -I PREROUTING -p tcp -i wg11 --dport 20500 -j DNAT --to-destination 192.168.0.238:20500
iptables -I FORWARD -p tcp -d 192.168.0.238 --dport 20500 -m state --state NEW -j ACCEPT

And also with:

RT-AX86U:

iptables -t nat -I PREROUTING -i wg11 -p tcp --dport 20500 -j DNAT --to-destination 10.50.1.6:20500
iptables -I FORWARD -i wg11 -p tcp -d 10.50.1.6 --dport 20500 -m state --state NEW -j ACCEPT

RT-AC86U:

iptables -t nat -I PREROUTING -p tcp -i wg11 --dport 20500 -j DNAT --to-destination 192.168.0.238:20500
iptables -I FORWARD -p tcp -d 192.168.0.238 --dport 20500 -m state --state NEW -j ACCEPT

With no luck.

maybee this is possible to setup in the GUI instead, but I'm not at home so cant check.

Really it is possible to do this through the GUI? It would be great news.

Thanks in advance.

Edit: Finally I got it working. The router needed a restart. I got a weird message while starting wg_manager, as follows:

juanantonio@RT-AX86U-6C38:/tmp/home/root# wgm

(wg_manager.sh): 16989 DEBUG= *********************************WTF!? Rogue RPDB IPv4 rule 220 FOUND?????!!!!!*******************************

        IPv4 RPDB

0:      from all lookup local
220:    from all lookup 220
9810:   from all fwmark 0xd2 lookup 210
9910:   from all to 10.50.1.1/24 lookup main
9981:   from 10.50.1.0/24 lookup 121
10210:  from 192.168.1.14 lookup ovpnc1
10211:  from 192.168.1.12 lookup ovpnc1
10212:  from 192.168.1.137 lookup ovpnc1
10213:  from 192.168.1.170 lookup ovpnc1
10214:  from 192.168.1.237 lookup ovpnc1
10215:  from 192.168.1.18 lookup ovpnc1
10216:  from 10.10.0.0/24 lookup ovpnc1
10217:  from 10.12.0.0/24 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

        IPv4 Route Table 220

10.12.0.1 via 87.235.0.10 dev ppp0 proto static

        Press y to Delete rogue RPDB PRIO 220 rules or press [Enter] to SKIP.
y

But now everything is working.

The only thing is that in the passthru node (RT-AX86U) you have to forward the port not at the wireguard server IP (10.50.1.1), but at the device client IP (10.5.1.6). This sounded to me a little strange, but that's it.

Many thanks for your advice.

 

[ZebMcKayhan]

The only thing is that in the passthru node (RT-AX86U) you have to forward the port not at the wireguard server IP (10.50.1.1), but at the device client IP (10.5.1.6). This sounded to me a little strange, but that's it.

Yep, that's what I was trying to explain. Because of your setup the ax86u has no knowledge of ac86u lan, only the wg client connected to the server so portforward to ac86u wg11 first, then on the ac86u you need to forward again to the lan ip.

If you were running site2site you will need to split ip ranges on lan like ax86u: 192.168.1.0/24 and ac86u:192.168.2.0/24 then both lan is accessible from either side and port forwarding could be done on ax86u directly to the lan client connected on the ac86u.

PS. Only one Endpoint is needed for site2site. You should be able to leave one blank as both sides dont need to contact each other.

Edit: you can probably discard the Rouge 220 error, but if you want you can suppress or delete in config using vx

 

[juanantonio]

PS. Only one Endpoint is needed for site2site. You should be able to leave one blank as both sides dont need to contact each other.

So I don't need to have DDNS available on both endpoints?

 

[ZebMcKayhan]

So I don't need to have DDNS available on both endpoints?

I don't believe so. @JGrana has this setup, he could probably assist you with the details.

 

[juanantonio]

I don't believe so. @JGrana has this setup, he could probably assist you with the details.

Well, I hope he will read this thread and answer. If not, I always can send a PM to him.
Many thanks.

 

[ZebMcKayhan]

Well, I hope he will read this thread and answer. If not, I always can send a PM to him.
Many thanks.

He will probably respond when he have the time. Anyhow it is better you have the discussion here so others could benefit as well.

 

[JGrana]

Actually I do have DDNS at both sites. In both cases I’m using the Asuswrt DDNS. Works well, never had any issues.
I believe site2site is kind of bi-directional. SiteA is a server to SiteB and SiteB is a server to SiteA.
It’s a pretty simple setup actually (once @ZebMcKayhan and @Martineau helped figure out the iptables rules!).

 

[juanantonio]

Actually I do have DDNS at both sites. In both cases I’m using the Asuswrt DDNS. Works well, never had any issues.
I believe site2site is kind of bi-directional. SiteA is a server to SiteB and SiteB is a server to SiteA.
It’s a pretty simple setup actually (once @ZebMcKayhan and @Martineau helped figure out the iptables rules!).

Well, I've managed to install an application on my tethered Android phone which keeps updated my new domain linked with the phone on no-ip.com.

So I think now I am in similar situation as you were when you first configured your site 2 site connection.

Can anyone point me the thread (and messages) on the forum where you talked about building your site 2 site tunnel?

I think I don't need anymore (well, of course the guide from @ZebMcKayhan on GitHub).

Many thanks.

 

[ZebMcKayhan]

I believe site2site is kind of bi-directional. SiteA is a server to SiteB and SiteB is a server to SiteA.

Yes, but there is only one peer (wg21) on each side and I think its enough if one side can contact the other. Sorry @juanantonio but regardless of your current needs I think this is important to clear out.

Perhaps @Martineau knows wheither or not both sides of a Wireguard site2site wgm setup requires ddns (or static public ip) or if it's enough that one side is reachable?

 

[juanantonio]

Perhaps @Martineau knows wheither or not both sides of a Wireguard site2site wgm setup requires ddns (or static public ip) or if it's enough that one side is reachable?

Well, fortunately the tunnel is up and running. It seems that, as you previously said, it is not absolutely necessary to have DDNS in both sides.

Just in case, I had installed a DDNS updater on my tethered mobile phone, but I think it is not being used.

I started the tunnel from the side that has DDNS and, after that, started the other side and Voilà! Now I have remote access to my LAN through the site2site tunnel.

Now, I would like to now the way to forward an specific port from my public IP (VPN supplier) to my client PC in the site2site tunnel.

It would be something like this:

VPN Supplier (Public IP: 20500) <---> Wireguard Client wg11 (RT-AX86U) (10.151.13.172:20500) <---> Wireguard Server wg22 (RT-AX86U) (10.16.0.1:20500) <---> Wireguard Server wg22 (RT-AC86U) (10.16.0.2) <---> PC Client (192.168.0.238:20500)

Now that the site2site tunnel is established, please, can someone tell me how to forward the port 20500 between wg11 Iface and PC Client?

Thanks, anyway.

 

[ZebMcKayhan]

It seems that, as you previously said, it is not absolutely necessary to have DDNS in both sides.

Great job! Good to know!

Now that the site2site tunnel is established, please, can someone tell me how to forward the port 20500 between wg11 Iface and PC Client?

First of all you would need internet access to go via wg11 on ax86u from 192.168.0.238 for this to work (so internet through remote peer on ac86u, then passthru to wg11 on ax86u), then on ax86u just redirect incoming connections on port 20500 directly to 192.168.0.238:

iptables -t nat -I PREROUTING -i wg11 -p tcp --dport 20500 -j DNAT --to-destination 192.168.0.238:20500 
iptables -I FORWARD -i wg11 -p tcp -d 192.168.0.238 --dport 20500 -m state --state NEW -j ACCEPT

That should be it (I'm hooping)

Edit: I believe these rules are best placed in wg11-up.sh since wg11 is the last interface started. And remove the rules in wg11-down.sh
There are plenty of references in my guide to these so just search around.

Edit2: Any passthru rules needs to be made on ax86u with ac86u lan address. Hooping wgm will not complain about this, otherwise you need to do it manually (examples on my github)

 

[JGrana]

Yes, but there is only one peer (wg21) on each side and I think its enough if one side can contact the other. Sorry @juanantonio but regardless of your current needs I think this is important to clear out.

Perhaps @Martineau knows wheither or not both sides of a Wireguard site2site wgm setup requires ddns (or static public ip) or if it's enough that one side is reachable?

Your right, I need to break the habit of client/server.

Site2site is simply peer to peer. I believe as long as you have Site A’s subnet in Site B’s allowed IP and vice versa - you should be good.

I would think for truly bidirectional peer2peer, you would need the public IP as endpoints. On both. That way either side could initiate connection.

I guess if one side has issues with a public IP, once the tunnel is setup by the “other“ side, it routes fine.
Never really tried just having site B (or in my case, the Cabin) not define its public IP as an endpoint.
@Martineau , does this sound correct?

 

[Martineau]

Your right, I need to break the habit of client/server.

Site2site is simply peer to peer. I believe as long as you have Site A’s subnet in Site B’s allowed IP and vice versa - you should be good.

I would think for truly bidirectional peer2peer, you would need the public IP as endpoints. On both. That way either side could initiate connection.

I guess if one side has issues with a public IP, once the tunnel is setup by the “other“ side, it routes fine.
Never really tried just having site B (or in my case, the Cabin) not define its public IP as an endpoint.
@Martineau , does this sound correct?

In a classic client-server configuration, then unless you have the luxury of having a true static WAN IP for the server (or by chance a dynamic WAN IP assigned that simply never changes), then using a DDNS reference on the client is usually (for convenience) promoted as mandatory?

If either of your Site-to-Site .conf files references a DDNS, then you should see a wg_manager generated cron job that instructs the wg utility to internally update/refresh its target Endpoint when the handshake fails i.e. resolves the DDNS.

Clearly there is no such mechanism on mobile devices, so you need to stop the interface for the resolving of the Endpoint to its (new) IP.

DDNS references on both Endpoints doesn't hurt, but it may prove beneficial in operation (maintaining the reliability/integrity of the connection), with less manual admin overhead.

 

[ZebMcKayhan]

I started the tunnel from the side that has DDNS and, after that, started the other side and Voilà! Now I have remote access to my LAN through the site2site tunnel.

How are you progressing?

Just accrued to me that it would be possible to keep your old peers (ax86:wg21 and ac86:wg11) for internet access but if you port-forward via site2site you will end up with reverse-path filtering issues as packages are not replied the same route as the original packages.

Hopefully the passthru feature of wgm allows for adding remote side lan clients, or, if not, maybee we could suggest this as a possible future feature to @Martineau

Altough the remote side setup for redirecting internet access on a site2site is abit clunky. It gets somewhat complex as you have 3 options for accessing internet: siteA:WAN, siteA:VPN, siteB:WAN. So on siteB you need policy rules (manual) for which clients to route internet to siteA and on siteA you need policy rules to route which clients to VPN and which to WAN, and these could now include siteB ips (if these ips internet are routed over the site2site tunnel).
Adding DNS redirect on top of this, prefferably siteB clients that routes internet over the tunnel should also redirect dns to the other side of the tunnel, siteA: wg22 ip. Then siteA passthru redirect to vpn dns.

Imagine adding dual-stack on top of this... what a mess!

 

[Billy Chaney]

How do you use the vx command to edit wg11.conf file. It seems whenever I use vx wg11 it only allows me to view. I would like to add a permanent KILLSWITCH.

 

[ZebMcKayhan]

How do you use the vx command to edit wg11.conf file. It seems whenever I use vx wg11 it only allows me to view. I would like to add a permanent KILLSWITCH.

The command vx is not used with any parameters. Just:

E:Option ==> vx

And press Enter.
This should open a text editor with the current (global) config file, and allow you to make changes.
https://github.com/ZebMcKayhan/WireguardManager/blob/main/README.md#manage-killswitch

The killswitch is in global config, not wg11.conf.

Wg11.conf is not really used any more after it is imported but if you want to add custom script (like your own implementation of the kill-switch) that executes when wg11 starts, you could create a file here, with this name:

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

And also another is executed when wg11 is stopped:

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

Dont forget to make them executable when you are done.

 

[Billy Chaney]

The command vx is not used with any parameters. Just:

E:Option ==> vx

And press Enter.
This should open a text editor with the current (global) config file, and allow you to make changes.
https://github.com/ZebMcKayhan/WireguardManager/blob/main/README.md#manage-killswitch

The killswitch is in global config, not wg11.conf.

Wg11.conf is not really used any more after it is imported but if you want to add custom script (like your own implementation of the kill-switch) that executes when wg11 starts, you could create a file here, with this name:

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

And also another is executed when wg11 is stopped:

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

Dont forget to make them executable when you are done.

Yeah I got it. I'm a little dense sometimes. Thank you for your help with this.

 

[evlo]

the 500mbit limit is for wire guard connections or having this installed or having connection using WG will limit my WAN speed to 500mbps?

should web ui work? For me clicking anything apart from import config does not do anything, also version etc is not even filled
this is how it looks for me

 

[juanantonio]

How are you progressing?

Just accrued to me that it would be possible to keep your old peers (ax86:wg21 and ac86:wg11) for internet access but if you port-forward via site2site you will end up with reverse-path filtering issues as packages are not replied the same route as the original packages.

Hopefully the passthru feature of wgm allows for adding remote side lan clients, or, if not, maybee we could suggest this as a possible future feature to @Martineau

Altough the remote side setup for redirecting internet access on a site2site is abit clunky. It gets somewhat complex as you have 3 options for accessing internet: siteA:WAN, siteA:VPN, siteB:WAN. So on siteB you need policy rules (manual) for which clients to route internet to siteA and on siteA you need policy rules to route which clients to VPN and which to WAN, and these could now include siteB ips (if these ips internet are routed over the site2site tunnel).
Adding DNS redirect on top of this, prefferably siteB clients that routes internet over the tunnel should also redirect dns to the other side of the tunnel, siteA: wg22 ip. Then siteA passthru redirect to vpn dns.

Imagine adding dual-stack on top of this... what a mess!

I was working yesterday on all that stuff of routing between siteA and siteB from siteB, which is >60km from siteA when I mispelled a command and I lost completely the connection with this siteA, so for the moment I cannot progress anymore.

I expect to return next week to the city, so I'll have the opportunity of reconfigure my main router and perhaps I will try to enable the site2site connection. I'm in doubt because the client-server scheme worked well with less configuration.

Lastly, I found that ddns was working in my siteB router, so I had ddns in both sides of the tunnel. The thing that confused me was that in network map it was showing a private IP as WAN, but I seeked in the log and I found that internally it was getting a public WAN IP.

Thanks for all. Now I think I'm going to restore my Wireguard client-server configuration, once I get acces to my main router and can restore it.

 

[ZebMcKayhan]

the 500mbit limit is for wire guard connections or having this installed or having connection using WG will limit my WAN speed to 500mbps?

Yes, you will limit all traffic since hw nat acceleration (FlowCache) needs to be turned off, usually.

Some select devices (AC86U and AX88U) could keep it on because they have a working package mark to disable hw acceleration for only wg package.

It has also been reported that some setups (site2site if I recall correctly) could still keep hw acceleration on without issues.

If you experience really poor speeds (1-5 Mb/s) and syslog filling up with blog mcast errors you will need to turn off flow cache, which could be done in wgm config. Use vx command in wgm to edit it.