[Feature Request] WireGuard server: Endpoint for each peers

Technical Support for Routers VPN, DNS, Leaks
1

Currently, gl-sdk4-wg-server doesn't allow to having endpoint for each peers, and gl-sdk4-wg-client doesn't allow multiple instances(actually those are two different instances though).

If each peers can have own endpoint value:

  • WireGuard "Server" can acts as both server and client(Actually WireGuard itself doesn't distinguish between the two by design)
  • WireGuard "Client"(menu item name) can be used for another purpose and cascading
  • Dependancy-less mesh configuration is possible(Requires simple additional settings for both routes and keys, but would be so much useful especially for lowend models like MT300N-V2 which doesn't capable to install and use other solutions like Tailscale)

This is a different issue but I found that many people requested many times for multiple instances, like this: WireGuard and GL-AXT1800 (Two WireGuard connections at the same time)

Having own endpoint for peers might be a simpler workaround when two or more "client" connection is needed(If a single interface address is allowed at multiple servers, it will be more efficient than using multiple instances, and at least it can be an alternative for two "client" instances).

2

Thanks, we're raising priority to support wireguard multi-instance.
Do you mean creating two wireguard servers, for example, one listening on 51820, the other listen on 51821? Could you elaborate the requirements and gain?

2 Likes
4

That's a good news! Thank you for your feedback.

Anyway. What you said is "multiple interfaces", and what I said is literally "endpoint for each peers".

[Interface]
PrivateKey = ...
Address = 10.0.1.1/22
ListenPort = 51820

[Peer]
PublicKey = ...
AllowedIPs = 192.168.11.0/24, 10.0.0.0/22
Endpoint = xxa1a1a.glddns.com:51820
PersistentKeepalive = 25

[Peer]
PublicKey = ...
AllowedIPs = 192.168.22.0/24, 10.0.0.0/22
Endpoint = xxb2b2b.glddns.com:51820
PersistentKeepalive = 25

[Peer]
PublicKey = ...
AllowedIPs = 192.168.33.0/24, 10.0.0.0/22
Endpoint = xxc3c3c.glddns.com:51820
PersistentKeepalive = 25

[Peer]
PublicKey = ...
AllowedIPs = 192.168.44.0/24, 10.0.0.0/22
Endpoint = xxd4d4d.glddns.com:51820
PersistentKeepalive = 25

[Peer]
PublicKey = ...
AllowedIPs = 10.0.0.111/32
PersistentKeepalive = 25

[Peer]
PublicKey = ...
AllowedIPs = 10.0.0.222/32
PersistentKeepalive = 25

By configurations like this,

  • A single interface is act as a server and 4 clients at the same time.
  • Any of WG client devices are able to access every private network regardless of its endpoint(server).
  • More efficient and robust thanks to its "mesh" structure
2 Likes
5

This reminds me kinda on the kind of setup mullvad also shows on their blog on openwrt.

I like this idea :+1:, currently on openwrt with this setup it is not easy to have such peer talk on its own specific interface (the opposite what blog suggests, but still about the mesh part).

to accomplish you have to re-create the same interface with the same private key with the different peer in the section, so you can have wgclient1 (with a bunch of dutch peers), wgclient2(with a bunch of other country peers).

in openwrt itself that feels less inuititve for me, you really get the idea the more mesh approach looked like a last moment thought in luci atleast for me :yum:, when i first tried to use it that way i was worried that it would fail to work tbh due to the two instances with the same private key.

I hope this can also be expanded on from OP suggestion.

1 Like
6

@hansome There are more reasons why this feature is important.

As it's now, if only one(so-called "client") peer has the endpoint information of the other(so-called "server") peer, then when the "connection" is lost, they cannot communicate with each other by WG interface until the "client" peer tries to "connect" to the "server" again.

Currently, even if a device directly connected to the "client" router tries to access an IP address which has to be routed through the WG interface, it does not immediately try to "handshake" again, but has to wait at least a few seconds, usually tens of seconds, up to minutes. For me it happens mostly when the routing or peer config of the WG instance has changed and this is so annoying.

So though the WireGuard is connection-less and basically peer-to-peer(therefore the words in quotes above are actually unnecessary concepts in WG), current limitation makes it relies on "connections" and "handshakes", like other VPN protocols do.

However,

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.

All each peer needs is a single UDP port open on a public IP address(no matter it's static or dynamic, and generally DDNS to DDNS would also be fine).

7

I doubt this is possible because it's simply not how VPN works. There are always servers and clients.

2 Likes
8

Wow. I can't believe that you believe like that.
I wonder how you can be so sure. And I'm sorry but I don't know where to begin to explain for you what the WireGuard is...

Let me ask a few.

  • Have you ever have any experience configuring WireGuard by yourself?
  • If so, where was the concept of server and client in the configuration?
  • Was there really any difference other than not specifying the endpoint?
9

The main issue is that the endpoint is mostly dynamic because normal people don't have static IPs.

And it will add complexity which isn't really useful. My personal thought: People use VPN providers or road warrior - but side to side is not a usecase that is needed often.

So yeah, WireGuard does not rely on a strict server-client model. But at the end the topology is server-client…

2 Likes
10

Wow again. I don't know why I have to hear such. This is very surprising.

11

Would this feature support a client side WG tunnel failover scenario?

Client A has tunnels to FlintA (Primary Active) and FlintB (Secondary Standby)

Thanks

12

So you don't like opinions or what are you complaining about? :sweat_smile:

Since I am no GL staff … my opinion is just a personal one.

13

add complexity which isn't really useful

People use VPN providers or road warrior

side to side is not a usecase that is needed often

I'm really sorry but I don't want waste my time by talking nonsense with an inexperienced and narrow-minded amature.

Since I am no GL staff … my opinion is just a personal one.

Of course I know. That's exactly the point why I don't know why I have to hear such from you.

So you don't like opinions or what are you complaining about? :sweat_smile:

You keep saying things that aren't true as if they were facts, and you're just saying it's an opinion?

I doubt this is possible because it's simply not how VPN works. There are always servers and clients.

mostly dynamic because normal people don't have static IPs

Did you read what I wrote? I said, "no matter it's static or dynamic, and generally DDNS to DDNS would also be fine". Yes most people don't have static IP addresses. So what? I already said that would be fine, but what's wrong with you?

Please don't pay attention to this topic anymore. I beg you.

14

And how to handle CGNAT then?

1 Like
15

You have to admit your wrongnesses first. Why are you keep avoiding? And you keep harassing me by saying the wrong thing. I already beg you to stop it. Enough.

16

It's not about wrongness, it's about the use case.

You are right. WireGuard does not care about a server <-> client concept. But this doesn't matter based on the use case. I read many posts & topics here and would say that it's a fact that side-to-side VPN isn't pretty common. Happens sporadically, but not that often.

Mostly the people will use a road warrior design (yep, even with CGNAT or, more terrible DPI from hotels), which would make a reverse initiation of the VPN connection just useless and even one more point of failure, speaking of wrong configuration and stuff that needs to be checked as well.

The "not server, not client" concept isn't new, either. IPSec was capable of this as well. But without a S2S VPN, it simply isn't useful.

Since you rely on your use-case, which is fine, can't you just add the necessary parameters to your config manually?

1 Like
17

Hey Quidn,

You are out of order. You should not call admon names and I will ask the moderators to ban you if you continue to be abusive.

Furthermore admon is not "inexperienced" or a "narrow-minded amature"

admon has a great depth of knowledge and helps many many people on this forum. Check out his previous posts for proof.

Let's have a civil discussion.

18

Wrongness list:

I doubt this is possible

Actually this is not a very wrongness, but you don't have to say like that about what you don't know. Don't doubt. It can be simply done by manual config, as my example above.

it's simply not how VPN works.

You said "simply not" without any exception, but now saying "about the use case"? That's simply not how humans communicate. Do you know what exactly the concept of VPN and how it works technically?

There are always servers and clients.

Always? Oh no. Always means always. You excluded any exceptions at the first. But again, now saying "use case"? Seriously?

The main issue is that the endpoint is mostly dynamic because normal people don't have static IPs.

Do you think it wasn't your wrongness? Why are you saying about static/dynamic even I clearly said that dynamic addresses are fine? What the hell is the problem with you? Why you distorting the truth by saying "not about wrongness"?
You had to read my post first. I'm really curious whether you didn't read my post, or whether you read but couldn't understand.

People use VPN providers or road warrior - but side to side is not a usecase that is needed often.

Even though you said it's your personal thought, but you're speaking as if it were an established fact. That's the point that pointed as being narrow-minded. You may consider that most people use like that, but saying like that based on your limited experience might be inappropriate.

So yeah, WireGuard does not rely on a strict server-client model.

Wrong. You said "not rely on a strict server-client model" but it's distorting the truth. The truth is, not just "strict" but not at all a server-client model. It's literally peer-to-peer by design. Even a road-warrior setup, technically it's different from "a strict server-client model" and also "a strict peer-to-peer model". This is an example of technically proper usage of "strict".
https://www.wireguard.com/papers/wireguard.pdf

But at the end the topology is server-client

...only in the use cases you usually imagine. Saying like that is inappropriate.

And how to handle CGNAT then?

Why you asking like this rather than admit? At the first, I said "All each peer needs is a single UDP port open on a public IP address". Did you needed to ask because you can't understand what it means? If not, don't say that off-topic nonsense. Since a public IP address was prerequisite, asking that could be interpreted as an attempt to start and keep a meaningless arguments.

I read many posts & topics here and would say that it's a fact that side-to-side VPN isn't pretty common

So what? What are you expecting from saying that? That seems so awesome for you...?
If it's not common in this forum, are you allowed to just spit out opinions that it doesn't needed it? So narrow-minded.
You don't understand that most people using site-to-site usually don't need any support. Even if someone posting bug report or feature request, experts don't need to explain all the environment and configs in detail. Can't you do some sort of think that what kind of people would post on this forum? Again, I can't believe you believe like that.

it's a fact that side-to-side VPN isn't pretty common

In this forum? Yes maybe. But in fact? You can't say so sure like that.
If that's the truth, why do you think GL.iNet created automatic site-to-site feature in GoodCloud, even it's "not pretty common" and therefore would be barely used? You don't have any idea how network equipment vendors do business.
You keep saying "side-to-side"... I'm pretty sure that you don't know what exactly the site-to-site VPN is.

Mostly the people will use a road warrior design

So what? Regardless of whether that's true or not, do you believe that you have some privilege to reject minorities by so-called opinion?

The "not server, not client" concept isn't new, either

So what? Who said that's so new? Why you keep saying off-topic?

But without a S2S VPN, it simply isn't useful.

I can't believe that you with this level of thinking can be so confident and so sure. You don't know how WireGuard is used in the industry at all. This is pretty surprising experience.

can't you just add the necessary parameters to your config manually?

This is a ridiculously inappropriate to say to a "feature request". If so, then any feature requests are unnecessary since anything is possible with root privilege.
Moreover, you said "I doubt this is possible" at the first, but now saying "can't you just add the necessary parameters to your config manually"? Why are you harassing me like this? You keep changing your words and don't admit anything. Stop spouting sophistry to cover your ignorance.

If you really think you weren't wrong, then I have nothing to say anymore.

And I really wonder why you keep pay attention to this topic. Please stop it and don't do like this ever.

19

Don't post off-topic and use DM if you want, as the Community Guidelines.

20

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.
The VPN policy is mostly for client.

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

3 Likes
21

Also please finally add multiple WG Client support too.