Remote WinBox access over WireGuard?

RouterOS Beginner Basics
1

Okay. True confessions time. I’ve been trying to set up a multi-site WireGuard network for some months now.

I’ve made progress. The links are up and working. I can ping the various site routers from each other. I can ping devices on the LANs from the routers. But I can’t seem to pass data between the devices over the WireGuard links.

I think that if I could just get all of the routers on Winbox, from the same location, at the same time then I could work this out in short order. But I still haven’t figured out how to set the firewalls to allow that. I’m having to go to one location, make a change; go to the next location, make a change; and so forth. It’s frustrating.

Go ahead and give me a dunce cap, it’s probably some very easy tweak/setting that I’ve just overlooked. Sometimes I guess you’ve just got to be willing to be laughed at…

2

I’m far from an actual guru here, but I will save the real gurus the time and ask you to please post your anonymized config:

/export file=config

Remove serial number, wireguard keys, dynamic dns entries, public IPs, passwords, etc.

I would first check the interface list priviledges:

[admin@RB5009-212-New] /tool/mac-server/mac-winbox> print
  allowed-interface-list: TRUSTED

And make sure that the wireguard interface is a member of TRUSTED (or whichever interface-list is now showing).

3

@ehbowen; Yeah, remote access over WireGuard can definitely be a bit tricky to get just right. Here are a few key things to check:

  1. Since remote management like Winbox targets the router itself, you need to explicitly allow that in the firewall “input” chain for each router. For example:
/ip firewall filter add chain=input src-address=<peer-IP-or-subnet> protocol=tcp dst-port=8291 action=accept comment="Allow Winbox over WireGuard"

Or allow traffic from the WireGuard interface:

/ip firewall filter add chain=input in-interface=wireguard1 action=accept comment="Allow WG input"

Alternatively, if you have multiple subnets or IPs to allow, you might want to use an address list instead. Create the address list:

/ip firewall address-list
add list=Allowed_Winbox_Subnets src-address=10.100.100.0/24
add list=Allowed_Winbox_Subnets src-address=10.200.200.0/24
add list=Allowed_Winbox_Subnets src-address=192.168.88.0/24

Then use “src-address-list=Allowed_Winbox_Subnets” in your firewall rule like this:

/ip firewall filter
add chain=input src-address-list=Allowed_Winbox_Subnets  protocol=tcp dst-port=8291 action=accept comment="Allow Winbox access from trusted subnets"

You can then add or remove subnets/IPs from the address list without touching the firewall rule itself which much easier to maintai


2. Make sure Winbox isn’t restricted under “/ip service” and just allow those subnets via the firewall:

/ip service set winbox address=0.0.0.0/0

Or restrict it to trusted subnets only:

/ip service set winbox address=<subnet1>/24,<subnet2>/24,...

Firewall rules are processed top-down. If your “drop all” rule is above the “allow Winbox” rule, it will block you. Move your allow rules above any general drops in the “input” chain.

  1. Verify that WireGuard peers have the correct “Allowed Address” ranges for all your subnets, and that routing is in place so the packets actually reach the router.


    Once those are set up, you should be able to reach each site’s router via Winbox through the WireGuard tunnel.
4

That’s probably a couple of hours of work, at least, but I’ll start on it.

5

Do you mean the “sanitizing” of export.rsc?

I use a notepadd++ script that I wrote. Well, I didn’t exactly write it: I had it record a long series of find/replace. It takes longer to issue the export command and download the file than to open the file in notepad++ and execute the sanitizing script (and the entire process takes ~75 seconds).

6

Yes
/export file=anynameyouwish ( minus serial number, any public WANIP information, wireguard keys ).

WHich mean
a. serial number one entry at beginning of config
b. WANIP information, so removed any PUBLIC wan ip information → could be in IP DHCP Client text, IP route text ( public IP address or public IP gateway, or if PPPOE any credentials )
c. wireguard private and public keys.

Thats it. Not that much work really
Also recommend for sanity of users if you have

  1. long dhcp lease lists …remove those just noise
  2. Scripts that have nothing to do with USING the router.

For the most part you will note that Export removes all other sensitive items.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Larsa gave a good generic response to a generic question. However your situation is very specific and complex and good luck trying to shove a round peg into a square hole :stuck_out_tongue_winking_eye:

With 10 routers and specific servers and devices needed access to those servers and of course admin to be able to access all, an IP based approach is a nightmare.

Accessing other routers via winbox for config purposes, OR all other subnets to work on servers for example, is accomplished by ensuring that at each router you have identified the trusted subnets

Typically
management-vlan=TRUSTED ( no explanation needed - local )
OFFBridgePort =TRUSTED ( no explanation needed - local )
Wireguard=TRUSTED ( remote admin coming in for router config, remote admin coming in to work on servers, generic users accessing speific servers for work )

In order to keep it simple but maintaining security, one should see that although Wireguard is considered Trusted, there is a caveat, we allow generic users to come in on wireguard.
Thus it is imperative on each router, on the forward chain to NOT let users go out wireguard carte blanche, but ONLY with specific forward chain rules.
In this way they will exit the wireguard tunnel at any router and only be allowed to reach the destination address permitted.

In this manner one does not need to maintain long assed lists of admin IP addresses one has on each router, which would need to be put on every router…

These rules allow the admin to reach both the config and servers locally and the same remotely over wireguard.
They also allow any user to come exit the router and go to the LAN destination they have been allowed to visit on their home router forward chain firewall rules.

/input chain
add chain=input action=accept in-interface-list=TRUSTED
/forward chain
add chain=forward action=accept in-interface-list=TRUSTED out-interface-list=LAN

This relies on ensuring at each router, you only let local users, in non-trusted subnet, access to needed specific subnets in the forward chain over wireguard.
/forward chain
add chain=forward action=accept comment=“iot R1 to iotServerR2” in-interface=vlan-IOT-r1 dst-address=ServerR2 out-interface=wireguard
add chain=forward action=accept comment=“camerasR1 to CameraServerR3” in-interface=vlan-Camera-r1 dst-address=ServerR2 out-interface=wireguard.

In this way, no matter where you as the admin are located ( working at the managment vlan or offbridge port), you can reach any other router for config purposes or any LAN subnet for working on servers etc. All other users are restricted to the subnets on the routers they need access to.

This is as efficient and easy as it gets.

7

@ehbowen, fixing the export is actually pretty easy. Here’s a guide on how to do it: “How to export your Mikrotik config and share it (Step-by-Step guide)”

8

duplicate.

9

If Joseph you are asking a different question, can one see all the routers at one time via winbox, via wireguard, in order to select for configuring, the answer is no. Those protocols dont go over wireguard.

10

Thanks, but I asked that question over a year ago and learned about the Winbox/ip-neighbors protocols and EOIP as a solution to wanting to see the MT devices in winbox across a wireguard solution.

I had it implemented for a while, but then I learned about the downsides to EOIP and thought it wasn’t worth keeping in place.