question about "wireguard responder"

RouterOS General
1

i’m having a hard time understanding this line in 7.15 changelog

*) wireguard - added option to mark peer as responder only;

and the relative documentation

is-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” causing unnecessary system logs to be written.

should i use it for site2site peers or for roadwarrior ones?

2

You should use this for the device which acts as initiator of the connection.
Not if some device is only waiting for connections to come in (useless there).

So roadwarrior situation:
The mobile device should have it. The “server” not (yeah yeah, wireguard is all peers, I know …)

Site 2 site: can be both if both have a fixed IP.
If only one has a fixed IP, it should be used on the site with dynamic IP.

3

if that is the case the utility is lost to me:
wouldn’t i want something that flags on the “server” a specific peer as “you should not try to reach this one, it will always be it that contacts you” to avoid spamming packets to a non existent endpoint?
or am i misinterpreting this?

4

Now you mention this, my explanation was completely backwards :open_mouth: :confused:
Oops …

In that case, tick “responder”.
That’s what it does. It does not go out, it only listens.

What it should be then:

You should use this for the device which acts as arrival of the connection.
Only if some device is simply waiting for connections to come in.

So roadwarrior situation:
The mobile device should NOT have it. The “server” does (yeah yeah, wireguard is all peers, I know …)

Site 2 site: can be none if both have a fixed IP.
If only one has a fixed IP, it should be used on the site with static IP.

5

oh, ok, great, so that’s exactly what i need :smiley:

thanks a lot!

6

Not required at all unless using BTH, which should only be used if both ends do not have a public IP or the ISP router cannot forward ports to the MT device.
Otherwise advise avoiding all that nonsense.

7

may i ask why would you avoid that?
for a “roadwarrior only” scenario it sound great on the wireguard “server”

8

It used to (at minimum) stop a lot of annoying log messages on the server, I assume it still might.

9

Shot myself in the foot by using it on the “server” side in a router-router-VPN scanario.

Result was that new packets form the “client/caller” passed flawlessly, so I could reach other services in my home lab but new packets from the “server/responder” were dropped! Not what I expected but in a very close definition of being a responder quite obvious… LOL

So: Do not use it unless you need it! :wink:

Cheers,

Ralf.

10

And the “worst writing in a short sentence” 2024 award goes to the anonymous Mikrotik developer for the sentence:

Should be used on WireGuard devices that are used as “servers” for other devices as clients to connect to.

11

Not required for standard setups as stated and its redundant anyway. Its basic understanding of how wireguard works → A peer client at handshake initiates the connection, the peer Server responds.
Why would the admin need to tell himself anything extra, he knows the config already. Its confusing and I see no point to it.
Its strictly a BTH function when there is no clear client server relationship as the connection is done at the MT cloud.

12

It does result in a lot less log messages on the server side.

13

I get zero logged messaged on my server side… false information

14

i agree.
i have routers at remote sites which have static ip and connected to my router

and i have static ip on myside and some other outers connect from their to me

to me keeping off has worked fine till now

15

Tried to setup mikrotik wireguard in a site-to-site manner, whereas one side is having CGNAT and is the connection initiator (client side, B).
The other server side (side A) site has a bridged WAN fixed public IPv4 and is set as a responder, without the endpoint/port set nor persistent keep-alive being set.

Now, I didn’t manage to set things up fully working, likely due to some other rules bugging me that I will need to trobubleshoot further or CGNAT might be preventing tunnel establishment.

Either way, I noticed side A is trying to initiate the connection regardless of the fact that it is checked off as a responder (in 7.16.1).
Likely a bug to report, so here is the related log excerpt on site A:

…
Handshake for peer did not complete after 5 seconds, retrying (try 16)
Wireguard: Sending handshake initiation to peer ((einval))
Wireguard: Handshake for peer did not complete after 5 seconds, retrying (try 17)
Wireguard: Sending handshake initiation to peer ((einval))
…
Handshake for peer did not complete after 5 seconds, retrying (try 20)
Wireguard: Sending handshake initiation to peer ((einval))
Handshake for peer did not complete after 20 attempts, giving up
…

16

I think: when site A has a “fixed” IP address, act as a SERVER, and site B is a roaming one, or behind a NAT gateway, act as a CLIENT.

In site A, should mark peer B as a responder.

In site B, don’t need mark anyone.