WireGuard frustration

RouterOS General
1

I’m likely missing something simple, but I followed the RouterOS documentation to set up a WireGuard peer (i.e., an iOS device) that will be connecting to reach internal resources. The client authenticates properly, so I think there are no problems in the WireGuard setup:

/interface wireguard
add listen-port=59703 mtu=1420 name=homevpn
/interface wireguard peers
add allowed-address=0.0.0.0/0 interface=homevpn public-key="…"

However, traffic from the client goes nowhere. I have firewall rules that allow WireGuard traffic:

/ip firewall filter
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="Allow WireGuard" dst-port=59703 protocol=udp
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="Allow VLAN" in-interface-list=VLAN
add action=drop chain=input comment="drop all else"
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=forward comment="VLAN Internet access" connection-state=new in-interface-list=VLAN out-interface-list=WAN
add action=accept chain=forward comment="VPN to COMMON_VLAN" in-interface=homevpn out-interface=COMMON_VLAN
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="defconf: drop bad forward IP addresses" src-address-list=no_forward_ipv4
add action=drop chain=forward comment="defconf: drop bad forward IP addresses" dst-address-list=no_forward_ipv4
add action=drop chain=forward comment="drop everything else"

In the above rules, COMMON_VLAN is 192.168.2.0/24 and contains all of the resources the VPN client needs to access. Please refer to the interface lists below for the rest:

/interface list member print
Columns: LIST, INTERFACE
# LIST     INTERFACE  
;;; defconf
0 LAN      bridge     
;;; defconf
1 WAN      ether1     
2 VLAN     BASE_VLAN  
3 VLAN     COMMON_VLAN

I also defined an IP address for the WireGuard interface and a route to it was dynamically created:

/ip address
add address=192.168.10.1/24 interface=homevpn network=192.168.10.0
/ip route print
Flags: D - DYNAMIC; A - ACTIVE; c, s, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS      GATEWAY      DISTANCE
0  As 0.0.0.0/0        xx.yy.zz.94          1
  DAc xx.yy.zz.88/29    ether1              0
  DAc 192.168.2.0/24   COMMON_VLAN         0
  DAc 192.168.10.0/24  homevpn             0

Is it because the bridge is performing VLAN filtering? The WireGuard interface is not part of the bridge, but adding it wasn’t part of the office-to-office example in the RouterOS documentation, so I assumed it wasn’t necessary. (The WireGuard interface doesn’t appear when autocompleting the interface, so I’m not certain whether it’s intended to be part of a bridge.) All VLAN tagging occurs further downstream at the switch.

2

I don’t see anything clearly wrong here. Maybe it’s something on client side? And no, WG can’t be bridged.

3

Thank you for the sanity check. I’ll try with a different client on a remote Linux system. The WireGuard app in iOS has terrible documentation, so it’s possible something is off that doesn’t affect the tunnel setup.

4

Disagree the wireguard app in IOS is dirt simple.
What part of it confuses you??

What I dont get is your allowed IPs on the MT server
add allowed-address=0.0.0.0/0 ??

Why did you choose this. I am assuming you have specific wireguard clients that will be connecting to your server.
Thats what should be indicated in allowed peers.
In other words, its not clear who is using the tunnel and which traffic is flowing through it etc…

Further, if I dont see the whole config a proper assessment cannot be provided
/export file=anynameyouwish

5

As indicated by Anav, the problem is likely to be found here (could be other parts of your config are also acting up)

/interface wireguard peers
add allowed-address=0.0.0.0/0

Pretty sure that part is not in the RouterOS documentation to set up a WireGuard peer.
At the very least allowed address should only have the IP address you assigned to your iPhone (or that subnet, if you have multiple peers).

You also did not show the peer config on iOS ?

6

https://forum.mikrotik.com/viewtopic.php?t=182340

7

It turned out the problem was with a firewall raw rule. I was dropping all traffic that wasn’t from the VLAN, WAN, or LAN interface lists and I neglected to add the WireGuard interface to any of these (i.e., I knew it was something simple). That said, I think I’m going back to IPSec because WireGuard is much slower on my hEX S, at least when the client is on cellular.

To address my complaint about the iOS WireGuard client, I agree it’s simple if you’ve ever configured a WireGuard client before. However, there’s no documentation in the app itself; just field labels. For instance, it’s not obvious what the Addresses field is for in the Interface section unless you already know from the WireGuard man page.

As for why I allowed 0.0.0.0/0, it’s because I need to grant access to a cellular device and I don’t know necessarily know what network it will be on at any given time. Is there a more secure way to do this?

8

Well that is the whole point of using wireguard.
The address is what you use to FIX or make STATIC the mobile device IP, so that you DO KNOW what the IP will be.

For example on my iphone the address is FIXED and falls within the subnet IP address for the wireguard interface on my MT server router.
Hence, the MT server knows exactly what IP address is coming in as source address from the cellular device. Do not worry whether or not you are in a coffed shop, airport etc…

9

Working through this has been enlightening, and thanks for the intro guide!

EDIT: It’s too early for me to comprehend language, so I originally thought the use case for WireGuard was different.

10

After spending large part of an evening this week getting IPSEC/IKEv2 working between mAP roughly 220km away and Azure (BTW I did get it running ), Wireguard is BY FAR easier to setup and much more clear in what needs to be done where. Speedier too (I made sure to have a WG connection to that Tik device in parallel, so I could make that setup from home and compare the performance too).
The fact alone that stupid Azure requires 2-way public IPs for setting up a tunnel whereas WG is more then happy with only 1 part visible…

My view.

11

Have you heard of any plans for hardware acceleration for WireGuard? I seem to recall reading it uses ChaCha20, which is not one of the ciphers that can be offloaded from the CPU.

12

No its strictly a software driven entity, its faster than most other VPNS that I have used.

13

I’ll continue testing in different locations. I could just have crap cellular signal here, because the outgoing pipe from this network is 300 Mbps and should be mostly clear.