*) wireguard - do not initiate handshake when peer is configured as responder;
Which is great, but I am confused about the wording in the documentation: (https://help.mikrotik.com/docs/display/ROS/WireGuard#WireGuard-Peers)
There seems to be an as-yet-undocumented change in 7.17 that renames ‘is-responder’ to ‘responder’, so I’ll just say responder.
I don’t understand which side’s peer is supposed to be set to responder. It seems like the roaming peer would be the “initiator”, since it is the one that always knows the servers endpoint-address, right? So the server’s peer entry on the roaming device should have responder=yes? Then how does that tell the server not to log failures to contact the roaming device at it’s last known endpoint-address? Maybe the server is the one that needs responder=yes on the roaming peer? It seems to me that the meaning of the terms are lost if that is the case.
I’m guessing it is the second one and the term responder actually refers not to the peer, but the device the configuration is on, even though it is in the peer configuration.
It would be nice to have it clarified, at least as an example in the documentation. If it’s being renamed for 7.17 anyway, maybe it could be called respond-only or similar.
Responder should be side that can have static connectivity and IP address (let’s call it server, maybe? WG seem to not love this word), so dynamic devices can initiate connection to it, and responder, well, responds to them.
And that’s what I’ve guessed, to put responder=yes on the “server’s” configuration, but in the definition for the remote peer. Being used in that way, in peer definition, as though the term refers to the peer, makes it a confusing use of the term. To me, anyway. An example in the docs would still be nice.
It’s a server-side config “per-user”, you can have multiple peers on a single interface, and for a reason want to be some as initiators, and others as responders. But that only means if server wish to start connection first or not, but doesn’t affect “client wishes” in any way.
The first block should contain them. The problem is that current implementation is buggy and gonna be fixed in 7.17, so no more handshake failures in logs. Currently, if client doesn’t handshake in a default 2min window, server tries to handshake on its own using discovered client endpoint, which should not happen while responder is checked.
No I dont need to tell myself on each config who is client for handshake and who is server for handshake. I am the admin I know what I have setup and can add comments if required.
These settings should only be required perhaps for BTH settings, certainly not normal wireguard setups…
It’s still unclear to me, on which side and in which peer-definition I set responder=yes?
Let’s assume I have a central router with a static-IP (which should act as the server “responder”). And we have a few “road warriors”, who have dynamic-IPs and must initiate the connection.
Do I set responder=yes in the “server” (the router with the static IP) and on this device in the peer-definition of the dynamic-IP-devices “road warriors”?
Or do I set this in the road-warrior-device and there in the peer-definition of the “server”?
You can read the documentation both ways. And even in a lab with both sides set to “responder=yes”, the tunnel is established (v7.16.1).
Are you sure? My understanding is the other way around - the roaming/client/road warrior (possibly dynamic IP and/or behind NAT) is the initiator and the server (public IP) is the responder - right?
There is no need to indicate responder in normal wireguard. It should a term only used in BTH, if thats where its coming up??
As per the documentation all the extra fields not normally used…
Used for the client-server setup scenario, when the configuration is imported using a qr code for a client, configuration details on tab with qrcode will appear once it has been set in the fields:
Since I dont use BTH or qr codes, the terms are foreign to me.
As per the documentation: responder (yes | no; Default: no) → Specifies if peer is intended to be connection initiator or only responder. Should be used on WireGuard devices that are used as “servers” for other devices as clients to connect to. Otherwise router will all repeatedly try to connect “endpoint-address” or “current-endpoint-address”.
To me that indicates the term should only be set to YES, on the allowed IP settings on client peer devices when describing the peer Server Router.
It should never be used on the peer Server Router to describe the peer client devices.
In other words it logically matches persistent keep-alive.
Maybe it’s a bit confusing so some examples (clearly marked which side is which) would be useful. My understanding is that the purpose of this setting is to avoid the server trying forever to re-connect with a client that is gone (disconnected, changed IP address, behind NAT so not reachable from outside and must be first to connect).
Why would the server keep trying to contact the peer client if its gone. There may be some attempt to establish communications to pass on lets say a new WANIP in a the normal wireguard but in BTH, the controlling entity is wireguard cloud relay. If both sides are not talking to the relay the connection is broken. The server should not initiate any traffic.
I am not saying your wrong, I just dont see any other logic.
In short: The “responder” parameter should have been named instead as “Only respond” (or “To this peer only respond” or “Do not initiate connection to this peer, only respond”).
It may be set (in fact, changed from the default “Not only respond”) in a configuration of a peer (say, smartphone) in the server device’s (say, router’s) settings [if the configuration is kind of not peer-to-peer but peer-to-server] [and is separate for each peer i.e. has to be set to “yes” individually for each peer-for-which-is-needed] [and AFAIK can be set to “yes” not to all of the peers in the list as well].
bp0, could you please mark the topic as [SOLVED], if the last mantouboji’s message (or this one of yours truly) solves this MikroTik’s conundrum.
