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

libove · August 19, 2026, 7:56am

Zero doubt that I've done this to myself, so, , go ahead, give me my well-earned flaming....

I have several MikroTik routers, all of them happily talking WireGuard amongst themselves, as well as happily receiving 'road warrior' (Windows mobile client) WireGuard connections. All of them recently updated to 7.24 (stable).

Except one. I've recently configured one RB951Ui-2HnD to go at a new site, and the WireGuard 'client' on that router does not seem to be even attempting to connect to its 'server' peer. (The 'server' is "MikroTik4", the 'client' is "MikroTik3B"; the WireGuard peer configuration on MikroTik4 for the MikroTik3B client is set to 'responder', the peer configuration on MikroTik3B for the MikroTik4 'server' is NOT set to responder).

I suspect this may have something to do with the unique bridge configuration that I have on MikroTik3B, which I have because I had noticed a DHCP service weirdness, so I'll start by describing that:

MikroTik3B is not directly exposed to the Internet. It sits behind a FRITZ!Box ISP router. MikroTik3B has a static IP address within the FRITZ!Box's LAN (192.168.178.x/24), and is plugged into the FRITZ!Box via MikroTik3B Eth2 -> some Ethernet port on the FRITZ!Box. MikroTik3B's default route is to/through the FRITZ!Box (192.168.178.1). That works. MikroTik3B can reach the Internet, can check MikroTik's servers for updates, can route traffic for hosts connected to MikroTik3B's offered wireless network to the Internet; MikroTik3B's local LAN for its wireless clients is 192.168.252.0/24, for which it runs a DHCP server. Everything works fine .. except:

Initially, when a wireless client would connect to MikroTik3B's wifi and issue a DHCP client request, despite that MikroTik3B runs a DHCP server:

[admin@MikroTik3B] > /ip/dhcp-server print detail
0 ;;;
name="FelinesNJDad" interface=MTik3B-wlan1 lease-time=10m address-pool=FelinesNJDadDHCP dynamic-lease-identifiers=client-mac,client-id server-address=192.168.252.3
add-dns-entries-suffix="lan" use-radius=no use-reconfigure=no lease-script="" dhcp-option-set=FelinesDad_DHCP_Options_set address-lists="" support-broadband-tr101=no

.. the wireless client would end up getting a DHCP lease from the FRITZ!Box on the other side of MikroTik3B's wireless/Ethernet bridge. I didn't want that.

So, I removed MikroTik3B's wireless interface from MikroTik3B's (one and only) bridge:

[admin@MikroTik3B] > /interface/bridge/print
Flags: R - RUNNING
0 R ;;; defconf
name="bridge" mtu=auto actual-mtu=1500 l2mtu=1598 arp=enabled arp-timeout=auto mac-address=D4:01:C3:C6:CD:A9 protocol-mode=rstp fast-forward=yes igmp-snooping=no
auto-mac=no admin-mac=D4:01:C3:C6:CD:A9 ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no
dhcpv6-snooping=no ra-guard=no port-cost-mode=short max-learned-entries=auto mlag-peer-port=none mlag-priority=128 mlag-heartbeat=5s

[admin@MikroTik3B] > /interface/bridge/port/print
Flags: I - INACTIVE; 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

N 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
;;; defconf
1 IH ether3 bridge yes none no no no no 10 10 no auto auto 1 admit-all
;;; defconf
2 IH ether4 bridge yes none no no no no 10 10 no auto auto 1 admit-all
;;; defconf
3 IH ether5 bridge yes none no no no no 10 10 no auto auto 1 admit-all

(notice, no wireless interface in bridge's port list)

Since doing that, everything - except MikroTik3B being a WireGuard 'client' peer of MikroTik4, works. Wireless clients of MikroTik3B get (only) a DHCP address from MikroTik3B's DHCP server on MTik3B-wlan1, and can talk to the Internet through MikroTik3B through the FRITZ!Box just fine. (I have not attempted to test inbound WireGuard connections from the Internet to MikroTik3B).

Here are all of MikroTik3B's interfaces:

[admin@MikroTik3B] > /interface/print
Flags: X - DISABLED; R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU, L2MTU, MAX-L2MTU, MAC-ADDRESS

N NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 ether1 ether 1500 1598 2028 D4:01:C3:C6:CD:A8
1 RS ether2 ether 1500 1598 2028 D4:01:C3:C6:CD:A9
2 S ether3 ether 1500 1598 2028 D4:01:C3:C6:CD:AA
3 S ether4 ether 1500 1598 2028 D4:01:C3:C6:CD:AB
4 S ether5 ether 1500 1598 2028 D4:01:C3:C6:CD:AC
5 MTik3B-wlan1 wlan 1500 1600 2290 D4:01:C3:C6:CD:AD
;;; defconf
6 R bridge bridge 1500 1598 D4:01:C3:C6:CD:A9
7 R lo loopback 65536 00:00:00:00:00:00
8 sstp-in1 sstp-in
;;; (old) Pegged-up VPN route to Barcelona network
9 X sstp-out1 sstp-out
10 R wg1 wg 1420

.. and the details of the wireless interface:

[admin@MikroTik3B] > /interface/print detail where name="MTik3B-wlan1"
5 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 link-downs=0

The WireGuard setup (I'll omit the MikroTik4 'server' side since that works for all of my other MikroTik router 'client' peers and for various Windows 'road warrier' peers, and the problem is that I never see any attempts from MikroTik3B to even send a single connection packet out):

[admin@MikroTik3B] > /interface/wireguard/print detail
Flags: R - RUNNING
0 R name="wg1" mtu=1420 listen-port={myport} public-key="{public key}="

0 ;;; This MikroTik3B as a WG client of Tik4 in BCN
interface=wg1 name="MikroTik4-WG" public-key="{other public key}=" endpoint-address={MikroTik4's public DNS} endpoint-port={myport}
current-endpoint-address="" current-endpoint-port=0 allowed-address=192.168.255.0/26,192.168.255.64/26,192.168.255.128/26 persistent-keepalive=30s client-endpoint=""
client-allowed-address=::/0 rx=0 tx=0

At no time do I ever see any packet cross any of MikroTik3B's interfaces for {myport}, at no time do I ever see any packet arriving on MikroTik4 from MikroTik3B's public IP address, at no time do I see any system log entries for WireGuard on MikroTik3B (I have /system/logging add topics=ppp,wireguard,debug,info,warning,packet action=memory). (Except, if I disable/enable the MikroTik3B 'client' peer to MikroTik4 then the system log will show the disable/enable messages).

The last-handshake field on MikroTik3B for its 'client' peer relationship with MikroTik4 is always empty.

Okay, flame me: what have I done wrong?

thank you...
-Jay

fragtion · August 19, 2026, 8:54am

This is a bug with v7.24. Downgrade to 7.24rc1 or 7.23.x and you should be fine.

I reported this issue on the 7.24rc thread (7.24rc [testing] is released! - #190 by fragtion) before 7.24 was released and even posed the rhetorical question about whether this issue was going to find its way in the 7.24 release, and low and behold, it still did Blows my mind that they released 7.24 to all release channels after this bug had been published days before on the sole forum thread they had in place for 7.24rc feedback.....

crosswind · August 19, 2026, 9:03am

does it really blow your mind though. i mean, based on previous experience with MikroTik...

fragtion · August 19, 2026, 9:13am

Maybe a lesson can be learned here that not all bugs will be filed through the Support platform with a supout.rif provided. Perhaps they should pay a little bit more attention to users taking the time to report a potentially major bug on an their official release forum thread also, as not everyone wants to share their private router configuration each time they report a general bug that is release-specific and likely to affect many other users.

It's not a co-incidence that I made the remark "Looks like it may find its way into the official/stable 7.24 release? that wouldn't be good. please fix ". I did so based on prior experience reporting an issue on the forums which gets ignored only for it to become a major issue in a subsequent release. So this seems to be a common slip-up with Mikrotik for some reason. Why have a forum thread for each version if you aren't going to take notice of (or recklessly ignore/dismiss) bug-related feedback on those threads?

libove · August 19, 2026, 9:21am

That really is hard to believe (even for MikroTIk).

In my case, however, a reboot does not fix the problem. It's persistent even after a reboot.

Worse, it's persistent even after downgrading RouterOS to 7.23.3 ... (Firmware is still at 7.24; must I also downgrade firmware? HOW to downgrade firmware? I find lots of information about .npk and downgrading RouterOS/packages, but nothing about downgrading firmware)

Other ideas, please? sigh Thanks.

fragtion · August 19, 2026, 9:32am

Ah ok, yours may be a different issue then after all, and indeed related to a device-specific (mis)configuration

Is the TX counter for the peer (on MikroTik3B) at least incrementing? If it is, then you are dealing with a different fundamental underlying issue (however, being on 7.24 could be complicating your troubleshooting efforts...)

If you have supplied an endpoint address (IP/hostname:port) for a peer, and that peer has persistent keepalive set and 'Responder' option unchecked, then you should see the Tx counter for that peer incrementing whenever traffic is directed to the peer endpoint (ie: on keepalive, or routed traffic). If no Rx response/traffic seen on the same peer, then either the traffic is being obstructed, or your private/public key pairs are wrong - handshake will fail, and Rx counter will remain 0.

One thing you could try is to set the endpoint to {placeholder-ip}:{placeholder-port}, and then add a firewall rule to redirect that traffic to the real host and endpoint:

/ip firewall nat add action=dst-nat chain=output comment="MikroTik3B" protocol=udp src-port={wg-interface-port} to-addresses={real-dst-endpoint-ip} to-ports={real-dst-endpoint-port}

the placeholder ip:port can be any ip:port as that will be rewritten by the firewall anyway. the src-port should be set to the listening port of the peer's parent interface (ie, on the same device). this helps to steer traffic to the correct ip:host at all costs (bypassing wg's internal endpoint cache and similar shenanigans) - it's worked for me in a few fringe cases where I had similar issues to what you seem to be experiencing

libove · August 19, 2026, 10:00am

Thank you. No, the Tx counter stays zero on MikroTik3B.

And,

[admin@MikroTik3B] /tool/sniffer> print
only-headers: no
memory-limit: 100KiB
memory-scroll: yes
file-name:
file-limit: 1000KiB
streaming-enabled: no
streaming-server: 0.0.0.0:37008
max-packet-size: 2048
filter-stream: no
filter-interface:
filter-mac-address:
filter-src-mac-address:
filter-dst-mac-address:
filter-mac-protocol:
filter-ip-address:
filter-src-ip-address:
filter-dst-ip-address:
filter-ipv6-address:
filter-src-ipv6-address:
filter-dst-ipv6-address:
filter-ip-protocol:
filter-port: {myport}
filter-src-port:
filter-dst-port:
filter-vlan:
filter-cpu:
filter-size:
filter-direction: any
filter-operator-between-entries: or
quick-rows: 20
quick-show-frame: no
running: yes
[admin@MikroTik3B] /tool/sniffer> pack print follow
-- Ctrl-C to quit. Space prints separator. New entries will appear at bottom.

.. never shows any packets. So it really seems that MikroTik3B's WireGuard 'client' (even having downgraded ROS to 7.23.3) simply never does anything at all ... so I wouldn't expect the NAT rule to change anything. (My sniffer config above should catch any attempt to MikroTik3B to send a packet on any interface any protocol port {myport}, right?).

Also, /ip firewall filter contains NO action=drop rules, so I also don't think it's that I'm blocking myself from sending the WireGuard packets, right?

fragtion · August 19, 2026, 10:01am

Delete and recreate the peer and wg interface (You could try simply deleting them and then pressing undo button twice). Does the issue then still persist?

I'd advise to create a supout.rif before and after doing this, so that if recreating the interface with the exact same configuration resolves your issue, then Mikrotik can potentially investigate what the issue was with the interface before it was recreated with the same configuration.

CGGXANNX · August 19, 2026, 10:13am

If possible, post your /ip address print output too. It might be possible that the addresses are attached to the wrong interfaces.

libove · August 19, 2026, 10:34am

Thank you, both. Deleting and re-creating the wg1 interface and the peer did not resolve the problem; I still see no attempts at all by MikroTik3B to initiate the connection. (I did created supout.rif files before and after in case they still turn out to be useful).

Regarding /ip address -- output below; but, even if I had addressing/ interfaces all wrong, wouldn't the /tool sniffer, filtering solely on the destination port of the WireGuard listener on the remote MikroTik, have seen something?

[admin@MikroTik3B] /ip/address> print detail where disabled=no
Flags: X - DISABLED, I - INVALID; D - DYNAMIC; S - SLAVE
0 ;;; MikroTik3B's local WiFi LAN for Felines clients
address=192.168.252.3/32 network=192.168.255.0 interface=MTik3B-wlan1 actual-interface=MTik3B-wlan1 vrf=main

2 S ;;; MikroTik3B WireGuard Server endpoint IP address
address=192.168.252.21/32 network=192.168.252.21 interface=ether2 actual-interface=bridge vrf=main

3 ;;; MikroTik3B WireGuard Client-to-Tik4 endpoint IP address
address=192.168.255.141/32 network=192.168.255.141 interface=wg1 actual-interface=wg1 vrf=main

4 S ;;; TEMP on Nicole FRITZ! Box
address=192.168.178.201/24 network=192.168.178.0 interface=ether2 actual-interface=bridge vrf=main

CGGXANNX · August 19, 2026, 10:53am

As you can see here, the 192.168.178.201/24 address is installed on ether2, and it has a big S flag in front of it. That's because ether2 is a member port of the bridge and thus is a slave port.

The address should be installed on the bridge interface instead. This address is used when the router needs to talk to the FRITZ!Box (the subnet 192.168.178.0/24). Edit it and swap the interface to bridge. And check your masquerade rule if it uses something like out-interface=ether2, change that to out-interface=bridge if needed.

You've configured ether2 as part of the bridge, which means you should not use it directly for things like address assignment or specified as gateway interface anymore or as out-interface. Those things should use the bridge interface. Alternatively, remove ether2 from the bridge if you want to use such things directly on ether2.

Same with this:

This should not be installed on the slave port (again the S flag). I don't think that you even need the entry for this address, this should probably be removed.

libove · August 19, 2026, 12:41pm

I remain perenially confused by what can/can't/"shouldn't" be on Slave ports in MikroTik land; someday I would like to understand that better. What I've read in the forums just hasn't made much sense to me.

About whether the explicitly defined WireGuard Server endpoint IP address is needed, when I was first setting up WireGuard on my other MikroTiks I think that I recall it being necessary at some point; in any case, all of my other MikroTiks do follow this pattern, so at least for the moment it seems to be harmless, and doesn't seem to be related to the problem of MikroTik3B's WireGuard 'client' not even appearing to try to connect out to MikroTik4. (If the on-the-local-.178. LAN slave vs bridge had mattered, I imgine that bigger communications problems than this would have arisen; other than the WireGuard 'client' seeming to not do anything at all, the rest of this router seems to be working well; and the IP address assignment of MikroTik3B's WireGuard server I don't see as being related to the problem of MikroTik3B's WireGuard client not seeming to do anything at all).

Anyway, making those changes (from Eth2 to bridge) did not cause the MikroTik3B WireGuard 'client' to connect out.
No change

libove · August 19, 2026, 5:45pm

There's a dynamic route which appears on MikroTik3B, which does not have an analog on my other routers, and I can't figure out what it's coming from, and it doesn't seem to make sense to me:

[admin@MikroTik3B] > /ip route/print detail where dst-address=192.168.255.0/32
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
DAc dst-address=192.168.255.0/32 routing-table=main gateway=MTik3B-wlan1 immediate-gw=MTik3B-wlan1 distance=0 scope=10 target-scope=5
local-address=192.168.252.3%MTik3B-wlan1

What is this from? Why is it there?
Could this be what's completely blocking the WireGuard 'client' from even attempting to initiate a peer connection to MikroTik4? (But even then, why would no error/log entries occur, and none of my sniffer attempts see anything at all)?

thank you,

libove · August 20, 2026, 8:10am

I really am casting at straws here. I noticed in the system log, when I would temporarily disable the WireGuard wg1 interface, to see if that goosed RouterOS into trying to connect to its MikroTik4 WG peer, these routes created+destroyed entries:

2026-08-20 03:13:23 system,info device changed by tcp-msg(winbox):admin@192.168.178.40 (/interface set wg1 disabled=yes)
2026-08-20 03:13:24 route,ospf,info default-v2 { version: 2 router-id: 192.168.255.141 } destroyed
2026-08-20 03:13:24 route,ospf,info default-v2 { version: 2 router-id: 192.168.252.21 } created
2026-08-20 03:13:39 system,info device changed by tcp-msg(winbox):admin@192.168.178.40 (/interface set wg1 disabled=no)
2026-08-20 03:13:40 route,ospf,info default-v2 { version: 2 router-id: 192.168.252.21 } destroyed
2026-08-20 03:13:40 route,ospf,info default-v2 { version: 2 router-id: 192.168.255.141 } created

It makes sense that the 192.168.255.141 route would be destroyed (when disabling the wg1 interface) and re-created (when re-enabling the wg1 interface), because 192.168.255.141 is MikroTik3B's IP address on its WireGuard interface for when MikroTik3B has a live WireGuard tunnel to MikroTik4.

However, I don't see why the 192.168.252.21 route would change:
192.168.252.21 is on bridge, and is the IP address that MikroTik3B uses for its own WireGuard listener. Whether the wg1 interface (which would get/send traffic via 192.168.252.21/32 on bridge) is up or down or disabled, 192.168.252.21 is just an IP address on bridge. So why does disabling/re-enabling the wg1 interface cause ROS to destroy and re-create the 192.168.252.21 route?

It doesn't seem to even cause the route to be different:

=== To start, wg1 remains enabled, show the 192.168.255.141 and 192.168.252.21 routes:

[admin@MikroTik3B] /system/logging> /ip route print detail where dst-address=192.168.255.141
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
DAc dst-address=192.168.255.141/32 routing-table=main gateway=wg1 immediate-gw=wg1 distance=0 scope=10 target-scope=5 local-address=192.168.255.141%wg1

[admin@MikroTik3B] /system/logging> /ip route print detail where dst-address=192.168.252.21
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
DAc dst-address=192.168.252.21/32 routing-table=main gateway=bridge immediate-gw=bridge distance=0 scope=10 target-scope=5 local-address=192.168.252.21%bridge

=== Disable the wg1 interface and re-check the two routes
[admin@MikroTik3B] /system/logging> /interface/set wg1 disabled=yes
=== As expected, 192.168.255.141 has disappeared,
[admin@MikroTik3B] /system/logging> /ip route print detail where dst-address=192.168.255.141
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP

=== .. and/but 192.168.252.21 seems unchanged
[admin@MikroTik3B] /system/logging> /ip route print detail where dst-address=192.168.252.21
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
DAc dst-address=192.168.252.21/32 routing-table=main gateway=bridge immediate-gw=bridge distance=0 scope=10 target-scope=5 local-address=192.168.252.21%bridge

[admin@MikroTik3B] /system/logging> /interface/set wg1 disabled=no
[admin@MikroTik3B] /system/logging> /ip route print detail where dst-address=192.168.255.141
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
DAc dst-address=192.168.255.141/32 routing-table=main gateway=wg1 immediate-gw=wg1 distance=0 scope=10 target-scope=5 local-address=192.168.255.141%wg1

[admin@MikroTik3B] /system/logging> /ip route print detail where dst-address=192.168.252.21
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
DAc dst-address=192.168.252.21/32 routing-table=main gateway=bridge immediate-gw=bridge distance=0 scope=10 target-scope=5 local-address=192.168.252.21%bridge

Though, why does the 192.168.252.21 route appear with local-address=192.168.252.21**%bridge** ? I'm ignorant here, but that seems to imply that 192.168.252.21 could be on some other interface.

Well, ok, I guess it could: Is my problem that I've hopelessly confused myself (and RouterOS) with how I'm trying to set up what IP addresses/subnets are on which interfaces of this router?

As a reminder, the router has two physical connections:

Eth2 (on bridge) cabled to the ISP router (192.168.178.0/24 network), on which this MikroTik3B has the IP address 192.168.178.201/24
MTik3B-wlan1 (wireless) for offering local behind-my-VPN-networks clients addresses on 192.168.252.0/24, on which this MikroTik3B has the IP address 192.168.252.3/24 (on MTik3B-wlan1)

.. and a further set of logical connections:

192.168.255.141/32 a single IP address which will be on wg1 when this MiktoTik3B is connected to its WireGuard peer/server MikroTik4 (MikroTik4's local subnet is 192.168.255.0/24 and it expects its WireGuard peer/clients to use specific IP addresses reserved within its 192.168.255.0/24 range)
192.168.252.21/32 (on bridge) a single IP address within this MikroTik3B router's local 192.168.252.0/24 subnet on which this MikroTik3B expects inbound WireGuard peer/client connections to arrive. However, see I've_thought_better_of_it notes below.
- (So, this is now 192.168.252.21/32 on MTik3B-wlan1)
192.168.252.22 through .25 - static one-IP-each routes via wg1 for reaching WireGuard peer/clients when those clients connect via WireGuard to this MikroTik3B's WireGuard listener.

Of course, now that I put this all down on paper {yeah, I'm old}, I realize that there's exactly zero reason why the WireGuard listener needs to be on the same subnet on which WireGuard peer/client IP addresses will be assigned, particularly not when the WireGuard listener has to be associated with a different physical interface than the physical interface with which the WireGuard peer/clients will become associated. I realize that what this 192.168.252.21/32 address is supposed to be is the IP address, reachable via WireGuard tunnels, via which peers of this MikroTik3B WireGuard peer/server will route over their WireGuard tunnels with this MikroTik3B WireGuard peer/server, so 192.168.252.21/32 should be on MTik3B-wlan1 along with the rest of the 192.168.252.0/24 subnet, and the WireGuard listener's ip firewall filter chain=input action=accept rule should be on the 192.168.178.201 address on bridge.

Having done the above, the ip addresses and routes now look like:

[admin@MikroTik3B] > /ip address/print detail where disabled=no
Flags: X - DISABLED, I - INVALID; D - DYNAMIC; S - SLAVE
0 ;;; MikroTik3B's local WiFi LAN for Felines clients
address=192.168.252.3/32 network=192.168.255.0 interface=MTik3B-wlan1 actual-interface=MTik3B-wlan1 vrf=main

2 ;;; MikroTik3B WireGuard endpoint IP address for peer/clients while they are connected
address=192.168.252.21/32 network=192.168.252.21 interface=MTik3B-wlan1 actual-interface=MTik3B-wlan1 vrf=main

3 ;;; MikroTik3B's endpoint IP address of WireGuard Client-of-BCN-Tik4 WG tunnel
address=192.168.255.141/32 network=192.168.255.141 interface=wg1 actual-interface=wg1 vrf=main

4 ;;; MikroTik3B Eth link to ISP router on Nicole FRITZ! Box
address=192.168.178.201/24 network=192.168.178.0 interface=bridge actual-interface=bridge vrf=main

admin@MikroTik3B] > /ip route/print detail where disabled=no
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE;
c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, y - BGP-MPLS-VPN; H - HW-OFFLOADED; + - ECMP
5 As ;;; Bremen TEMP
dst-address=0.0.0.0/0 routing-table=main gateway=192.168.178.1 immediate-gw=192.168.178.1%bridge distance=1 scope=30 target-scope=10

6 As ;;; MikroTik3B Felines NJ Dad LAN .252.
dst-address=192.168.252.0/24 routing-table=main gateway=MTik3B-wlan1 immediate-gw=MTik3B-wlan1 distance=1 scope=30 target-scope=10

7 As ;;; JayThinkT16 WireGuard client of MikroTik3B
dst-address=192.168.252.22/32 routing-table=main pref-src=192.168.252.21 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

8 As ;;; Monster WireGuard client of MikroTik3B
dst-address=192.168.252.24/32 routing-table=main pref-src=192.168.252.21 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

9 As ;;; YYThinkX395 WireGuard client of MikroTik3B
dst-address=192.168.252.25/32 routing-table=main pref-src=192.168.252.21 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

10 As ;;; WireGuard VPN route to BCN; n.b. must set pref-src to our MikroTik3B WG Client IP address 192.168.255.141
dst-address=192.168.255.0/26 routing-table=main pref-src=192.168.255.141 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

11 As ;;; WireGuard VPN route to BCN; n.b. must set pref-src to our MikroTik2 WG Client IP address 192.168.255.145
dst-address=192.168.255.64/26 routing-table=main pref-src=192.168.255.141 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

12 As ;;; WireGuard VPN route to BCN; n.b. must set pref-src to our MikroTik2 WG Client IP address 192.168.255.145
dst-address=192.168.255.128/26 routing-table=main pref-src=192.168.255.141 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

All that having been done, MikroTik3B still doesn't try to initiate WireGuard connections to MikroTik4

(n.b. MTik3B-wlan1 remains NOT a part of bridge, because I don't want DHCP client requests of wireless clients of MikroTik3B to pass through MikroTik3B to its bridge/Eth2 interface and be handled by the local ISP router's DHCP server, and it is the intention that this wireless network be ONLY routed, not bridged, to everything outside of that wireless network - and its WireGuard clients - themselves).

(also n.b. MikroTik3B remains on ROS 7.23.3, but with firmware 7.24)

Um, help, please?
thank you,

CGGXANNX · August 20, 2026, 8:24am

This route is from this address assignment:

When you add an /ip address entry to an interface, a connected route (with flag c) is automatically added by taking the prefix length (/32 from address) together with the value of network (192.168.255.0) to form the dst-address value of the route (192.168.255.0/32). The gateway is set to the interface value of the /ip address entry (MTik3B-wlan1). As a result, you see the route in your post:

And distance=0 scope=10 target-scope=5 are default values for connected route.

CGGXANNX · August 20, 2026, 8:35am

As I wrote above, once you've added a port to a bridge, don't add layer 3 stuffs directly to it anymore, that includes:

No address assignment on the port. That should be added to the bridge, or VLAN interfaces created on that bridge.
No DHCP server or client instance on the port. Same as above.
Do not use the port in firewall conditions such as in-interface, out-interface. If you put the port in an interface list, don't expect to have match for the port if you put the interface list in in-interface-list, out-interface-list.
Don't add routes with gateway=the-port.
Do not add /interface vlan entries with interface=the-port, only use the bridge.

I've probably missed a ton more things. But really once you've added a interface to a bridge as member port (under /interface bridge port) most of the time, you should only do stuffs that directly refer to that original interface under /interface bridge vlan (if needed), and nowhere else.

libove · August 20, 2026, 9:42am

Thank you. I guess I just find a /32 route to a .0 address to be weird (I started doing networking in the 1970s, and back then you pretty much never treated .0 as an address, and .0/32 just didn't make sense).

Nonetheless, clearly, this is how it occurs today.

libove · August 20, 2026, 9:44am

I respect that this is how it is supposed to be on MikroTik. What I still don't understand is how MikroTik thinks about bridges/masters and slaves, and why it is this way, but for now that's not key. I really would like to get WireGuard working again on MikroTik3B (it used to work; either/both the 7.24 upgrade, even though I'm back down to 7.23.3 now, or/and whatever config changes I have made recently, have caused WireGuard[-only] to stop working on this particular MikroTik).

thanks,

CGGXANNX · August 20, 2026, 10:32am

That's because you added your /32 address that way. That was your decision to put 192.168.252.0 in network. If you really need that /32 address on that interface, you can add it as:

/ip address 
add address=192.168.252.3/32 interface=MTik3B-wlan1

And you'll see that it automatically set network=192.168.252.3, which means the generated connected route has dst-address=192.168.252.3/32 gateway=MTik3B-wlan1.

It's also a way to configure point-to-point like address. For example you need your router to be 172.18.20.9 on ether1 and be able to talk to some host 10.15.25.35 connected to that interface, in a P2P manner, add the address as:

/ip address 
add address=172.18.20.9/32 network=10.15.25.35 interface=ether1

And you'll see that a route with dst-address=10.15.25.35/32 gateway=ether1 is created for you, that allows talking to that remote host by using ARP to find out the MAC address.

libove · August 20, 2026, 10:44am

Thank you. This - /ip address add address=1.2.3.4/32 network=5.6.7.8/32 ... - blows my mind.

Am I so out of date in my networking knowledge that this is normal across IP networking? Or is this peculiar to MikroTik/RouterOS?

Anyway, does any of this help us solve why MikroTik3B doesn't even try to initiate its WireGuard peer/client connection outbound to MikroTik4?