Routing packets through a wireguard client

[dacid44]

This might just be an iptables thing, but I can't figure it out.

Short version: I'm trying to forward packets from a VPS to the router over wireguard (router is client) and forward them to the correct device on the LAN.

I have a setup that I'm trying to carry over from my old DD-WRT router where I have the router connect to a Wireguard server running on a VPS, so that even when my router is behind a NAT (e.g., on a university dorm network), or the WAN settings change, I can expose ports to the internet through the VPS (for example, if I run a Minecraft server, I can give someone the ip of the VPS, and it will forward the connection through the wireguard tunnel to the router, which will forward it to my PC).

I am trying to replicate this setup using ASUSwrt-Merlin, and I'm stuck. I have a Wireguard connection set up, and I can tell that they are connected by running the wg command on both ends. In addition, pinging the router or my PC from the VPS while running tcpdump on the router's wgc1 interface shows the incoming packets, as do LOG entries in the iptables PREROUTING chain on the raw table. However, none of the packets as far as I can tell ever make it to iptables filters or nat rules, as logging all packets with the filter -i wgc1 on the FORWARD or INPUT chains, or the INPUT chain on the nat table doesn't show anything.

I have also noticed, however, that I'm unable to ping the wireguard server from the router. (or, I can, but it's going through my old router which the new one is plugged into). I'm not sure why this is, either, but solving it may be the first step in fixing my main issue. running ip route shows no route for the wireguard tunnel's subnet.

The wireguard configuration is, as far as I can tell, exactly the same as the one on the old DD-WRT router, and as far as I can tell, all the iptables rules are correct, but I am way less sure of that. Any ideas what might be the problem here?

Router model: ASUS RT-AX86U
Firmware version: ASUSwrt-Merlin release 3004.388.4
LAN subnet: 192.168.50.1/24
Wireguard subnet: 192.168.5.1/24 (server is 192.168.5.1, router is 192.168.5.50)
I've tried with NAT both on and off, as well as with a VPN Director rule for wgc1 with remote IP 192.168.5.0/24.

I can post logs or other configuration files too if it helps. I'm pretty sure the VPS end is not the problem, as the configuration is exactly the same as what's been running with the DD-WRT router for ~3 years now. I'm certainly not ruling it out, though.

Thanks in advance!

 

[ZebMcKayhan]

This might just be an iptables thing, but I can't figure it out.

Short version: I'm trying to forward packets from a VPS to the router over wireguard (router is client) and forward them to the correct device on the LAN.

I have a setup that I'm trying to carry over from my old DD-WRT router where I have the router connect to a Wireguard server running on a VPS, so that even when my router is behind a NAT (e.g., on a university dorm network), or the WAN settings change, I can expose ports to the internet through the VPS (for example, if I run a Minecraft server, I can give someone the ip of the VPS, and it will forward the connection through the wireguard tunnel to the router, which will forward it to my PC).

I am trying to replicate this setup using ASUSwrt-Merlin, and I'm stuck. I have a Wireguard connection set up, and I can tell that they are connected by running the wg command on both ends. In addition, pinging the router or my PC from the VPS while running tcpdump on the router's wgc1 interface shows the incoming packets, as do LOG entries in the iptables PREROUTING chain on the raw table. However, none of the packets as far as I can tell ever make it to iptables filters or nat rules, as logging all packets with the filter -i wgc1 on the FORWARD or INPUT chains, or the INPUT chain on the nat table doesn't show anything.

I have also noticed, however, that I'm unable to ping the wireguard server from the router. (or, I can, but it's going through my old router which the new one is plugged into). I'm not sure why this is, either, but solving it may be the first step in fixing my main issue. running ip route shows no route for the wireguard tunnel's subnet.

The wireguard configuration is, as far as I can tell, exactly the same as the one on the old DD-WRT router, and as far as I can tell, all the iptables rules are correct, but I am way less sure of that. Any ideas what might be the problem here?

Router model: ASUS RT-AX86U
Firmware version: ASUSwrt-Merlin release 3004.388.4
LAN subnet: 192.168.50.1/24
Wireguard subnet: 192.168.5.1/24 (server is 192.168.5.1, router is 192.168.5.50)
I've tried with NAT both on and off, as well as with a VPN Director rule for wgc1 with remote IP 192.168.5.0/24.

View attachment 52591

I can post logs or other configuration files too if it helps. I'm pretty sure the VPS end is not the problem, as the configuration is exactly the same as what's been running with the DD-WRT router for ~3 years now. I'm certainly not ruling it out, though.

Thanks in advance!

Your problem probably lies in AllowedIPs and/or VPNDirector (which is required for WG Client setups).... if you did not add any VPNDirector rules your packets will be blocked by rp-filter in the router.

I'm running a similar setup which was initially setup using Wireguard Manager where site2site setups uses servers on both sides. my initial setup is described here: https://github.com/ZebMcKayhan/WireguardManager#setup-private-server-via-cloud-server

I later migrated the setup from Wireguard Manager to firmware Wireguard implementation but I kept on using a server, described here https://www.snbforums.com/threads/wireguard-server-tweaks.85758/ everything worked immedately, and is still working. I can access all my local LAN resources by connecting to the VPS and it will relay all data to my LAN (and back).

I would recommend you save yourself some grief and use a server peer for this purpose as it will make all routes end up in main routing table and access will be granted to LAN, to dnsmasq (for DNS lookup) a.s.o.

 

[ZebMcKayhan]

I have a setup that I'm trying to carry over from my old DD-WRT router where I have the router connect to a Wireguard server running on a VPS, so that even when my router is behind a NAT (e.g., on a university dorm network), or the WAN settings change, I can expose ports to the internet through the VPS (for example, if I run a Minecraft server, I can give someone the ip of the VPS, and it will forward the connection through the wireguard tunnel to the router, which will forward it to my PC).

Ive been giving this some thought and Im still alittle confused about how you made this work before.

So a packet from a.b.c.d with dport n arrives at the vps. So the vps recognize port n and redirect (PREROUTING, DNAT) this packet to a local address 192.168.50.x and allows this to be forwarded (FORWARD, ALLOW). the VPS knows, via AllowedIPs that this ip is reached over vpn. So off it goes to your router and pops out of the wireguard interface.
So, one of the earlier things the router does is that it changes place on src and dst ip and runs through routing, to figure out if a reply to this packet would be routed out the same interface. If not, the packet is dropped.

So if you dont route your lan internet data via your vps, how will the router know to send the reply to this internet packet to the vps, instead of the normal path for internet destinations? It is possible to setup like this using conntrack, but its not there by default. You can turn off rp-filter to skip this check, but it still wont work since the reply doesnt find its way back through the same interface.

I dont know if this is treated differently in DD-wrt and/or this is the reason for your issues.

I dont really se any better way then to masquarade (POSTROUTING) the forwarded packets at the VPS so all packets appear to come from there. Ofcource the technically best solution would be to setup a packet mark scheme using connmark and restore mark together with mark based routing rules so conntrack is marking all packets belong to certain connections which then transfers to fwmark for routing.

Perhaps you could provide more information on how you intended this to work?

 

[Jeffrey Young]

Just to dig deeper on @ZebMcKayhan comments, are you trying to limit your setup so that inbound traffic to your VPS, on a specific port, is only forwarded to a internal IP on your private network? Or are you simply wanting to reach your internal network?

I too have a similar setup as you. I use a VPS as a reverse proxy into my internal network as my home router is behind a CGNAT. That means the VPS must be able to talk to all machines in my internal network.

I don't use Asus's wireguard GUI. It is a good start, but it is not configurable enough. I use my own simple scripts that I call from wan-event script. Indeed, I believe you are missing some routing information as well as port forwarding info. If I think about it on Sunday when I am home, I can post my setup. I have posted elsewhere here on SNB, but I forget where. If I can find the post, I will point you to it.

If you use Entware, you could look at Wireguard-Manager.

 

[Jeffrey Young]

Here is a client config I use on my router to allow traffic inbound to my VPS to reach my internal network.

Is wireguard available on RT-AC86U ?

Ive seen some posts about wireguard around the forums but just wondered if it's usable on RT-AC86U. i'm currently running asus merlin on firmware 386.4

www.snbforums.com

 

[dacid44]

Your problem probably lies in AllowedIPs and/or VPNDirector (which is required for WG Client setups).... if you did not add any VPNDirector rules your packets will be blocked by rp-filter in the router.

I'm running a similar setup which was initially setup using Wireguard Manager where site2site setups uses servers on both sides. my initial setup is described here: https://github.com/ZebMcKayhan/WireguardManager#setup-private-server-via-cloud-server

I later migrated the setup from Wireguard Manager to firmware Wireguard implementation but I kept on using a server, described here https://www.snbforums.com/threads/wireguard-server-tweaks.85758/ everything worked immedately, and is still working. I can access all my local LAN resources by connecting to the VPS and it will relay all data to my LAN (and back).

I would recommend you save yourself some grief and use a server peer for this purpose as it will make all routes end up in main routing table and access will be granted to LAN, to dnsmasq (for DNS lookup) a.s.o.

I seem to be misunderstanding what VPNDirector is doing then. I had assumed that it specifies what outbound requests from the LAN get routed through the tunnel instead of the WAN. How would I configure it to allow inbound requests? Or did you just mean that if the router can't send packets back to where they came from, it will block them? I did also try a rule with 192.168.5.1/24 as external IP and that did not allow me to ping the Wireguard server either. What rules should I try to get this to work (either inbound or outgoing requests)?

As for using a server instead of the client, the main reason I use this setup is so that the router can link to the VPS even when the router is behind another NAT which I don't control, like a university dorm network, so it's not possible for the VPS to reach the router, hence the Wireguard server being on the VPS, which is exposed to the internet.

Ive been giving this some thought and Im still alittle confused about how you made this work before.

So a packet from a.b.c.d with dport n arrives at the vps. So the vps recognize port n and redirect (PREROUTING, DNAT) this packet to a local address 192.168.50.x and allows this to be forwarded (FORWARD, ALLOW). the VPS knows, via AllowedIPs that this ip is reached over vpn. So off it goes to your router and pops out of the wireguard interface.
So, one of the earlier things the router does is that it changes place on src and dst ip and runs through routing, to figure out if a reply to this packet would be routed out the same interface. If not, the packet is dropped.

So if you dont route your lan internet data via your vps, how will the router know to send the reply to this internet packet to the vps, instead of the normal path for internet destinations? It is possible to setup like this using conntrack, but its not there by default. You can turn off rp-filter to skip this check, but it still wont work since the reply doesnt find its way back through the same interface.

I dont know if this is treated differently in DD-wrt and/or this is the reason for your issues.

I dont really se any better way then to masquarade (POSTROUTING) the forwarded packets at the VPS so all packets appear to come from there. Ofcource the technically best solution would be to setup a packet mark scheme using connmark and restore mark together with mark based routing rules so conntrack is marking all packets belong to certain connections which then transfers to fwmark for routing.

Perhaps you could provide more information on how you intended this to work?

MASQUERADE from the VPS is in fact how I'm making this work:

user@vps:~$ sudo iptables -t nat -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -o wg0 -j MASQUERADE
-A POSTROUTING -o ens4 -j MASQUERADE

I also have my PostUp of the wireguard server config set to explicitly add routes for the wireguard clients:

[Interface]
Address = 192.168.5.1
PrivateKey = <nope>
ListenPort = 1336
PostUp = ip route replace 192.168.5.2 via 192.168.5.1; ip route replace 192.168.4.0/24 via 192.168.5.1; ip route replace 192.168.5.50 via 192.168.5.1; ip route replace 192.168.50.0/24 via 192.168.5.1

I'm not sure how necessary this actually is, especially for the direct wireguard clients themselves, but I seem to remember it not working without these rules (I set this up about 3 years ago).

Conceptually, the VPS is acting like a reverse proxy, but for any network packets. Port forwarding is handled through separate iptables scripts on the VPS (10.128.x.x is the address of the VPS, it's behind another NAT and firewall which I can't figure out how to remove, thanks Google cloud, but it works anyway, since at least I control the port forwarding on that NAT, and 192.168.4.0/24 is the subnet of my old router, that will change to 192.168.50.0/24 once I have this system set up):

iptables -A PREROUTING -t nat -p tcp -m tcp -d 10.128.0.6 --dport $2 -j DNAT --to-destination 192.168.4.2:$1
iptables -A FORWARD -m state -p tcp -d 192.168.4.2 --dport $1 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -p tcp -m tcp -s 192.168.4.2 --sport $1 -j SNAT --to-source 10.128.0.6

iptables -A PREROUTING -t nat -p udp -m udp -d 10.128.0.6 --dport $2 -j DNAT --to-destination 192.168.4.2:$1
iptables -A FORWARD -m state -p udp -d 192.168.4.2 --dport $1 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -p udp -m udp -s 192.168.4.2 --sport $1 -j SNAT --to-source 10.128.0.6

echo $1 > .custom-mc-port

However, that should only be needed for a connection being forwarded from the internet, the DNAT and SNAT rules shouldn't be needed for a ping or http connection (which I've also tried) coming directly from the VPS itself, which is also not working. I can ping the old router and devices on its LAN, but not the new one.

Just to dig deeper on @ZebMcKayhan comments, are you trying to limit your setup so that inbound traffic to your VPS, on a specific port, is only forwarded to a internal IP on your private network? Or are you simply wanting to reach your internal network?

I too have a similar setup as you. I use a VPS as a reverse proxy into my internal network as my home router is behind a CGNAT. That means the VPS must be able to talk to all machines in my internal network.

I don't use Asus's wireguard GUI. It is a good start, but it is not configurable enough. I use my own simple scripts that I call from wan-event script. Indeed, I believe you are missing some routing information as well as port forwarding info. If I think about it on Sunday when I am home, I can post my setup. I have posted elsewhere here on SNB, but I forget where. If I can find the post, I will point you to it.

If you use Entware, you could look at Wireguard-Manager.

I'm fine with using scripts. I looked at wireguard-manager, but it appears to just be a different way to get the same wireguard client set up, I expect I would probably need to add my own rules in a script either way.

Here is a client config I use on my router to allow traffic inbound to my VPS to reach my internal network.

Is wireguard available on RT-AC86U ?

Ive seen some posts about wireguard around the forums but just wondered if it's usable on RT-AC86U. i'm currently running asus merlin on firmware 386.4

www.snbforums.com

This came in as I was writing this reply. I'll have a look at it and post again here if I can glean anything from it for my situation.


SMALL EDIT: I think the most likely cause is the router dropping the packets because it doesn't see a route back to 192.168.5.1/32. I'll look a bit more into how to fix that, either through VPN Director or my own script, though insight on how to use VPN Director to fix this would be appreciated, since my attempt (no internal IP, external IP 192.168.5.0/24, set for wgc1) didn't work. As you can see on the screenshot above, the AllowedIPs on the wireguard client is also set to 192.168.5.1/24, which as far as I know should be correct, but if that's wrong, please tell me.

ANOTHER SMALL EDIT: Any ideas why the wireguard client has to manually be reconnected every time the router reboots? I always have to go into the GUI and hit apply on the wireguard client page.

Thanks everyone for the insights! At the very least, I'm learning a lot more about iptables from this, lol. (Most of the stuff above was originally trial and error, but I think I've been working on this long enough now to actually understand what it's doing.)

 

[dacid44]

I SOLVED IT!

I was looking through ip a and ip route, and realized that the problem was in the default subnet of the wireguard interface. In DD-WRT, this was my configuration:

The interface IP address is set to 192.168.5.2, and it explicitly asks for a subnet.

In ASUSwrt-Merlin, however:

There's no box for a subnet, and so if you don't specify one in CIDR notation, it assumes /32. However, I wanted /24. Here's the fix:

That's why the router couldn't find a route back to 192.168.5.1: it didn't know that addresses other than 1902.168.5.50 existed and were accessible on that interface. After the change, the ip route listing is there too:

dacid44@spacerig17:/tmp/home/root# ip route
default via 192.168.4.1 dev eth0
127.0.0.0/8 dev lo scope link
192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.133
192.168.4.1 dev eth0 proto kernel scope link
192.168.5.0/24 dev wgc1 proto kernel scope link src 192.168.5.50
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
239.0.0.0/8 dev br0 scope link

Thanks again everyone for the insights, especially about rp-filter, that helped me find this. No special scripts needed after all, it seems. I can now ping any device on the router's LAN from the VPS. Port forwarding from the internet works too.

If anyone would like more info on how this setup works, feel free to ask!

 

[ZebMcKayhan]

VPNDirector is doing then. I had assumed that it specifies what outbound requests from the LAN get routed through the tunnel instead of the WAN.

Both yes and no. The routes for wg is setup in a separate routing table together with a snapshot of the main routing table, no wg rules in the main table. In VpnDirector you setup rules for which local (source ip) or remote (destination ip) that should use this new routing table.
Wg puts in routing rules based on AllowedIPs in the peer, which in your case should be 192.168.5.0/24 and possibly 10.128.0.0/24

How would I configure it to allow inbound requests?

VpnDirector only works on routing, it wont deny or allow anything. In your case it should be local ip left blank, remote ip: 192.168.5.0/24, iface wgc1.
And possibly a duplicate rule for 10.128.0.0/24.
Without these rules no resource will find any routes to your vps, since no one is using this routing table.

As for using a server instead of the client, the main reason I use this setup is so that the router can link to the VPS even when the router is behind another NAT which I don't control, like a university dorm network, so it's not possible for the VPS to reach the router, hence the Wireguard server being on the VPS, which is exposed to the internet.

Wireguard is neither server or client, that is a construct of the fw. Surely a server peer can connect out, you just need to provide the endpoint. Look at the links I sent you. My server connects out to the vps as Im also behind cgnat.

MASQUERADE from the VPS is in fact how I'm making this work:

Alright, that should work then.

I also have my PostUp of the wireguard server config set to explicitly add routes for the wireguard clients:

I have never seen this solution before. Wg-quick setup routes based on AllowedIPs so this should not be nessisary. On the vps wg config, each peer should have AllowedIPs set to All destinations on that peer, so, for this peer it should be: 192.168.5.50/32, 192.168.50.0/24.

Anyhow, glad you got it working!

Out of curiosity, did your routes end up in the main routing table?? So you never needed to add vpndirector rules? Hmm, maybe this has changed in the firmware to only apply to 0.0.0.0/0 rules...

Ooh, I see... the kernel adds the interface routes to the main table. But any additional routes in AllowedIPs are only in policy table. But since there are no additional routes it works!

If you, for example, were to add 10.128.0.0/24 to AllowedIPs to be able to ping vps via this ip or if you i.e want 8.8.8.8 dns lookup via vps, you would need to handle this differently, via vpndirector.

 

[dacid44]

Wireguard is neither server or client, that is a construct of the fw. Surely a server peer can connect out, you just need to provide the endpoint. Look at the links I sent you. My server connects out to the vps as Im also behind cgnat.

So the firmware has its own definition of server or client? Huh. By server or client I'd just meant which end of the wireguard tunnel listens, and which one connects (e.g., server listens for incoming connections, client has an endpoint specified and connects to a listening server) as that's what I've seen in documentation before (https://www.stavros.io/posts/how-to-configure-wireguard/ is the page I've seen explain Wireguard best for me), and I've never seen them mixed before, it never occured to me that a peer could connect to other peers but also listen for incoming peers. I was operating under the assumption that "server" and "client" via the firmware used this same definition. DD-WRT doesn't make a distinction, in fact it even puts Wireguard options separately under "tunnels" instead of under "VPN". The client does seem to work fine though.

I have never seen this solution before. Wg-quick setup routes based on AllowedIPs so this should not be nessisary. On the vps wg config, each peer should have AllowedIPs set to All destinations on that peer, so, for this peer it should be: 192.168.5.50/32, 192.168.50.0/24.

Again, I'm not sure it is necessary. It's likely redundant, something I added while debugging this solution when I first set it up. I might remove those lines and see if it still works, but I'm inclined to not fix what isn't broken.

Out of curiosity, did your routes end up in the main routing table?? So you never needed to add vpndirector rules? Hmm, maybe this has changed in the firmware to only apply to 0.0.0.0/0 rules...

I'm not sure exactly what you mean by "main routing table", but it shows up in ip route (the 192.168.5.0/24 rule):

dacid44@spacerig17:/tmp/home/root# ip route
default via 192.168.4.1 dev eth0
127.0.0.0/8 dev lo scope link
192.168.4.0/24 dev eth0 proto kernel scope link src 192.168.4.133
192.168.4.1 dev eth0 proto kernel scope link
192.168.5.0/24 dev wgc1 proto kernel scope link src 192.168.5.50
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
239.0.0.0/8 dev br0 scope link

And in the routing table in the GUI:

And no, I never added any VPNDirector rules (at least for the final setup). This is (as far as I can remember) all of the configuration that I've done on the router side:

Last thing though-any idea why the wireguard client needs to be manually started on every reboot? Or how I might fix that? Does a server peer-based setup have the same issue?

And thanks again for all your help!

 

[ZebMcKayhan]

So the firmware has its own definition of server or client? Huh. By server or client I'd just meant which end of the wireguard tunnel listens, and which one connects (e.g., server listens for incoming connections, client has an endpoint specified and connects to a listening server)

Wireguard does not have any of this buildt in. The firmware makes this so that it is easier for the user. Why have a server with an endpoint? The server typically does not attempt to connect to its clients. And a client typically does not open ports nor allow incoming connections through the firewall. So when the firmware setup a server it just implies it configures wireguard for a typical server with regards to setup firewall, listen ports and such. But for Wireguard, it is all peers. Everything connects to everything (or not). Some inspiration here https://github.com/ZebMcKayhan/WireguardManager#site-2-multisite--mesh

I'm not sure exactly what you mean by "main routing table", but it shows up in ip route (the 192.168.5.0/24 rule):

You have another routing table, try:

ip route show table wgc1

There you would find any additional routing rules from AllowedIPs.
But as you can see in

ip rule

No one is using this routing table since you did not put in any rules in vpndirector.
As you only need the wg network to go over vpn this works for you anyway, but the proper way would be to setup rules, or use a server peer.

Last thing though-any idea why the wireguard client needs to be manually started on every reboot? Or how I might fix that? Does a server peer-based setup have the same issue?

If its enabled it should autostart at boot. Check you syslog if there are any errors during boot to prevent it from starting.

 

[dacid44]

You have another routing table, try:

ip route show table wgc1

There you would find any additional routing rules from AllowedIPs.

The only difference I see here is that for some reason it's added a route to the VPS' endpoint address explicitly through the default gateway. e.g. <wg endpoint ip> via 192.168.4.1 dev eth0. I'd guess that's just to ensure that even if the wireguard tunnel is the default gateway, that the tunnel's connection itself goes through the normal WAN? I'd guess though that this would add additional rules if AllowedIPs were more than just the tunnel's own subnet.

Wireguard does not have any of this buildt in. The firmware makes this so that it is easier for the user.

Yes, but the router firmware is not the only place that uses "server"/"client" terminology with Wireguard. This terminology is used in other (admittedly, third-party) documentation that I've seen, as this appears to be how Wireguard is used in many common cases. I was only confused that the router firmware has a different treatment of client vs. server than just the single difference in Wireguard that the "client" has an endpoint specified and the "server" does not. I had assumed this was the only difference, but it seems like, as you've said, there is more that the router firmware handles differently between "client" and "server" than just this. If I need to do anything else with Wireguard (which I probably will), I'll look into what the other differences are, but as before, I'm not inclined to fix what isn't broken, so I'll probably keep the "client"-based setup that's working right now.

But as you can see in

ip rule

No one is using this routing table since you did not put in any rules in vpndirector.

dacid44@spacerig17:/tmp/home/root# ip rule
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

I haven't used ip rule before. Would the wgc1 table also have an entry here if added rules for it in VPN Director?

If its enabled it should autostart at boot. Check you syslog if there are any errors during boot to prevent it from starting.

I don't see anything related in the syslog. I see wg_manager stuff (I installed it, but didn't end up using it) but nothing related to wireguard that isn't also related to wg_manager, or anything mentioning wgc1. What would I be looking for? It seems like it's just not starting in the first place, rather than starting and then crashing for some reason.


Thanks again, by the way, for the opportunity to pick your brain about the routing stuff. I'm really interested in learning more about how low-level networking works. I'm taking a computer networks class in college this next semester, so maybe it'll be some review!

 

[ZebMcKayhan]

Yes, but the router firmware is not the only place that uses "server"/"client" terminology with Wireguard.

Yes, but all are constructs from whatever sw it is used on to aid the user in achieving the setup they want. Or backwards, lessen the user options needed from the user.

I haven't used ip rule before. Would the wgc1 table also have an entry here if added rules for it in VPN Director?

Yes, mine are:

admin@RT-AX86U_Pro:/tmp/home/root# ip rule
0:      from all lookup local
10010:  from all to 192.168.0.0/16 lookup main
11210:  from 192.168.128.0/24 lookup wgc1
11211:  from 192.168.100.0/24 lookup wgc1
32766:  from all lookup main
32767:  from all lookup default

I have 3 rules, one for iface wan that points to main routing table and 2 for wgc1

I don't see anything related in the syslog. I see wg_manager stuff (I installed it, but didn't end up using it) but nothing related to wireguard that isn't also related to wg_manager, or anything mentioning wgc1. What would I be looking for? It seems like it's just not starting in the first place, rather than starting and then crashing for some reason.

Wierd, what do you get from

nvram get wgc1_enable

?

 

[dacid44]

Yes, but all are constructs from whatever sw it is used on to aid the user in achieving the setup they want.

I meant more in terms of documentation. Many blog posts/wiki articles/etc walking through how to set up wireguard (using something like wg-quick, with conf files) use "client" vs "server". Either way, it's set up now, and I know that the firmware treats them differently.

Wierd, what do you get from

nvram get wgc1_enable

?

It returns 1. I did also find this article: https://www.snbforums.com/threads/wireguard-not-starting-on-reboot.83049/, but it doesn't really provide a solution. I did try adding a VPN Director rule, but that didn't help either. Based on that thread, it looks like it may be a bug. Is there maybe a way I can start it with a script as a workaround? I may also try switching to a server peer or running it through wg_manager if I can't find another solution.

 

[ZebMcKayhan]

there maybe a way I can start it with a script as a workaround?

You should be able to start it with command:

service start_wgc1

Test that manually first.

Then you may add it to some script hooked into the firmware: https://github.com/RMerl/asuswrt-merlin.ng/wiki/User-scripts
Something like wan-event (connected) and perhaps put in a delay so its not starting to early.

 

[dacid44]

You should be able to start it with command:

service start_wgc1

Test that manually first.

Odd, that doesn't seem to be working. The only logs are:

Aug 24 16:46:04 rc_service: service 19928:notify_rc start_wgc1
Aug 24 16:46:04 custom_script: Running /jffs/scripts/service-event (args: start wgc1)

 

[ZebMcKayhan]

Odd, that doesn't seem to be working. The only logs are:

Aug 24 16:46:04 rc_service: service 19928:notify_rc start_wgc1
Aug 24 16:46:04 custom_script: Running /jffs/scripts/service-event (args: start wgc1)

hmm... I wonder if wgc1 is in some odd state where the fw think it's enabled, so it wont start it again, but it's not fully enabled so it's not working. I guess this could happen if it i.e. starts too early in the boot process.

after a reboot when wg is not working, what is the output of:

nvram get wgc1_enable

wg show

make sure to obfuscate any keys, public ips you dont want to show.

perhaps it needs a restart rather than just start:

service restart_wgc1

at least I think this is the command, but you may also experiment with

service stop_wgc1
service start_wgc1