Site to Site Wireguard Firewall Rules

RouterOS General
1

I’ve been struggling with this all day, I feel like I’m missing something fundamental.

I have two identical RB5009 set up across the world from each other, each running 7.1.1. I have had wireguard running on each of them successfully for several months now, but just using mobile phones, laptops (192.168.100.0/24). I followed this guide to set up site to site, and finding that firewall rules don’t seem to affect the traffic between sites.

I can ping between subnets from ‘Office 1’ to ‘Office 2’, configured as shown:

My firewall config is below (most is defconf). I expect Wireguard traffic to come in through rule 2, then go through the firewall rules again as local traffic. I expect that if the traffic is from my mobile Wireguard clients (each a /32 address in the 192.168.100.0/24 subnet), it is accepted and that if it’s from my other site (Office 2), then it will be dropped. However, all traffic gets through with this config.

I wonder if, because it’s two peers, that the traffic I’m expecting to be filtered in the firewall is considered an established connection due to the Office 1 to Office 2 tunnel? But it shouldn’t be, ‘Office 2’ traffic should be routed through its own Wireguard interface and not back through the already established connection from ‘Office 1’, right?

Firewall (Office 1)

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="wireguard server" dst-port=13231 in-interface-list=WAN protocol=udp
add action=accept chain=forward comment="wireguard mobile subnet to LAN" dst-address=172.16.0.0/16 src-address=192.168.100.0/24
add action=accept chain=input comment="defconf: accept ICMP" in-interface-list=!WAN protocol=icmp
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log=yes
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=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
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

IP addresses (Office 1)

/ip address
add address=172.16.0.1/16 comment=defconf interface=bridge network=172.16.0.0
add address=192.168.100.1/24 interface=wireguard1 network=192.168.100.0
add address=10.255.255.1/30 comment="wireguard site-to-site bridge" interface=wireguard1 network=10.255.255.0

Routes (Office 1)

/ip route
add disabled=no distance=1 dst-address=192.168.0.0/24 gateway=10.255.255.2 pref-src=0.0.0.0 routing-table=main scope=30 \
    suppress-hw-offload=no target-scope=10
2

Hi @ungo, welcome to the forum!

You may regard the tunnel as any standard LAN cable between two routers thus the firewall rules applies exactly in the same way as between ordinary subnets.

What do you want to achieve more precisely, ie is your objective to prevent (some/all) traffic from one office to the other or something completely different?

3

Why do you think that your current firewall should affect traffic from other site? Your current rules (in forward chain) do:

#1 - allows traffic from mobile clients (this should be after #4)
#2 - fasttracks established and related connections
#3 - allows rest of established, related and untracked connections
#4 - drops packets with invalid connection state
#5 - drops new connections from WAN, unless they are forwarded ports
#x - (implicit default action) allows everything else

Unless you added WG interface in WAN interface list, everything coming from there is allowed by #x.

4

If only he had read para 5 - https://forum.mikrotik.com/viewtopic.php?p=906311

5

Thanks for the welcome Larsa. I want to explicitly allow traffic between sites (e.g., an off-site backup) and deny everything else. A site-to-site config for wireguard would be accessible to anyone who compromised one side, so I would like to limit the damage if that ever happened.


That’s the fundamental thing I was missing - I was assuming a lot about the MT firewall, and didn’t expect it to be default open. This article really helped me nail it down further after your advice.


I did come across that a couple times in my searches, but I never made it to 5 before becoming overwhelmed by the volume. And I did get distracted reading the replies - if I had spent the amount of time that I did reading the replies in actually reading the OP, I would have been in good shape!


After some reading up on MT firewalls, I have a working config that I’m satisfied with. Deploying it to my remote site will be a bit tricky, hoping I don’t lock myself out!

Thanks to all of you for being so helpful.

6

Glad its working for you now!! Good job.
I am keen on how to make the above article better. I did try to state the topics at the top so that if one wanted info on firewalls they could go straight to that. I guess in your case you didnt know where the problems lied due to the fact there was firewall knowledge missing. Unfortunately that comes part and parcel of learning MT OS overall.
If you have any suggestions would love to hear them.

7

@ungo, glad to hear everything worked out!

One way to ensure that you are not completely locked out if something goes wrong is to create an additional wg tunnel just for your self to administer the remote site.

For example regarding admin access to office 2 create a new wireguard2 and set ip address of the peer to something like this "/ip address add address=192.168.100.2/32 interface=wireguard2, allowed ip’s are from your end (remember to add a route to your side using wireguard2 as gateway) and lastly add wireguard2 to the interface list “LAN”. Test access to wireguard2 from a laptop using a mobile hotspot as your smartphone or using a different ISP just to make sure it won’t involve the existing wireguard network.

Don’t hesitate to come back with further questions and good luck with the networking!

EDIT:
Here is an even simpler solution for an admin connection where all routing is handled automatically by Mikrotik and the client side (at least on windows and macos).

Pick a small subnet that is unused in Office2 lets say 192.168.100.9-10 (/30). Assign one ip addr to wireguard2 ie “/ip address add interface=wireguard2 address=192.168.100.10/30” and the other 192.168.100.9 to your pc or mac like this:

[Interface]
PrivateKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Address = 192.168.100.9/32

[Peer]
PublicKey = "public key from mikrotik wireguard2"
AllowedIPs = 192.168.100.0/24
Endpoint = publicipaddress.office2.com:12345
PersistentKeepalive = 25
8

I use Winbox Remote (free version) as a cheap and easy backup for my wireguard access but that does rely on/go through a 3rd party.

9

Yeah, that’s a very good choice for SOHO although there are some things you might want to consider. See the following thread: RemoteWinBox [review]. If they add support for mfa and certificates it would significantly increase both security and flexibility.

10

Concur Larsa, I know squat about SSTP but the first thing I said to them was why are you not using certificates?? No good answer other than probably it takes time and effort to manage them ?? $$$