[Feature Request] WireGuard server: Endpoint for each peers

[hansome]

@Quidn

If both routers have the endpoint information of the other peer, then either side can just start communicating without having to try to make or wait for incoming a "connection". This also allows eliminating PersistentKeepalive which isn't necessary.

In early version, we have static listenport for wgclient, but users reported server becomes unreachable. Due to wireguard UDP could easily be blocked, so we removed the listenport, like the standard wireguard client app. hahaha.

@Quidn

For me it happens mostly when the routing or peer config of the WG instance has changed and this is so annoying.

Indeed, multiple-peer is very useful in this case.

[hansome]

Righty ok, we're developing multiple wg client/instance.

[mkdr]

You also need to add the following options then too:

• VPN Cascading needs a field where you select which WG Client to use WGClient1, WGClient2 and so on

• Maybe add it so that you have one master WGClient which is for all normal VPN traffic, also Cascading, and then add infinite slave WGClients, which are just for client to client router binding with custom routing options where you select the WGClient for each subnet to go through for the route, or same as for Cascading, add option where you select the "master WG Client" for all VPN traffic

[Quidn]

@hansome

Your idea is very creative—one wireguard interface as multiple "servers" and multiple "clients" - lightweight multifunctioning.
We can implement this in future firmware versions, maybe with a whole new package.

I think it's still good to distinguish between clients and servers.
We limit its role and trade off the possibility with ease of use.

Thank you for your opinion and share informations. You are right and I'm sure that it makes sense since it's consumer routers.

WG config UI of TP-Link Omada SDN controller is a good comparison. It's separated into just interfaces and peers, and multiple entries are allowed. I fully agree that kind of UI isn't suitable for consumer routers.

Anyway.
What I wanted wasn't that not to distinguish them. I'd like to suggest more specific.

• WireGuard Client
  Currently it's not possible to have multiple peers even I input them manually in the GL UI. Despite it seems like just reflects the WG config as is, but actually it ignores any other than the first peer, because the GL SDK parses it and omits unexpected like second peer, right?
  Allowing multiple peers doesn't need any UI change. Same UI, no confusion. Now it can be advertised as "WireGuard mesh config supported by default"!

• WireGuard Server
  Similar here. If the Client Configuration modal can have just one more field named "Endpoint (Optional)", it's done. I don't think this change could confusing even for beginners. Omada controller has an "optional" endpoint field as the screenshot above.

Please don't get me wrong. I'm not saying the both are need at the same time, nor to urging. I just mean, there won't be any considerable confusion.

By the way, even though I said their WG config UI isn't suitable to GL.iNet routers, if you haven't used it, I suggest you try it out for reference. Omada Cloud Essentials is completely free and you don't need any bound device to set site configs.

I don't like their UI but there's one exception and probably it's the only thing I really like there: LAN

---

@hansome

Multiple-instance is heavy but could also have its own firewall zone. We'll evaluate when develop though.

That'd be welcomed because many users don't have full control over IP addresses and keys. Even though "own endpoint for each peer" is my request, but the biggest catch is that one interface can only have one IP address and one key when up.

So if someone wants to connect to two or more VPN services, having multiple interface may almost essential. I don't need it at all but I'm sure that many users will.

Separated firewall zones would help to set not only ACLs but also SNATs, whether not to use NAT, etc for certain instance, so it would be interesting.

---

@hansome

@Quidn

If both routers have the endpoint information of the other peer, then either side can just start communicating without having to try to make or wait for incoming a "connection". This also allows eliminating PersistentKeepalive which isn't necessary.

In early version, we have static listenport for wgclient, but users reported server becomes unreachable. Due to wireguard UDP could easily be blocked, so we removed the listenport, like the standard wireguard client app. hahaha.

OMG NOOOO!!
Then, the difference between the "server" and the "client" instances was only whether allowed "multiple peers, no endpoints" or "one peer, with endpoint" at that time. lol

[hansome]

@Quidn

Currently it's not possible to have multiple peers even I input them manually in the GL UI. Despite it seems like just reflects the WG config as is, but actually it ignores any other than the first peer, because the GL SDK parses it and omits unexpected like second peer, right?

Yes, current code only parses the first peer, both the frontend and backend.

Thanks for the detailed description, great input.

[admon]

Offtopic posts were deleted, please stick to the topic.

[gw108]

I ran into a similar issue. But my router is a "client" not a "server" since it does not have a static IP address.

I want the router to connect to 2 (server) peers with different AllowedIP ranges. The first server is my public webserver that allows me to access some home stuff when I'm outside. The second server is for the typical "proxy" use-case but only for traffic to a specific country/region (with 8662 IP ranges), I don't want to update the default (global) route.

I ended up with a customized "fix up" script that runs periodically to update the config:

#!/bin/sh
IFNAME=wgclient
CONF_FILE=/tmp/wgclient.conf
wg showconf $IFNAME >$CONF_FILE 2>/dev/null
[[ $? != 0 ]] && exit
PEER_COUNT=$(fgrep '[Peer]' $CONF_FILE | wc -l)
[[ $PEER_COUNT -gt 1 ]] && exit
echo Updating WireGuard config
CONF_EXTRA_FILE=/etc/config/wireguard-extra/wg0.conf
cat $CONF_EXTRA_FILE >> $CONF_FILE
wg setconf $IFNAME $CONF_FILE
echo Updating route table
grep AllowedIPs $CONF_EXTRA_FILE | sed 's/.*=//;s/,/\n/g' | while read IP_RANGE; do
  ip route add $IP_RANGE dev $IFNAME
done

I put the extra peer's config in $CONF_EXTRA_FILE. The script checks if wgclient has multiple peers, if not, reload the config with the extra peers, then update the route table based on AllowedIPs. This seems to work well for me. I also noticed that the AllowedIPs would be too long for the stock wireguard GUI to handle.