WireGuard, routes through, but the MikroTiks themselves can't ping each other

RouterOS
1

Just starting with WireGuard, to replace ages-old, rock-solid reliable, but slow-as-**** SSTP.

Two MikroTik RouteROS 7.23 devices, "MikroTik4" (WireGuard responder), and "MikroTik3B" (WireGuard client).

On MikroTik4:

[admin@MikroTik4.felines.org] > /interface/wireguard/print detail
Flags: X - DISABLED; R - RUNNING
0 R name="wg1" mtu=1420 listen-port=56106 public-key="....."

[admin@MikroTik4.felines.org] > /interface/wireguard/peers/print detail
Flags: X - DISABLED; D - DYNAMIC
0 interface=wg1 name="MikroTik3BWG" public-key="....." endpoint-address="" endpoint-port=0 current-endpoint-address=95.33.x.x current-endpoint-port=59366
allowed-address=192.168.251.0/24 persistent-keepalive=30s client-endpoint="" client-allowed-address=::/0 responder=yes rx=44.4MiB tx=81.1MiB last-handshake=57s

[admin@MikroTik4.felines.org] > /ip addr print
Flags: D - DYNAMIC; S - SLAVE
Columns: ADDRESS, NETWORK, INTERFACE, VRF
;;; defconf
0 S 192.168.255.5/26 192.168.255.0 ether2 main
1 192.168.255.124/26 192.168.255.64 bridge main
2 D 192.168.255.54/32 192.168.255.55 <sstp-mikrotik3.local> main
3 D 192.168.255.52/32 192.168.255.53 <sstp-mikrotik2.local> main
;;; MikroTik4WG-MikroTik3B
4 192.168.255.140/26 192.168.255.128 wg1 main

[admin@MikroTik4.felines.org] > /ip route/print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC, v - VPN
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE

0 As 0.0.0.0/0 192.168.255.7 main 1
DAv 10.0.0.0/24 192.168.255.55 main 3
1 As 192.168.251.0/24 wg1 main 1
DAv 192.168.253.0/24 192.168.255.55 main 2
DAv 192.168.254.0/24 192.168.255.53 main 3
DAc 192.168.255.0/26 bridge main 0
DAc 192.168.255.53/32 <sstp-mikrotik2.local> main 0
DAc 192.168.255.55/32 <sstp-mikrotik3.local> main 0
DAc 192.168.255.64/26 bridge main 0
DAc 192.168.255.128/26 wg1 main 0

On MikroTik3B:

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

[admin@MikroTik3B] > /interface/wireguard/peers/print detail
Flags: X - DISABLED; D - DYNAMIC
0 interface=wg1 name="MikroTik4WG" public-key="....."
endpoint-address=something.felines.org endpoint-port=56106 current-endpoint-address=33.40.90.106
current-endpoint-port=56106 allowed-address=0.0.0.0/0 persistent-keepalive=30s client-endpoint=""
client-allowed-address=::/0 rx=26.1MiB tx=2381.9KiB last-handshake=1m42s

admin@MikroTik3B] > /ip address/print
Flags: X - DISABLED; S - SLAVE
Columns: ADDRESS, NETWORK, INTERFACE, VRF
;;; defconf
0 X 192.168.88.1/24 192.168.88.0 bridge main
1 S 192.168.251.3/24 192.168.251.0 WiFi2 main
2 192.168.178.201/24 192.168.178.0 ether1 main
;;; MikroTik3BWG-MikroTik4
3 192.168.255.141/26 192.168.255.128 wg1 main

[admin@MikroTik3B.felines.org] > /ip route/print
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE

0 Xs 192.168.255.0/26 sstp-out1 2
1 As 0.0.0.0/0 192.168.178.1 main 1
DAc 192.168.178.0/24 ether1 main 0
DAc 192.168.251.0/24 bridge main 0
2 Is 192.168.254.0/24 sstp-out1 main 3
3 As 192.168.255.0/26 192.168.255.140 main 1
DAc 192.168.255.128/26 wg1 main 0

A client on MikroTik3B's wireless network, with an IP address provided by MikroTik3B's DHCP server, 192.168.251.139/24, with default route via MikroTik3B (192.168.251.3), can traceroute through MikroTik3B, over the MikroTik3B-MikroTik4 WireGuard VPN, to a hote on MikroTik4's local 192.168.255.0/26 LAN:

C:>tracert -d 192.168.255.37

Tracing route to 192.168.255.37 over a maximum of 30 hops

1 3 ms 1 ms 1 ms 192.168.251.3
2 52 ms 51 ms 52 ms 192.168.255.140
3 52 ms 51 ms 51 ms 192.168.255.37

Trace complete.

And, while the above trace is going on, sniffer output on MikroTik4 shows the traffic going through:

77.796 wg1 192.168.251.139 192.168.255.37 icmp 92 0
77.796 wg1 192.168.255.140 192.168.251.139 icmp 120 0
77.849 wg1 192.168.251.139 192.168.255.37 icmp 92 0
77.849 wg1 192.168.255.140 192.168.251.139 icmp 120 0
77.905 wg1 192.168.251.139 192.168.255.37 icmp 92 0
77.905 wg1 192.168.255.140 192.168.251.139 icmp 120 0
78.912 wg1 192.168.251.139 192.168.255.37 icmp 92 0
78.912 wg1 192.168.255.37 192.168.251.139 icmp 92 1
78.965 wg1 192.168.251.139 192.168.255.37 icmp 92 0
78.966 wg1 192.168.255.37 192.168.251.139 icmp 92 1
79.02 wg1 192.168.251.139 192.168.255.37 icmp 92 0
79.02 wg1 192.168.255.37 192.168.251.139 icmp 92 1

So, we know that the WireGuard tunnel is working, and that MikroTik4 can see MikroTik3B's WireGuard IP address.

But MikroTik3B cannot ping MikroTik4, neither on its LAN IP 192.168.255.5 nor its WireGuard IP 192.168.255.140, nor can MikroTik3B ping the same host on the LAN on the other side of MikroTik4 that we successfully tracerouted just above:

[admin@MikroTik3B] /tool/sniffer> /ping 192.168.255.5
SEQ HOST SIZE TTL TIME STATUS
0 192.168.255.5 timeout
sent=1 received=0 packet-loss=100%

[admin@MikroTik3B] /tool/sniffer> /ping 192.168.255.37
SEQ HOST SIZE TTL TIME STATUS
0 192.168.255.37 timeout
sent=1 received=0 packet-loss=100%

[admin@MikroTik3B] /tool/sniffer> /ping 192.168.255.140
SEQ HOST SIZE TTL TIME STATUS
0 192.168.255.140 timeout
sent=1 received=0 packet-loss=100%

.. even though we do see the ping packets going out the wg1 interface on MikroTik3B (from sniffer):

[admin@MikroTik3B] /tool/sniffer> pack print
Columns: TIME, INTERFACE, SRC-ADDRESS, DST-ADDRESS, IP-PROTOCOL, SIZE, CPU
0 2.946 wg1 192.168.255.141 192.168.255.140 icmp 56 1
1 3.949 wg1 192.168.255.141 192.168.255.140 icmp 56 0
2 4.952 wg1 192.168.255.141 192.168.255.140 icmp 56 0

On MikroTik4, sniffing, we do NOT see packets coming in:

[admin@MikroTik4.felines.org] /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: wg1
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: !winbox
filter-src-port:
filter-dst-port:
filter-vlan:
filter-cpu:
filter-size:
filter-direction: any
filter-operator-between-entries: and
quick-rows: 20
quick-show-frame: no
running: yes

[admin@MikroTik4.felines.org] /tool/sniffer> pack print follow
TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU

[ no output ] ^C

(I've tried a wide variety of sniffer configurations, "anything on wg1", "anything from ", and others; nothing ever appears in the sniffer output on MikroTik4).

I don't think it's firewall filter or NAT rules:

[admin@MikroTik4.felines.org] /ip/firewall/filter> print
Flags: X - DISABLED, I - INVALID; D - DYNAMIC
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough

1 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related,untracked

2 ;;; defconf: accept to local loopback (for CAPsMAN)
chain=input action=accept dst-address=127.0.0.1

3 ;;; Allow Felines internal networks to access this MikroTik
chain=input action=accept src-address-list=FelinesVPNnets log=no log-prefix=""

7 ;;; Accept WireGuard
chain=input action=accept protocol=udp dst-address=192.168.255.5 in-interface=bridge dst-port=56106 log=yes log-prefix="wg1"

12 ;;; Drop all other attempts to talk directly to this MikroTik itself
chain=input action=drop log=no log-prefix=""

13 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid

14 ;;; defconf: accept ICMP
chain=input action=accept protocol=icmp

15 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN

18 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related

19 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked

20 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid

21 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN

The chain=input action=accept rule #3 allowing src-address-list=FelinesVPNnets includes both MikroTik3B's LAN 192.168.251.0/24 and all of MikroTik4's 192.168.255.0, .64, and .128 /26 nets.

Is there some limitation of the RouterOS WireGuard implementation that makes the participating MikroTiks themselves unable to ping or traceroute each other via WireGuard tunnels? Or have I got the configuration mostly right, but some small part is wrong which allows the networks on both sides of the two MikroTiks to communicate successfully over the WireGuard tunnel, but blocks the MikroTiks themselves from talking with each other?

thank you,

2

You should edit your post and redact the public IP address and domain name in the MikroTik3B print output!

No.

Here is your problem. When MikroTik3B pings MikroTik4, it will use 192.168.255.141 as the source address of the packet, because 192.168.255.141/26 is configured on wg1 under /ip address. But the associated WireGuard peer on MikroTik4 explicitly says that it only accepts source addresses in the 192.168.251.0/24 range.

You need to edit the peer on MikroTik4 to include at least 192.168.255.141/32 too. Set allowed-address=192.168.251.0/24,192.168.255.141/32 for that peer.

The WG configuration on MikroTik3B does not have the problem because it has allowed-address=0.0.0.0/0 which accepts everything.

3

Thank you, @CGGXANNX . That fixed MikroTik3B's (in)ability to ping MikroTik4.

[ EDIT: I seem to have had the keypair wrong for the Windows client WireGuard configuration; WinDump showed data going "into the tunnel" but it wasn't being accepted at all on the WireGuard server end; @MikroTik it would be nice if each WireGuard Peer would have a clearer Status display; I had to notice that either the malfunctioning WireGuard peer(client)'s "Current Endpoint Address" was empty/out-of-date or that the "Last Handshake" was too long ago/never, to realize that the tunnel wasn't really up). ]

Apart from that, it now "works", except for just one thing:

Attempting to traceroute through the WireGuard tunnel to anything on the other side of the tunnel works except for the first hop, which should get an ICMP TTL Expired packet back from the WireGuard endpoint on the MikroTik router. That one packet does not come back; sniffing on the MikroTik does not see the router responding to that one packet, though it does correctly forward the next-hop packets which allows the rest of the traceroute to complete.

This WireGuard client's WireGuard tunnel IP address is included in lists which are allowed in an input chain rule on the MikroTik; its tunnel IP address is included in a route on the MikroTik to go back out through the single WireGuard interface; routes on the client are correct; client firewall rules are open; ...

Why would that one hop, the RouterOS WireGuard IP address itself, not respond to the first-hop traceroute packets from this Windows client?

Thanks,
-Jay

All the below is now irrelevant, in light of the above.

I'm still seeing what looks like a similar problem on a Windows client, running the reference Windows client implementation from the WireGuard.com website, configured as a Peer on MikroTik4:

interface=wg1 name="JayThinkT16WG" public-key="....." endpoint-address="" endpoint-port=0 current-endpoint-address="" current-endpoint-port=0
allowed-address=192.168.255.151/32 persistent-keepalive=30s client-endpoint="" client-allowed-address=::/0 responder=yes rx=0 tx=0

When this JayThinkT16WG client is connected, it gets the following:

IPCONFIG:

Unknown adapter MikroTik4WG-NOdefRoute:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WireGuard Tunnel
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::8f04:723a:e4da:3fd9%55(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.255.151(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.192
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Enabled

ROUTE:

IPv4 Route Table

Active Routes:
Network Destination Netmask Gateway Interface Metric
192.168.255.0 255.255.255.192 On-link 192.168.255.151 5
192.168.255.64 255.255.255.192 On-link 192.168.255.151 5
192.168.255.128 255.255.255.192 On-link 192.168.255.151 5

But:

C:\>ping 192.168.255.5

Pinging 192.168.255.5 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.255.5:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

And, while that ping is going on, on the Windows client:

C:>windump -i8 icmp or udp
windump: listening on \Device\NPF_{E5AB9D61-CFD4-AAEF-669E-8BEED8579C9D}
09:58:32.512346 IP 192.168.255.151 > 192.168.255.5: ICMP echo request, id 2, seq 20855, length 40
09:58:37.413597 IP 192.168.255.151 > 192.168.255.5: ICMP echo request, id 2, seq 20856, length 40

But, on MikroTik4:

[admin@MikroTik4.felines.org] /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: wg1
filter-mac-address:
filter-src-mac-address:
filter-dst-mac-address:
filter-mac-protocol:
filter-ip-address: 192.168.255.151/32
filter-src-ip-address:
filter-dst-ip-address:
filter-ipv6-address:
filter-src-ipv6-address:
filter-dst-ipv6-address:
filter-ip-protocol:
filter-port: !winbox
filter-src-port:
filter-dst-port:
filter-vlan:
filter-cpu:
filter-size:
filter-direction: any
filter-operator-between-entries: and
quick-rows: 20
quick-show-frame: no
running: yes

[admin@MikroTik4.felines.org] /tool/sniffer> pack print follow
TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
[ no output ]

So, the Windows WireGuard client is sending the ping packets from its WireGuard client configuration-assigned 192.168.255.151 address, which does appear in the MikroTik4 WireGuard VPN server's Peer entry allowed-address list, and there's a route through the WireGuard tunnel, but the packets don't seem to go anywhere.

What am I missing this time?

Regarding the security warning that you gave, other than providing a small degree of lack-of-obscurity, what is the threat model against which redacting public IP addresses and domain names in the MikroTik3B print output would be defending?

Of course I agree that we shouldn't make surveillance too easy for adversaries; but I always assume that anything that is publicly exposed can and will be found, and that the security has to be in the exposed services, not in trying to obscure their existence. Is it just a minor principled disagreement, or am I missing something important about the (in)security of exposed MikroTik services?

Thanks for everything!

4

That "Last Handshake" has value (not 00:00:00) and is recent (no more than two minutes, the hardcoded Rekey Interval in WG is 120 seconds) is a reliable way to know that the tunnel is running and the key pair are ok.

I cannot reproduce this problem with my WG site-to-site or road warrior setups (tested with Windows tracert as well as traceroute and tracepath under Linux). It might be due to some firewall related settings?

5

Thanks again.

I'm still interested in your reasons for suggesting to redact the public domain name and IP address information?

[ EDIT even before posting this time! :sweat_smile: I figured it out:

The problem was that, before I had realized that this Windows client was completely failing to connect to the WireGuard server due to bad key exchange, I had removed 192.168.255.128/26 from the AllowedIPs, just in case that was causing an overlap with some kind of automagic routing. And then I had left it out. And of course it wasn't *creating* any automagic routing because WireGuard doesn't do that; it did explicitly have to be there. :person_facepalming:

]

{ what I would have posted, which is now irrelevant }:

Here is the MikroTik4 firewall ruleset:

[admin@MikroTik4.felines.org] > /ip firewall/filter/print
Flags: X - DISABLED, I - INVALID; D - DYNAMIC
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough

1 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related,untracked

3 ;;; Allow Felines internal networks to access this MikroTik
chain=input action=accept src-address-list=FelinesVPNnets log=no log-prefix=""

7 ;;; Allow WireGuard VPN connection attempts
chain=input action=accept protocol=udp dst-address=192.168.255.5 in-interface=bridge dst-port=56106 log=yes log-prefix="wg1"

12 ;;; Drop all other attempts to talk directly to this MikroTik itself
chain=input action=drop log=no log-prefix=""

13 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid

14 ;;; defconf: accept ICMP
chain=input action=accept protocol=icmp

15 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN

18 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related

19 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked

20 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid

21 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN

In the firewall filter rule above:

3 ;;; Allow Felines internal networks to access this MikroTik
chain=input action=accept src-address-list=FelinesVPNnets log=no log-prefix=""

The address-list FelinesVPNnets includes 192.168.255.128/26, which includes the IP address of the WireGuard Windows VPN client.

So, I don't see anything in the firewall that could cause the problem?

Hm, though this might give a hint; on the Windows client:

C:>tracert 192.168.255.5

Tracing route to mikrotik4-int.felines.org [192.168.255.5]
over a maximum of 30 hops:

1 52 ms 53 ms 52 ms mikrotik4-int.felines.org [192.168.255.5]

Trace complete.

C:>tracert 192.168.255.140

Tracing route to MikroTik4WG [192.168.255.140]
over a maximum of 30 hops:

1 General failure.

Trace complete.

That the Windows client can traceroute to an IP address of the MikroTik itself, in a single hop which means that the trace has gone over the WireGuard tunnel, but it cannot trace to (nor ping) the MikroTik's own WireGuard IP address?

Also, I have two WireGuard Windows Peer setups for this one MikroTik4 WireGuard server, one with default route, the other without. It is only the Peer setup withOUT the default route that canNOT ping/trace the MikroTik WireGuard server IP address; the Peer setup with default route CAN traceroute through and ping directly to the MikroTik's WireGuard server interface IP address.

This is the client Peer setup with the default route:

[Interface]
PrivateKey = .....
Address = 192.168.255.151/26

[Peer]
PublicKey = .....
PresharedKey = .....
AllowedIPs = 0.0.0.0/0
Endpoint = something.felines.org:56106

And this is the Peer setup without the default route:

[Interface]
PrivateKey = .....
Address = 192.168.255.151/26

[Peer]
PublicKey = .....
PresharedKey = .....
AllowedIPs = 192.168.255.0/26, 192.168.255.64/26
Endpoint = something.felines.org:56106

The only difference is the AllowedIPs, being 0.0.0.0/0 with the default route, and ... Oh, Frotz.

The problem was that, before I had realized that this Windows client was completely failing to connect to the WireGuard server due to bad key exchange, I had removed 192.168.255.128/26 from the AllowedIPs, just in case that was causing an overlap with some kind of automagic routing. And then I had left it out. And of course it wasn't *creating* any automagic routing because WireGuard doesn't do that; it did explicitly have to be there. :person_facepalming:

Ugh.

Thanks as always.
-Jay

6

Ah, with the public IP address other people can figure out your ISP and city location (with help of some websites like https://iplocation.io/). For many people that's private information that they don't want to disclose.

And the DDNS domain you left in the export allows other to know your future IP addresses too, even when the ISP gives you new addresses.

It's mostly a privacy issue. But if your firewall is not secure, putting your public IP address / domain on this forum might invite others to try to exploit / DoS you. Your FW looks ok though, so this is not an issue.

7

Yeah, all true. I'm a very strange privacy person. (I mean, I'm a very strange person just in general, but: )

I've worked in the technology, business process, legal/regulatory, risk/compliance, and human factors aspects of data protection/ privacy for many years. Many of my professional peers fall a bit on the "very careful" side of the equation (not to say "paranoid").

I guess my extensive exposure to the near futility of actually hiding anything find-out-able (plus some true good fortune as to where I live, where I am in my career, etc, which allow me to not care very much what most people think about me) has placed me/ allowed me to fall rather far on the side of "It's not worth the effort to hide much". :innocent:

Thanks again for all the help!

The new WireGuard VPN setups are much more efficient than the old SSTP VPNs they replace. (Yes, I know, "If Woody,er, Jay, had gone right to the police, er, WireGuard, this would never have happened." :grin: )

8

So, my thoughts on WireGuard...

The efficiency is hard to argue with. (Except, the whole discussion in another of my threads here in the forum about MTU problems).

But it feels very much NOT "commercially ready", in the sense that it behaves quite differently from classic "routers" route, optionally via "firewalls", over "network links", in that WireGuard munges together all three - Allowed IPs being a kind of firewall filter, as well as in some cases setting routes, and of course the WireGuard tunnels themselves being network links.

It forces the administrator to learn a new way of thinking, that is different from all the old ones.

Also, possibly, this is worse with MikroTik's particular implementation of WireGuard, as MikroTik does enforce the implicit firewalling of the WireGuard tunnels' Allowed IPs settings, and does not implement the implied routing that e.g. the WireGuard reference Windows implementation does.

9

You're right. But wireguard's design intention was explicitly to create something new.

Be careful not to conflate wireguard itself, for which Mikrotik's implementation is very close to the official, and wg-tools, which is responsible for the route additions. On a dedicated router platform the latter doesn't really make much sense.

Wireguard is best viewed as a replacement for ipsec's data plane. (Hence it being in-kernel.) This is why the allowed-address acts as a firewall - it's essentially a policy selector.

WG also explicitly doesn't include the IKE(v2) part of the stack. This was left to user-space tools like Tailscale or Netbird.

I think it's altogether successful in its goals.

10

I think that part of why WireGuard strikes me as a bit self-conflicting is because I'm setting it up, for the first time, at the same time, both for router-to-router (MikroTik-to-MikroTik) AND client-to-router (Windows-to-MikroTik), and they behave rather differently.

Especially, on Windows, that the reference WireGuard client implementation has a misnamed checkbox about "blocking" all untunneled traffic which seems to UNblock untunneled traffic by having Allowed IPs include 0.0.0.0/1, 128.0.0.0/1, instead of the single 0.0.0.0/0. The result of which is that local network addresses (including DNS servers!) are completely unreachable in the "block untunneled traffic" configuration. Okay, yes, it's literally doing what it says, but the expectation with VPNs is rarely to completely block local traffic.

So, okay, I withdraw my suspicion of MikroTik's implementation, but retain my concern about how much breakage is caused by how "something new" WireGuard is, considering that it has to coexist with everything old ...

11

All vpns cause strange breakages under consumer operating systems. The same /1 trick is used by many vpn clients, e.g. the redirect-gateway def1 does the same for openvpn.

It's assumed that when you want to tunnel all traffic, you'll also supply a suitable dns server in your config, that's reachable through the tunnel. (Yes, this part is not particularly well documented.)

EDIT: And the /1 routes don't block local traffic, they block traffic that would leave through the default. (The /1 prefixes are longer than the /0 default, but shorter than the usual /24.)

12

I think that (and this seems to be a client implementation specific thing, rather than a How WireGuard Is Supposed To Work By Design thing) conflating higher-or-lower/ more-or-less-specific /routes, vs. really having "Block all local traffic because it would 'not go through the tunnel'" is a quite poor implementation choice. Routes should be routes. Block traffic if the tunnel fails (that's really what a kill switch is supposed to do) is something else. And "All/killswitch EXCEPT for defined local traffic" is pretty much a must-have except for pushed-by-corporate-central-IT to-keep-the-worker-from-Doing-Stupid-Things(TM) use cases...

It also could be desirable to mostly tunnel all traffic/ mostly killswitch, but still allow local DNS, for speed of DNS server response.

Anyway, thanks to everyone for the education, and interesting theory discussions!