WireGuard client reports "Packed has unallowed source IP" coming through MikroTik

RouterOS
1

These log messages are coming from the Windows WireGuard client (from WireGuard.com), but the WireGuard tunnel which provokes these messages has one of my MikroTik routers as its Peer.

RouterOS 7.23.1

These messages/ messages like these appear occasionally in the WireGuard Windows client Log:

2026-06-05 23:38:17.325: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (142.251.140.238) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.325: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (13.83.125.1) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.325: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (142.251.142.42) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.325: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (50.85.242.216) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.325: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (216.239.36.145) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.325: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (142.251.140.238) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.326: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (34.107.243.93) from peer 1 (83.41.122.160:56306)
2026-06-05 23:38:17.326: [TUN] [MikroTik2WG-NOdefRoute] Packet has unallowed src IP (34.107.243.93) from peer 1 (83.41.122.160:56306)

2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (23.46.85.217) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (23.45.153.96) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (23.45.153.96) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (23.45.153.96) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (23.45.153.96) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (138.197.66.20) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (138.197.66.20) from peer 2 (83.40.90.106:56306)
2026-06-05 22:44:40.193: [TUN] [MikroTik4WG-NOdefRoute] Packet has unallowed src IP (34.107.221.82) from peer 2 (83.40.90.106:56306)

2026-06-04 18:34:04.793: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (216.239.36.145) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (216.239.36.145) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (216.239.36.145) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (216.239.36.145) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (138.197.66.20) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (107.170.69.16) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (52.123.159.129) from peer 1 (73.80.148.50:56306)
2026-06-04 18:34:04.798: [TUN] [MikroTik3WG-NOdefRoute] Packet has unallowed src IP (138.197.66.20) from peer 1 (73.80.148.50:56306)

The MikroTik2WG-NOdefRoute, MikroTik3WG-NOdefRoute, MikroTik4WG-NOdefRoute are WireGuard Windows client configurations, peers configured on the Windows client for three of my different MikroTik routers (all running the same software and effectively the same configurations).

Here's a representative WireGuard 'server' configuration from my MikroTik2:

[admin@MikroTik2] /interface/wireguard> print detail
Flags: X - DISABLED; R - RUNNING
0 R name="wg1" mtu=1420 listen-port=12345 public-key="sCHAgUkqEf....................DjC900V219Aozk="

.. and the peer/ configuration for this Windows client:

[admin@MikroTik2] /interface/wireguard/peers> print detail where name="JayThinkT16-WG-MTik2"
Flags: X - DISABLED; D - DYNAMIC
1 interface=wg1 name="JayThinkT16-WG-MTik2" public-key="bCDnh..............................N4J2zFSo=" endpoint-address="" endpoint-port=0
current-endpoint-address=95.33.36.24 current-endpoint-port=58620 allowed-address=192.168.254.51/32 persistent-keepalive=30s client-endpoint=""
client-allowed-address=::/0 responder=yes rx=2621.4KiB tx=6.9MiB last-handshake=2d22h24m47s

(Ignore the old last-handshake; I just hadn't conneted lately when I took this print output).

And the MikroTik2WG-NOdefRoute configuration on the Windows client:

[Interface]
PrivateKey = {privateKey}
Address = 192.168.254.51/32
DNS = 192.168.254.3

[Peer]
PublicKey = {publicKey}
PresharedKey = {presharedKey}
AllowedIPs = 192.168.254.0/24
Endpoint = http://mikrotik2-dyn.felines.org:12345

So, the Windows client only expects the /24 LAN on its MikroTik WireGuard peer MikroTik2 to come through this tunnel.

Routes on the MikroTik relating to WireGuard:

[admin@MikroTik2] /ip/route> print detail where gateway="wg1"
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
2 As ;;; WireGuard VPN route through BCN for Bremen/MikroTik3B temp June 2026
dst-address=192.168.251.0/24 routing-table=main gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

3 As dst-address=192.168.254.51/32 routing-table=main pref-src=192.168.254.50 gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

5 As dst-address=192.168.255.0/26 routing-table=main gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

6 As dst-address=192.168.255.64/26 routing-table=main gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

7 As dst-address=192.168.255.128/26 routing-table=main gateway=wg1 immediate-gw=wg1 distance=1 scope=30 target-scope=10

DAc dst-address=192.168.255.142/32 routing-table=main gateway=wg1 immediate-gw=wg1 distance=0 scope=10 target-scope=5
local-address=192.168.255.142%wg1

MikroTik2's overall situation is as a single IP client of some common ISP; nothing is routed to MikroTik2 from the Internet/ from the local LAN between the ISP router and the MikroTik2 except response packets to traffic generated outbound from behind MikroTik2. So, these 'unallowed source IP' packets that the Windows WireGuard client claims came through the peered-with-MikroTik2/3/4 routers should not have been sent towards the Windows WireGuard client by my MikroTiks.

Has anyone else seen seemingly spurious 'unallowed source IP' warnings on a WireGuard client (of any source) for packets coming through a WireGuard tunnel to a MikroTik router?

Do you see something in my configurations about which would actually mis-route packets from the MikroTik through this Windows WireGuard client's WireGuard tunnel ?

thanks,

2

One more note - this seems to happen, each time I connect the Windows WireGuard client to a MikroTik router WireGuard responder peer, only right at the beginning of the WireGuard tunnel connection. The packets do not seem to recur after that, until after disconnecting and later reconnecting the WireGuard tunnel.

3

Yep, but WHO is actually sending you these packets?

this is a Google bot.

this is a Google CDN

these are Microsoft

this is Microsoft Azure

etc.

I am not saying that "it is OK", but the fact that they come from these sources might mean that they have some "particular" ways to "probe" your network.

4

That the sources are okay is perhaps a relief, though I was already fairly sure of that;

The real question is: What in my configuration, or a bug in RouterOS perhaps, is misrouting these packets through this WireGuard tunnel?

5

Those remote IP addresses are from the big CDNs. I think those are response packets to outgoing connections that your Windows PC (the one running the WireGuard client) was making. It could be that when the WireGuard Windows client starts the tunnel, it at first installs the default route over the tunnel, before modifying the Windows route table and keep only the one with destination 192.168.254.0 netmask 255.255.255.0. So for a short moment, apps on the PC sends their outgoing connections through the tunnels. The return packets from the remote hosts of those connections are blocked by the Allowed IPs filter of the WG client. Later the default route is removed and the problem no longer happens.

You can run TCP View from Microsoft Sysinternals and start the tunnel to see whether there are apps making connections to the same remote IP addresses that will be logged by the WireGuard client.

6

TCPView did catch one connection (it happens to be from Signal), but all of those CDNs are unsurprising to see with connections from this Windows client.

It's an interesting theory that the WireGuard Windows client might set up a wrong route briefly; though, why would a VPN client ever set up a default route if default routing is not in the configuration? Poor quality coding is one thing; but I can't think of how that would make sense, since the specific routes needed are known in advance.

I searched for ways to log/monitor Windows routing table changes; there does not seem to be any standard way to do this :-/ I wrote a little script to run "route print" every second. This, of course, is not nearly granular enough, but over ten or so WireGuard tunnel up/down transitions, I never saw a wrong default route.

Any ideas on how to monitor the Windows routing table?

7

I've repeated packet captures on the MikroTik 'server' peer of the WireGuard tunnel on which the Windows client reports these unallowed IPs, sniffing only for tx, src IP ! the MikroTik's local LAN, dst IP the WireGuard client, and the reverse; nothing is ever found.

I'm beginning to think this is a bug in the WireGuard Windows client, complaining about packets that aren't actually coming through the WireGuard tunnel...

I'll look for a WireGuard forum, and if I come up with anything, I'll post back here.

Any other diagnostic ideas still much appreciated!