WireGuard 'client' not attempting to initial connection to 'server' peer?

RouterOS General
21

I only started reading this big post, but your log mentions OSPF, so maybe your routing configuration is more complex than what posted so far. The normal dynamic connected routes created by adding/removing IP addresses normally don't produce info log entries. It not easy to infer everything from pieces of print output.

Do you have the remote peer's endpoint IP address? The address outside the tunnel, where the UDP WG packet will be sent to. If yes, check the output of the command

/ip route check dst-ip=a.b.c.d once

with a.b.c.d being that address. What is shown as interface and next hop?

22

Thank you. I also noticed the OSPF appearing in the log; I don't know why. My routing configuration has no advanced protocols at all - just static and automatic routes. Or, at least, it shouldn't; I see on three of my four deployed MikroTiks (including this MikroTik3B) that one default OSPF instance exists; this seems to be something that RouterOS did automatically at some unknown point; however, this does not exist on my most central router (which is physically the newest piece of hardware I own, the only one that began its life on a ROS v7 version). So - hopefully - this isn't involved. I've removed that OSPF instance, and it doesn't seem to have made a difference in the WireGuard problem.

Next, peer endpoint; indeed, I have its IP address (it registers with a dynamic DNS service);
[MikroTik3B] >/tool/traceroute ${MikroTik4's dynamic DNS hostname} completes successfully, as does /ping ${MikroTik4's dynamic DNS hostname}.

The /ip route check output is correct- next hop is 192.168.178.1 (the ISP FRITZ!Box router) on bridge.

23

For me it seems that the weight of routes is set that way that loosing WG or OSPF or BGP or any other route implies flood of routing table rebuilds and one lost interface puts routes sequentially to their knees.

24

Another possibility is that you have some masquarade set for some interfaces and ROS, making a decision which interface use to send the traffic out, takes "wrong" (it means usually the lowest one) IP assigned to that interface, especially if you reconfigure interfaces. Connection gets broken, packets leak to wrong interface (0.0.0.0/0) as not being the part of "established connection". The implication is lost communication, possible BFD "alarm" that means connection shutdown and the "wave" of problems evolves the be a "tsunami".

25

Hi @BartoszP , I don't really understand what you've written, but anyway, the nat/masquerade rules are very simple:

[admin@MikroTik3B] > /ip/firewall/nat/print detail
Flags: X - DISABLED, I - INVALID; D - DYNAMIC
0 ;;; masquerade anything from this MikroTik to anywhere other than any other Felines network
chain=srcnat action=masquerade src-address=192.168.252.0/24 dst-address=!192.168.248.0/21 log=no log-prefix=""

1 ;;; Masquerade anything leaving this Mikrotik, from any Felines net, to the local Comcast Xfinity LAN, behind this MikroTik's Comcast local LAN IP
chain=srcnat action=src-nat to-addresses=10.0.1.3 src-address=192.168.248.0/21 dst-address=10.0.1.0/24 log=no log-prefix=""

Even if some kind of mangling/NAT was going on that would result in the traffic not reaching the intended destination, wouldn't the sniffer trace with all fields clear except filter-port=${my WG VPNs listener port} catch the traffic?

What could cause the WireGuard client/peer to generate absolutely zero visible traces of ever even attempting to send out a connection packet (nothing in log, nothing that sniffer can see, etc)?

thank you,

26

Just as a next step in debugging, it would be useful to know how exactly you check that "no attempt is made."

There is a log message that should periodically appear, something like "wireguard handshake unsuccessful after N retries, giving up". Does it?

What if you try to log the handshakes in mangle->output? A useful factoid is that a handshake request is always 148 bytes.

If there is really no attempt, that means that either your wg configuration is incorrect, there is no route to the destination in main or a bug.

I think it was mentioned that 7.24 seems to have a bug (or several) which makes wg peer entries act as if they were disabled. (And it was also reported that - contrary to one's intuition - disabling and re-enabling it does not fix this.)

27

Thanks @lurker888

I make the assertion that "no attempt is made" on all of the following:

  • nothing in the system log (see log config and search examples below)
  • in WinBox and at CLI /interface/wireguard/peer/print detail never show any last-handshake
  • /tool/sniffer captures, looking at wg1, or looking at no filters at all except for filter-port=${MikroTik4 WireGuard listener port}, which never captures anything at all except my traceroutes or pings to generate traffic that should cause the tunnel to come up, and that shows only MikroTik3G's own ICMP packets being transmitted on wg1 (so, there are routes which will send data out via a WireGuard peer), but causes absolutely no other traffic.

Given all this, is it still worth trying to capture the WireGuard handshakes/initiation in mangle? Or, as I think, have these other ways of looking for the handshakes/initiation sufficietly demonstrated that It's Just Not Happening Like It Should?

thanks,
Jay

system logging config:

[admin@MikroTik3B] > /system/logging/print where topics~"wireguard" and disabled=no
Columns: TOPICS, ACTION

TOPICS ACTION

1 ppp memory
wireguard
debug
packet
info
warning
bridge
discover
interface

Nothing in the system log:

[admin@MikroTik3B] > /log print where topics~"wireguard" or topics~wireguard or message~"wg1" or message~"wireguard" or message~"WireGuard"
2026-08-20 04:05:53 interface,info wg1 link up

I'm actually surprised to see even this one "wg1 link up" entry but I'm fairly sure that's when I had tested completely deleting and re-creating the WireGuard interface and peers, so, it is not any indication of any peer connection attempt.

28

The log entry should look like this:

Topic: wireguard,info

Message:
wginterface: [peername] peerpublickey: Handshake for peer did not complete after 20 attempts, giving up

If there is nothing like this, that means that something is very wrong.

Are you absolutely sure that you have a default route? (Or a route to the other router it's supposed to connect to?)

You've previously shown that you have configured the endpoint by fqdn. Are you absolutely sure that DNS resolution works on the router itself?

You can check the route thing with /tool ping and the DNS resolution part with :put [:resolve example.com]

Capturing the outgoing packet in mangle output is absolutely worthwhile. When you capture packets on the wgX interface, you will only see packets traveling in the tunnel, so over the overlay. The handshake packet doesn't travel there (it's part of the underlay) so it won't be visible.

One huge clue that dns is not working is that the "current-endpoint-address" field is not populated.

29

Yes, name resolution is working correctly on the router (including, explicitly, :put [:resolve ${the WG peer DNS name}]. (I apologize if I had implied that I had configured the WG peer by FQDN; it's a DNS name, of the - currentlyly correct, and reliably updated, dynamic DNS name of the WG peer). [So, just now, I temporarily tried setting the WG peer to an IP address instead of a DNS name. It made no difference.]

Yes, routing to, and reaching, the WG peer endpoint works (ping, traceroute). Everything on the router works, except that WireGuard is not initiating.

My sniffer traces have included setting ALL sniffer fields to except for the filter-port, so no matter the interface, protocol, direction, etc, etc, etc, as long as the router would transmit, any which way, a packet towards ${the WG peer listener port}, the sniffer should have detected it. The sniffer found nothing. (My example of sent-only packets being sniffed on wg1 was just to demonstrate that it is possible to generate traffic on this router that the router wants to send through a WireGuard tunnel, which even if the persistent-keepalive was not working, should cause the tunnel to attempt to initiate. It does not).

I believe that the current-endpoint-address field is not populated because, indeed, something is very wrong, and RouterOS is flatly not even trying to initiate the tunnel :frowning:

30

The reason that I usually log in mangle output is that some things, like filtering in the firewall, IPSec encapsulation, etc. can happen later in the processing that will preclude the packet from actually being emitted. These are fairly hypothetical scenarios.

FQDN is what is usually referred to as a "DNS name".

I think you've mostly exhausted your avenues for investigation.

At this point I'd try restarting the device (on the off chance you haven't already), but then I'd netinstall it. Just not to 7.24, but an older version like 7.21.5.

A netinstall will allow you to debug the issue step by step while building up the config. If you create a binary backup before doing this, then you can easily return to your current state.

EDIT: Before nuking things, verify again that "responder" is not set by accident.

31

Confirmed, responder NOT set. (I then also set responder, applied, then again unset responder, applied. No change).

FQDN :person_facepalming: yeah, yeah, brain fart on my part, sorry; I'm getting over the flu - brain may not be working so well at the moment... (I was around at Carnegie-Mellon University in the 1980s when DNS happened. I actually met Cricket Liu at one point when I was in the security group at Delta Air Lines in the late 1990s. [Insert other fascinating name-drops here]. Back then this tech stuff was easier for me).

FYI, my ip firewall filter contains NO action=drop rules, as this device is never meant to be broadly exposed to the Internet. There is no IPsec configured. Only the two simple NAT/masq rules as mentioned above. There just shouldn't be anything in this configuration which should be able to cause a WireGuard peer handshake initiation packet to be vanished without a trace like this.

Restarting - have already done, several times.

The one thing that I haven't done (7.24 bug) is completely delete ALL WireGuard configuration and re-create it; what I did do was to delete the wg1 interface and the MikroTik4 peer, but I left two road warrier 'client' peers of this router in the WireGuard peers configuration.

I'll clear away the entire WireGuard configuration, reboot, and re-create it:

No, that made no difference either.

So, supout -> MikroTik support, referencing this forum thread, with the brief summary "Even after extensive community discussion and testing a variety of things, it looks like something broke, possibly with the 7.24 upgrade persistent even downgrading to 7.23.3 (still firmware 7.24) which completely turns off WireGuard's ability/willingness to initiate a connection to a peer" ?

(I've never used netinstall; separately, I use ACME certificates with functionality that was added from 7.23, so going back to the LTS 7.21 tree would definitely result in some configuration breakage; and it worked on 7.23, so if I have to do this, I'd try with 7.23 first).

I do have a full BKP (as well as an EXP) of the 7.23.last configuration from just before all of this occurred. I think that might be the least-impactful place to start.... ? But I'd like to give MikroTik support the opportunity to debug, first.

So, anything else/ any other way to state, the problem in the support ticket that I'll raise?

thank you, all!

32

Ah. That's the thing I missed. You upgraded to 7.24 and then downgraded.

I'm willing to bet that something stuck around in the internal configuration. I don't know of any real way of messing around with the internal config, other than that netinstall clears it completely, and that backup/import replaces it completely.

So if you happen to have a pre-upgrade backup, that would help.

Depending on how much of a hurry you're in, it's an option to wait for the .1 release. Mikrotik is usually quite expedient in correcting these sorts of snafus.

33

Maybe this might help:

I've faced the same problem: wireguard wouldn't reconnect after disable-enable (which is done by script when "server" is unreachable). After I changed keepalive to something less than a minute (was 5 minutes) it reconnected immediately.

I don't have time to experiment with that right now, will try later...

34

Hi @sinisa , my keepalive is 00:00:30 :frowning:

I'll temporarily raise it to 00:05:30 and then lower it again:

No, that didn't make any difference, either.

35

Further test: I set up another of my MikroTik routers to initiate inbound an WireGuard peer connection to this malfunctioning MikroTik3B router. I do see the packets arriving (and the firewall filter accept rule counter incrementing), but again there is no response from the WireGuard stuff inside this MikroTik's kernel.

It really seems that MikroTik totally broke something in 7.24.

So, back to the supout.rif question - other than the supout itself and a link to this thread and a brief description, anything else that you recommend that I include in the bug report to MikroTIk?

thank you

36

MikroTik support immediately responded, with no details whatsoever, that "this is fixed in the next 7.24 release". No certainty that they even looked at my supout file vs. they're talking about the 7.24rc comments on the issue. No statement about when the "next" 7.24 release will come out (the MikroTik engineer included a link to 7.25 test files, which I'm not going to try to install). No rollback instructions, no answer to the question that I included in my bug report about how to get firmware back from 7.24 to 7.23.3.

Disappointing. I told them so.

37

Whenever I back down a release, I go to the routerboard section, and the old firmware is now listed as the "upgrade" one and I simply hit "update" and it loads. Same process as normal . . . it does not appear to care about version number delta at all - the one offered to load is what the device is running. (At least on all my stuff . . . I clearly don't own 'em all!) Just did this a few days ago on a haP ax2 - tried 7;24 and it's FW, and then rolled both back without issue.

(Note that I typically do this via WebFig . . . although the same stuff appears in the CLI. Never tried it in WinBox.)

38

:person_facepalming: Thank you, @tadawson . That's .. not obvious.

Unfortunately, it also doesn't work around the problem. Whatever MikroTik broke in this case, on my MikroTik3B they really broke it. I'll wait for 7.24.next, since it's not operationally urgent, but I really wonder whether even that will fix it, and I'll eventually have to restore the BKP file.

39

OK.

When you have the masquarade action like this:

/ip firewall nat add action=masquerade chain=srcnat out-interface=ETH8

then ROS makes NAT only for packets sent via this interface and changes src addr to the one that is assigned to that interface. If there are more than one, then it gets ... usually the "lowest" one but you never could be sure, so the better version is:

/ip firewall nat add action=arc-nat chain=srcnat out-interface=ETH8 to-address=IP_YOU _WANT_TO_BE_USED

If it is a WAN interface then all packets for which there are no known routes to dst address are sent with src-nat rule applied.
If you your management "internal" traffic passes different interfaces and goes outside the router then it could fall into your "broad" masquarade src-nat action and be changed to a packet with a different src address than the "receiver" expects as you never know what IP address would be used as src one.
Therefore if the "receiver" expects traffic from address X but receives NATted one than there is no match and connection is not established. More, if routes get changed (you loose a link) then the already esteblished connection could start receiving packets with different src address as they would go via different interface (masquarade could be applied) and the conection closes -> another link lost -> route recalculation -> other connection lost -> "tsunami" of problems.
If there are no matching "technical" routes then all goes to WAN. Good if ISP kills packests with forbidden addresses. If not then they travel and get TTL-killed after dozens of jumps. Your packets could also reach other routers with publicly exposed "internal" IPs that match your ones from connection and your "sender" router would be sure that it reached the proper "receiver" but it would never get the proper answer -> no link established, no traffice on receiver seen.

40

Thanks, ok, understood. My NAT/masq rules are trivial:

[admin@MikroTik3B] > /ip fire nat print detail
Flags: X - DISABLED, I - INVALID; D - DYNAMIC
0 ;;; masquerade anything from this MikroTik to anywhere other than any other Felines network
chain=srcnat action=masquerade src-address=192.168.252.0/24 dst-address=!192.168.248.0/21 log=no log-prefix=""

1 ;;; Masquerade anything leaving this Mikrotik, from any Felines net, to the local Comcast Xfinity LAN, behind this MikroTik's Comcast local LAN IP
chain=srcnat action=src-nat to-addresses=10.0.1.3 src-address=192.168.248.0/21 dst-address=10.0.1.0/24 log=no log-prefix=""

And, other than the (non-working) wg1/WireGuard stuff, there are only two live interfaces (Eth2/bridge, wlan1, and well, lo):

[admin@MikroTik3B] > /interface/print detail where running
Flags: D - DYNAMIC; X - DISABLED; I - INACTIVE, R - RUNNING; S - SLAVE; P - PASSTHROUGH
1 RS name="ether2" default-name="ether2" type="ether" mtu=1500 actual-mtu=1500 l2mtu=1598 max-l2mtu=2028 vrf=main mac-address=D4:01:C3:C6:CD:A9
last-link-up-time=2026-08-21 18:22:35 link-downs=0

5 R name="MTik3B-wlan1" default-name="wlan1" type="wlan" mtu=1500 actual-mtu=1500 l2mtu=1600 max-l2mtu=2290 vrf=main mac-address=D4:01:C3:C6:CD:AD
last-link-up-time=2026-08-21 18:32:26 link-downs=0

6 R ;;; defconf
name="bridge" type="bridge" mtu=auto actual-mtu=1500 l2mtu=1598 vrf=main mac-address=D4:01:C3:C6:CD:A9 last-link-up-time=2026-08-21 18:22:32 link-downs=0

7 R name="lo" type="loopback" mtu=65536 actual-mtu=65536 vrf=main mac-address=00:00:00:00:00:00 last-link-up-time=2026-08-21 18:22:31 link-downs=0

10 R name="wg1" type="wg" mtu=1420 actual-mtu=1420 vrf=main last-link-up-time=2026-08-21 18:22:31 link-downs=0

(wlan1 does not appear below because nothing is connected to it just at the moment).

[admin@MikroTik3B] > /interface/bridge/port/print where status!=inactive
Flags: H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, HORIZON, TRUSTED, TRUSTED-RA, TRUSTED-DHCPV6, FAST-LEAVE, PATH-COST, INTERNAL-PATH-COST, BPDU-GUARD, EDGE, POINT-TO-POINT, PVID,
FRAME-TYPES

INTERFACE BRIDGE HW HORIZON TRUSTED TRUSTED-RA TRUSTED-DHCPV6 FAST-LEAVE PATH-COST INTERNAL-PATH-COST BPDU-GUARD EDGE POINT-TO-POINT PVID FRAME-TYPES

;;; defconf
0 H ether2 bridge yes none no no no no 10 10 no auto auto 1 admit-all

So I'm sure that this is not a problem of unexpected/ unpredictable/ wrong NAT/masq. Do you agree?

thank you,