WireGuard clients can handshake CRS326, but not much more

AndyBillups · November 12, 2025, 7:13am

The Problem

TL;DR: WireGuard clients can handshake, but can't consistently do anything more.

We have configured a RoadWarrior WireGuard Tunnel on a CRS326 according to MikroTik's official documentation and the two sample clients are able to establish WireGuard handshakes.

WireGuard Client x.x.x.208 can ping WAN IP addresses and the router itself, but it generally can't browse to any websites. (Suggests a DNS resolution problem.) Sometimes Client 208 can ping other LAN clients inside the router. The router can ping Client 208, and usually other LAN clients can ping Client 208, even when Client 208 can't ping back.

WireGuard Client x.x.x.210 can also ping WAN IP addresses and the router itself, and it generally can browse outside websites. (But it has the same DNS configuration as 208.) Has the same problems with pinging LAN clients inside the router. The router can likewise ping Client 210, and usually other internal clients can ping Client 210, even when Client 210 can't ping back.

Once connected, both clients can SSH into the CRS326 and authenticate. We can navigate through the shell for a several seconds and print a list or two, but then it will inevitably hang while responding to a command that produces output longer than a few lines.

Attempting to SSH into anything else sometimes produces an authentication prompt, or sometimes it hangs before connecting, or sometimes it says the destination is unreachable. Sometimes we can get all three kinds of responses when attempting to contact the same in-network destination.

We wonder if there may be some complications from the VLAN configuration, but interestingly sometimes Client 210 can ping clients inside of the worknet VLAN.

Summary: Yeah... WireGuard clients can handshake, but can't consistently do anything more.

How We Got Here

We followed the MikroTik documentation to establish a RoadWarrior WireGuard Tunnel:

WireGuard - RouterOS - MikroTik Documentation

And we have reviewed and tried all sorts of suggestions from the following resources:

Wireguard connected but not able to access internal resources
Can't Access LAN Devices Behind MikroTik via WireGuard Tunnel
MikroTik Wireguard server with Road Warrior clients
Wireguard interface in wan and lan list
WireGuard - 7.1beta6 - Can't get it to work - Howto setup?
Both Openvpn and Wiregurard fail
Wireguard VPN setup
Wireguard proper server config
Wireguard: Can' access VLANs
...among many, many others (lots of friendly/helpful people here!)
...and at least 20-30 Reddit threads
...and plenty of blogs from supposed experts
...and exactly zero generative AI prompts

And we have sacrificed several idols on the altar of the MikroTikian demigods…

This didn’t reveal any technical answers, but we now have an outstanding recipie for kotletes to try!

Config Files

CRS326 Configuration

# 2025-11-11 05:07:17 by RouterOS 7.20.4
# software id = [REDACTED]
#
# model = CRS326-24G-2S+
# serial number = [REDACTED]
/interface bridge
add admin-mac=[REDACTED] auto-mac=no comment=defconf frame-types=\
    admit-only-vlan-tagged name=bridge vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment=WAN
set [ find default-name=ether2 ] comment="Trunk to WAP"
set [ find default-name=ether3 ] comment="worknet"
set [ find default-name=ether4 ] comment="worknet"
set [ find default-name=ether5 ] comment="worknet"
set [ find default-name=ether6 ] comment="worknet"
set [ find default-name=ether7 ] comment="worknet"
set [ find default-name=ether8 ] comment="worknet"
set [ find default-name=ether13 ] comment="worknet"
set [ find default-name=ether14 ] comment="worknet"
set [ find default-name=ether15 ] comment="worknet"
set [ find default-name=ether16 ] comment="guestnet"
set [ find default-name=ether17 ] comment="guestnet"
set [ find default-name=ether18 ] comment="locnet"
set [ find default-name=ether19 ] comment="locnet"
set [ find default-name=ether20 ] comment="locnet"
set [ find default-name=ether21 ] comment="locnet"
set [ find default-name=ether22 ] comment="locnet"
set [ find default-name=ether23 ] comment="locnet"
set [ find default-name=ether24 ] comment="Management"
set [ find default-name=sfp-sfpplus1 ] comment="worknet"
set [ find default-name=sfp-sfpplus2 ] comment="worknet"
/interface wireguard
add listen-port=35953 mtu=1420 name=wg1
/interface vlan
add interface=bridge name=MGMT vlan-id=99
add interface=bridge name=guestnet vlan-id=74
add interface=bridge name=locnet vlan-id=31
add interface=bridge name=worknet vlan-id=47
/interface ethernet switch port-isolation
set 16 forwarding-override=ether1
set 17 forwarding-override=ether1
/interface list
add comment="contains main bridge (without ether1)" name=LAN
add comment="47 Work Devices" name=worknet-list
add comment="74 Guest Devices" name=guestnet-list
add comment="31 Local Devices (no internet access)" name=locnet-list
add comment="Upstream port (ether1)" name=WAN
add comment="Trunk port (ether2)" name=trunk-list
add comment="99 Management Devices" name=MGMT-list
/ip pool
add name=worknet-pool ranges=10.76.47.100-10.76.47.199
add name=guestnet-pool ranges=10.76.74.100-10.76.74.199
add name=locnet-pool ranges=10.76.31.100-10.76.31.199
add name=MGMT-pool ranges=10.76.99.100-10.76.99.199
/ip dhcp-server
add address-pool=worknet-pool interface=worknet name=worknet-dhcp
add address-pool=guestnet-pool interface=guestnet name=guestnet-dhcp
add address-pool=locnet-pool interface=locnet name=locnet-dhcp
add address-pool=MGMT-pool interface=MGMT name=MGMT-dhcp
/port
set 0 name=serial0
/system ntp key
add key-id=52728
/interface bridge port
add bridge=bridge comment="Trunk to WAP" frame-types=admit-only-vlan-tagged \
    interface=ether2
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether3 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether4 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether5 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether6 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether7 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether8 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether9 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether10 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether11 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether12 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether13 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether14 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether15 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether16 pvid=74
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether17 pvid=74
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether18 pvid=31
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether19 pvid=31
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether20 pvid=31
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether21 pvid=31
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether22 pvid=31
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether23 pvid=31
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=ether24 pvid=99
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=sfp-sfpplus1 pvid=47
add bridge=bridge comment=defconf frame-types=\
    admit-only-untagged-and-priority-tagged interface=sfp-sfpplus2 pvid=47
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=worknet-list pvid=47
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=guestnet-list pvid=74
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=locnet-list pvid=31
/ip neighbor discovery-settings
set discover-interface-list=MGMT-list
/ip settings
set rp-filter=strict
/interface bridge vlan
add bridge=bridge comment="99 MGMT" tagged=bridge,ether2 untagged=ether24 \
    vlan-ids=99
add bridge=bridge comment="47 worknet" tagged=bridge,trunk-list untagged=\
    worknet-list vlan-ids=47
add bridge=bridge comment="74 guestnet" tagged=bridge,trunk-list untagged=\
    guestnet-list vlan-ids=74
add bridge=bridge comment="31 locnet" tagged=bridge untagged=locnet-list \
    vlan-ids=31
/interface list member
add interface=bridge list=LAN
add interface=ether20 list=locnet-list
add interface=ether21 list=locnet-list
add interface=ether22 list=locnet-list
add interface=ether23 list=locnet-list
add interface=ether3 list=worknet-list
add interface=ether4 list=worknet-list
add interface=ether5 list=worknet-list
add interface=ether6 list=worknet-list
add interface=ether7 list=worknet-list
add interface=ether8 list=worknet-list
add interface=ether9 list=worknet-list
add interface=ether10 list=worknet-list
add interface=ether11 list=worknet-list
add interface=ether12 list=worknet-list
add interface=ether13 list=worknet-list
add interface=ether14 list=worknet-list
add interface=ether15 list=worknet-list
add interface=ether16 list=guestnet-list
add interface=ether1 list=WAN
add interface=ether17 list=guestnet-list
add interface=ether18 list=locnet-list
add interface=ether19 list=locnet-list
add interface=ether2 list=trunk-list
add interface=worknet list=MGMT-list
add interface=ether24 list=MGMT-list
add interface=sfp-sfpplus1 list=worknet-list
add interface=sfp-sfpplus2 list=worknet-list
add interface=guestnet list=LAN
add interface=locnet list=LAN
add interface=MGMT list=LAN
add interface=worknet list=LAN
add interface=wg1 list=LAN comment="Some forum posts say this is necessary, but this list is not used in any firewall rules"
/interface wireguard peers
add allowed-address=10.76.42.210/32 interface=wg1 name=Client210 public-key=\
    "[REDACTED]"
add allowed-address=10.76.42.208/32 interface=wg1 name=Client208 public-key=\
    "[REDACTED]"
/ip address
add address=192.168.88.1/24 comment=defconf disabled=yes interface=bridge \
    network=192.168.88.0
add address=10.76.99.1/24 interface=MGMT network=10.76.99.0
add address=10.76.47.1/24 interface=worknet network=10.76.47.0
add address=10.76.74.1/24 interface=guestnet network=10.76.74.0
add address=10.76.31.1/24 interface=locnet network=10.76.31.0
add address=10.76.42.0/24 interface=wg1 network=10.76.42.0
/ip cloud
set update-time=no
/ip dhcp-client
add interface=ether1
/ip dhcp-server network
add address=10.76.31.0/24 dns-none=yes gateway=10.76.31.1
add address=10.76.47.0/24 gateway=10.76.47.1
add address=10.76.74.0/24 gateway=10.76.74.1
add address=10.76.99.0/24 dns-server=1.1.1.2,1.0.0.2 gateway=10.76.99.1
add address=192.168.88.0/24 gateway=192.168.88.1
/ip firewall address-list
add address=0.0.0.0/8 list=Bogon
add address=10.0.0.0/8 list=Bogon
add address=100.64.0.0/10 list=Bogon
add address=127.0.0.0/8 list=Bogon
add address=169.254.0.0/16 list=Bogon
add address=172.16.0.0/12 list=Bogon
add address=192.0.0.0/24 list=Bogon
add address=192.0.2.0/24 list=Bogon
add address=192.168.0.0/16 list=Bogon
add address=198.18.0.0/15 list=Bogon
add address=198.51.100.0/24 list=Bogon
add address=203.0.113.0/24 list=Bogon
add address=224.0.0.0/4 list=Bogon
add address=240.0.0.0/4 list=Bogon
add address=[REDACTED] list=BannedIP
add address=[REDACTED] list=BannedIP
[...]
add address=[REDACTED] list=BannedIP
add address=[REDACTED] list=BannedIP
/ip firewall filter
# Throughout the filter rules, WAN port ether1 is specified directly by its interface rather than using a list. I have tried changing this to the WAN list (in the proper field, of course) and it makes no apparent difference.
# There is a ton of logging turned on as a troubleshooting measure.
add action=drop chain=input comment="Drop BannedIP" log=yes log-prefix=\
    "DROP BANNEDIP" src-address-list=BannedIP
add action=accept chain=input comment=\
    "Accept established, related, untracked" connection-state=\
    established,related,untracked
add action=accept chain=input comment="Accept WireGuard Connections" \
    dst-port=35953 log=yes log-prefix="ALLOW WIREGUARD CONNECTION" protocol=\
    udp
add action=accept chain=input comment="Accept WireGuard Traffic" \
    in-interface=10.76.42.0/24 log=yes log-prefix="ALLOW WIREGUARD TRAFFIC ON IP -- MikroTik documentation says do this"
add action=accept chain=input comment="Accept WireGuard Traffic" \
    in-interface=wg1 log=yes log-prefix="ALLOW WIREGUARD TRAFFIC ON INTERFACE -- Forum post suggests this -- tried both independently and combined, with no change in behavior"
add action=accept chain=input comment="Accept ICMP" in-interface=ether1 \
    protocol=icmp
add action=accept chain=input comment="Allow WinBox" in-interface-list=\
    MGMT-list log=yes log-prefix="ALLOW WINBOX" port=[REDACTED] protocol=tcp
add action=accept chain=input comment="Allow SSH" in-interface=ether1 port=\
    [REDACTED] protocol=tcp
add action=drop chain=input comment="Drop invalid" connection-state=invalid
add action=drop chain=input comment="Drop all else" in-interface=ether1
add action=fasttrack-connection chain=forward comment=\
    "Fasttrack established, related" connection-state=established,related \
    hw-offload=yes
add action=accept chain=forward comment="Accept established, related" \
    connection-state=established,related
add action=drop chain=forward comment="Drop Bogon Forward to WAN" \
    in-interface=ether1 log=yes log-prefix="DROP BOGON FORWARD to WAN" \
    src-address-list=Bogon
add action=accept chain=forward comment="Allow worknet to WAN" \
    connection-state=new in-interface=worknet log-prefix=\
    "ALLOW worknet TO WAN" out-interface=ether1
add action=accept chain=forward comment="Allow wireguard to WAN" \
    in-interface=wg1 log-prefix="ALLOW WIREGUARD to WAN" out-interface=ether1
add action=accept chain=forward comment="Allow guestnet to WAN" in-interface=\
    guestnet log-prefix="ALLOW GUESTNET to WAN" out-interface=ether1
add action=drop chain=forward comment="Drop guestnet to ALL" in-interface=\
    guestnet log=yes log-prefix="DROP GUESTNET to ALL"
add action=drop chain=forward comment="Drop ALL to guestnet" log=yes \
    log-prefix="DROP ALL to GUESTNET" out-interface=guestnet
add action=drop chain=forward comment="Drop WAN access to clients behind NAT" \
    connection-nat-state=!dstnat connection-state=new in-interface=ether1 \
    log=yes log-prefix="DROP WAN to NAT CLIENT"
add action=drop chain=forward comment="Drop invalid" connection-state=invalid \
    log=yes log-prefix="DROP INVALID"
add action=drop chain=forward comment="Drop all traffic to WAN" log=yes \
    log-prefix="DROP TO WAN" out-interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
add action=masquerade chain=srcnat comment="Tried this and it did nothing" \
    disabled=yes out-interface=wg1
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip service
set ftp disabled=yes
set telnet disabled=yes
set www disabled=yes
set ssh address=10.76.47.0/24,10.76.99.0/24 port=[REDACTED] comment="Yes, this will get tightened up"
set winbox address=10.76.47.0/24,10.76.99.0/24 comment="So will this"
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
/snmp community
set [ find default=yes ] authentication-protocol=SHA1 encryption-protocol=AES \
    name=worknet security=private
/system clock
set time-zone-name=[REDACTED]
/system identity
set name=[REDACTED]
/system ntp client
set enabled=yes
/system ntp server
set auth-key=[REDACTED] enabled=yes
/system ntp client servers
add address=[REDACTED]
add address=[REDACTED]
add address=[REDACTED]
add address=[REDACTED]
/system routerboard settings
set enter-setup-on=delete-key
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none

Client 208 WireGuard Configuration

[Interface]
PrivateKey = [REDACTED]              # Client's private key
Address = 10.76.42.208/32            # Client's VPN IP

[Peer]
PublicKey = [REDACTED]               # Server's public key
Endpoint = [REDACTED].com:35953      # Server's IP and listen port
AllowedIPs = 0.0.0.0/0               # Route all traffic through VPN
PersistentKeepalive = 25             # Keep connection open (seconds)

Client 210 WireGuard Configuration

[Interface]
PrivateKey = [REDACTED]              # Client's private key
Address = 10.76.42.210/32            # Client's VPN IP

[Peer]
PublicKey = [REDACTED]               # Server's public key
Endpoint = [REDACTED].com:35953      # Server's IP and listen port
AllowedIPs = 0.0.0.0/0               # Route all traffic through VPN
PersistentKeepalive = 25             # Keep connection open (seconds)

Gratitude

Thank you for your help. We appreciate whatever insights and advice you may share.

Please let us know what additional information may be helpful.

BartoszP · November 12, 2025, 7:18am

Are you aware that it is mainly a SWITCH. Setting VPN tunnels on it is doable to connect to it and mabe manage it, not for daily use for many users. You need a router.

AndyBillups · November 12, 2025, 7:25am

We are aware. This isn’t intended to have more than one or two occasional WireGuard clients connected at any given time. The clients won’t be pushing much load over the tunnel – mainly SSH connections.

The client names are just the last octet of the IP address. We are not planning on having 210 clients. (Yikes!)

You need a router

For others who might have heavier needs, it would be great if products which do not meet the definition of “router” were not marketed with the name “Cloud Router Switch” and run an OS called RouterOS.

To be fair, MikroTik’s own product page for the CRS326 does start right off with saying this is a switch. It’s just an unnecessarily confusing name for the product.

KexyBiscuit · November 12, 2025, 8:19am

Try clamping TCP MSS on connections going out from interface wg1?

/ip firewall mangle
add action=change-mss chain=forward comment="clamp MSS to PMTU" new-mss=clamp-to-pmtu out-interface=wg1 protocol=tcp tcp-flags=syn

CGGXANNX · November 12, 2025, 8:44am

In the config file on the client devices, try adding a couple of lines:

DNS = 1.1.1.2,1.0.0.2
MTU = 1420

under the [Interface] (not [Peer]) section (or any other DNS provider of your choice. I picked those two because they are what your MGMT subnet is using).

If you ping other devices in the LAN subnet and it doesn't work, verify if those devices run Windows, because by default Windows devices don't accept ping from other subnets.

anav · November 12, 2025, 3:01pm

Observations:

Recommend, an offbridge port for emergency access or safe place to config router. If your bridge or vlans burp, then the management vlan access (on the bridge) via ether24, will not be of help.
If you have an unused port of course.
I have no idea of the purpose of these two rules,,,,,, just curious..

/interface ethernet switch port-isolation
set 16 forwarding-override=ether1
set 17 forwarding-override=ether1

Interface list looks very busy, but will ascertain if required or not.............
PROBLEMATIC ----> These appear to be wrong to me??

add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged
interface=worknet-list pvid=47
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged
interface=guestnet-list pvid=74
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged
interface=locnet-list pvid=31

A. Even using logic, and just go by the word INTERFACE, you know its wrong because the item on the right hand side of the equal sign are INTERFACE LISTS, not a single interface.
B. /bridge PORTS ( are that ... PORTS) an interface list is not a port ( such as etherport or wifi port or bonded ports).

Thus all those have to be removed. Now perhaps there is a new way of identifying ports here but I am now aware of it.

Looking more closely at your interface lists, which are used to group typically 2 or more SUBNETS (except mgnmt) , not users ( for users not full subnets, use firewall-address-lists)

Having an interface list for each vlan seems pointless. Its not a list then!
If you need to identify single subnets in firewall rules, most here typically use src or dst address xx.xx.xx.0/24 or interface name.

Also once you introduce vlans, the bridge just does bridging, no dhcp etc........ and should NOT be an interface member. This is what is required, cleaned up.

/interface list
add name=WAN
add name=LAN
add name=MGMT

/interface list member
add interface=ether1 list=WAN
add interface=locnet list=LAN
add interface=worknet list=LAN
add interface=guestnet list=LAN
add interface=MGMT list=LAN
add interface=wg1 list=LAN
add interface=MGMT  list=MGMT-list
add interface=wg1 list=MGMT-list

CHANGE IP SETTINGS to rp-filter**-loose**
Dont frig with MTU rule as recommended, until the rest is sorted, its a normal approach if ISPs involved are pppoe, or if connecting to a third party vpn server.
You seem to be playing silly games with DNS settings........... Agree with previous comments, Simply set each DNS to the gatewayIP and include

/ip dhcp-server network
add address=10.76.31.0/24 dns-server=10.76.31.1  gateway=10.76.31.1
add address=10.76.47.0/24 dns-server=10.76.47.1 gateway=10.76.47.1
add address=10.76.74.0/24 dns-server=10.76.74.1 gateway=10.76.74.1
add address=10.76.99.0/24 dns-server=10.76.99.1 gateway=10.76.99.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.2,1.0.0.2,9.9.9.9

FIREWALL LIST and rules, are a mess and somewhat bogus. Focus on traffic needed, since that is most efficient and KNOWN plus simplify.

It would also appear want to allow ALL of wiregurd to your input chain with access to the config??
If they are clients that are workers, not admin then you need to ensure only the admin remote wireguard users have access ( not clearly stated in your posts ). Thus I have to assume a mix. Will need to include
wireguard in MGMT-list but will use firewall address list to delineate granular access.

/ip firewall address-list
add address=10.76.42.210 list=WorkerBee comment="john to worknet"
/ip firewall filter
{ default rules to keep }
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=icmp
add action=accept chain=input comment="local loopback" dst-address=127.0.0.1
 ( admin rules )
add action=accept chain=input comment="wg handshake" dst-port=35953 protocol=udp
add action=accept chain=input in-interface-list=MGMT-list src-address-list=!WorkerBee
add action=accept chain=input interface-list=LAN dst-port=53,123 protocol=udp
add action=accept chain=input interface-list=LAN dst-port=53 protocol=tcp
add action=drop chain=input comment="drop all else" { put this rule here but last of all rules}
+++++++++++++++++++++++++++++++++++++++++++++++++++
add action=fasttrack-connection chain=forward connection-state=established,related 
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward comment="internet traffic" in-interface-list=LAN out-interface-list=WAN-list
add action=accept chain=forward comment="admin to vlans" in-interface-list=MGMT \
  src-address-list=!WorkerBee out-interface-list=LAN
add action=accept chain=forward comment="John to work" in-interface=wg1 
   source-address-list=WorkerBee dst-address=10.76.47.0/24
add action=drop chain=forward comment="drop all else"

Ditch the sourcenat for wireguard not required in your case.
For IP services, we use firewall rules down to granular IPs, so using this for subnets is fine but have to be all inclusive enough.... and your setup looks good here.
Not sure why you redact public NTP servers ?????
This needs to be set properly

/tool mac-server mac-winbox
set allowed-interface-list=MGMT-list

AndyBillups · November 12, 2025, 11:14pm

Thank you for this suggestion. Unfortunately it does not appear to have made any difference, at least in our current configuration. We’ll keep it on reference as we review the recommendations from @anav and others.

AndyBillups · November 12, 2025, 11:18pm

It had not occurred to us as necessary to declare the DNS resolvers on the clients. Most of our testing has involved attempting to connect via direct IP (no DNS involved) and it was not going well. For the small amount of testing by attempting to access a domain (which would need DNS) it seemed like the clients were able to resolve successfully at the same rate as the direct IP connection attempts.

We went ahead and included the DNS resolvers as you recommended, restarted all the devices, and unfortunately found we were basically having the same results.

Thank you for making an effort to help, @CGGXANNX. We appreciate it.

AndyBillups · November 12, 2025, 11:27pm

Thank you for this extensive reply, @anav. We’ve found a number of your other posts on the forum to be very helpful.

We will review each of your recommendations/questions and work through them. Every line in our config is based on either MikroTik’s documentation or the advice of seemingly reasonable people in the MikroTik user community – but we know we have a lot to learn moving from junk consumer routers and switches to something that permits some level of actual control. (That control unfortunately also allows us to make bonehead mistakes as you identified in 4a.)

There will almost certainly be some follow up questions. Please let us know if you find more things we need to be reviewing.

Fortunately this is not in production yet – we’re taking everything slowly and trying to test it to the best of our abilities.

anav · November 13, 2025, 12:24am

No worries take your time, and my salutations to the borg

AndyBillups · November 14, 2025, 5:06am

@anav, we'll first answer your questions from #10 about the intended use of the WireGuard tunnel, then respond to the rest of your observations in order.

Our goal is that the WireGuard tunnel clients receive essentially the same access as ethernet and wifi clients connected to the worknet VLAN. WireGuard clients should therefore be able to talk to endpoints in the worknet and locnet VLANs. For the moment, the WireGuard clients should also route their internet-destined traffic through the WAN. We may implement some split tunnels for other purposes later.

We only anticipate one or two WireGuard clients operating at any given time and their traffic loads should not be too heavy.

Responding to the rest of your observations:

Removing the ether24 management port from the bridge to assure acccess in the scenarios you provide seems to make sense. How does this affect the ability to manage other devices on a management VLAN? In Mikrotik's Bridging and Switching Case Studies they explicitly propose placing the management port on the bridge. Or do we misunderstand and you are actually suggesting we set aside an additional port explicitly for emergency access and that this port is not on the management VLAN?
The intention is to isolate the guestnet VLANs clients connecting via ethernet so they can only communicate to the WAN, not each other, mimicking the isolation available for guestnet wifi clients. Is there a better way? (We also tested implementing with firewall rules.)
Does the interface list make any better sense if we explain the intended port layout?
- ether1: WAN (off bridge)
- ether2: Trunk to WAP (tagged for all VLANs)
- ether3-15: Access ports for worknet VLAN (may connect to WAN and clients in worknet and locnet VLANs)
- ether16-17: Access ports for guestnet VLAN (isolated from peers but can connect WAN)
- ether18-23: Access ports for locnet VLAN (may connect to clients in worknet and locnet VLANs, but are local-only devices that should have no WAN access and therefore no DNS needed)
- ether24: Access port for MGMT VLAN (re-evaluating based on #1)
- sfp-sfpplus1-2: Access ports for worknet VLAN (same as ether3-15 for now)
- wg0: Intended to provide access identical to the worknet VLAN
On further study, we're confused here. In /interface bridge port we need to assign interfaces with their PVIDs to the bridge, right? Your point that interface= should require an interface and not an interface list seems to make sense — but then why does WinBox provide interface lists in the option box for the interface field? (WinBox filters excludes illegal choices in other option box contexts.)
This may be further confusion from #4. We used documentation/posts when setting up tagging in /interface bridge vlan that proposed using interface lists here to simplify assigning the VLAN IDs. Here, as in /interface bridge port, WinBox allows selecting interface lists for the Tagged and Untagged fields. It appears to have the intended affect of assigning the VLAN IDs to the proper ports/interfaces.
We don't think anyone could have said this better.
Could you please provide your thoughts behind setting /ip settings rp-filter=loose? We changed to strict based on hardening discussions from Manito Networks, this Reddit thread among other discussions, and this Mikrotik presentation that proposes strict mode for single-homed stub customers, which says "Loose mode is useful when you are connected to more than one ISP and you use asymmetric routing", and we do not. We totally acknowledge we may have arrived at the wrong conclusions — just want to understand better.
Understood.
Could you please help us find the "silly games" in our DNS settings? If there are errors, they are unintentional. Here's what we have:

/ip dhcp-server network
add address=10.76.31.0/24 dns-none=yes gateway=10.76.31.1
add address=10.76.47.0/24 gateway=10.76.47.1
add address=10.76.74.0/24 gateway=10.76.74.1
add address=10.76.99.0/24 dns-server=1.1.1.2,1.0.0.2 gateway=10.76.99.1
add address=192.168.88.0/24 gateway=192.168.88.1

Breaking this down so we understand:

add address=10.76.31.0/24 dns-none=yes gateway=10.76.31.1 intentionally specifies no DNS as these locnet clients will never connect to the WAN or have any need for DNS resolution.
Clients in 10.76.47.0/24 and 10.76.47.0/24 seem to be resolving DNS just fine without declaring dns-server=. Is this simply because the endpoints likely have local DNS settings that are picking it up for themselves?
We're hazy on why add address=10.76.99.0/24 dns-server=1.1.1.2,1.0.0.2 gateway=10.76.99.1 defines the DNS server — it may have been an unintentional edit in WinBox. Seeing it in the export, our immediate reaction is that it should be removed to match the lines above.
add address=192.168.88.0/24 gateway=192.168.88.1 is left over from the MikroTik default and we'll remove it.

After this, you propose setting /ip dns set allow-remote-requests=yes servers=1.1.1.2,1.0.0.2,9.9.9.9. In contrast, Mikrotik's Securing your router documentation proposes setting /ip dns set allow-remote-requests=no if the device is not providing a DNS cache. Do you have thoughts for or against having the CRS326 provide a DNS cache versus letting endpoints provide their own caches and query reasonably trustworthy DNS from the internet directly?

Yes. The current firewall is a mess and we suspect it could be a configuration error here that's breaking the WireGuard functionality — that's exactly why we requested assistance here. In the interest of getting the rest of our answers and questions to you sooner, we'll respond more thoroughly to this in a separate reply.
Ditched.
Thank you.
This was possibly overzealous redaction thanks to hours of October cybersecurity trainings ringing in our ears. We selected regional NTP pools and it didn't seem necessary to disclose the region.
This recommendation is to provide a means to connect and authenticate via MAC addressing, right? Curiously, MAC connections have never worked for us even out of the box — they either do not connect at all or get stuck on authenticating and then never complete the connection. We have always had to resort to IPv6 when establishing a connection in the absence of IPv4 being available.

We appreciate your insights, and those from anyone else who cares to help. We look forward to reading your next set of notes and will continue working on the firewall rules so we can get back to you with a thoughtful reply soon.

Thank you again.

The Borg? Sounds Swedish.

rplant · November 14, 2025, 6:51am

Some random stuff.

If you can ping clients on the subnets from the router, but not wireguard
you could try adding the following masquerade rule to see if it helps.

/ip firewall nat
add action=masquerade chain=srcnat src-address=10.76.42.0/24

Ping devices which answer to the router and see if they now answer over wg.
Can you see the counter on the above nat rule counting (probably once for each different ping)

If not, perhaps traceroute to the devices and make sure they are getting there via the wireguard link.

If either end of your links are running pppoe, you should drop the mtu of the wireguard link.
(Perhaps to 1412, though I would probably use 1400)
And change the tcp mss adjustment rule appropriately. (You do need the adjustment rule)

You can perhaps do some pings via wireguard to (probably the wireguard ip address on the router)
with various sizes and with no fragment.

(windows)
ping -f -l 1472 10.76.42.0
windows need to subtract 28 from actual packet size, so above is 1500. (Which shouldn't get through)

10.76.42.0 as an address is legal, but I don't like it

rplant · November 14, 2025, 10:28am

Probably if you add mtu = 1412 (1400, 1420) to the client config interface section you would not need mss clamping.

AndyBillups · November 17, 2025, 6:18am

All right, we’ve made a study of @anav’s firewall recommendations, and played with the suggestions from @rplant, @KexyBiscuit, and @CGGXANNX.

Here are the key takeaways:

A WireGuard client such as 10.76.42.208 can handshake the CRS326 successfully.
When connected, the WireGuard client can ping the CRS326’s internal IPs and receive responses for as many pings as we send. The first ping in each test series appears in the CRS326’s log as a new connection.
When connected, the WireGuard client can ping any internal client IP that it should be able to reach and receive responses for as many pings as we send. The first ping in each test series appears in the CRS326’s log as a new connection.
When connected, the WireGuard client can SSH via the CRS326’s internal IP and authenticate successfully. The connection appears in the log. The connection locks up after sending a few commands. Killing the SSH session on the client appears in the CRS326’s log as an SSH disconnect.
When connected, the WireGuard client can request an SSH connection from any internal client IP, but the session freezes before requesting authentication. The connection attempt appears in the CRS326’s log as a new connection and the receiving client sees the connection request. (Yes, we’ve even tried completely disabling the target client’s firewall or setting it to allow literally anything in – so the problem isn’t the target client.)

When connected, attempting a traceroute from the WireGuard client to any internal client produces the following:

traceroute to 10.76.47.203 (10.76.47.203), 30 hops max, 60 byte packets
 1  10.76.42.1 (10.76.42.1)  68.566 ms  108.379 ms  108.212 ms
 2  * * *
 3  * * *
 4  * * * 
 5  * * * 
 6  * * * 
 7  * * * 
 8  * * * 
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

…and each of the 30 packets appears in the CRS326 log as a new connection attempt between the Wireguard client and the target client, each reporting a length of 60 bytes.

In contrast, attempting a traceroute to 1.1.1.1 produces a completely ordinary result. The first hop is 10.76.42.1 and from there it jumps through our ISP’s infrastructure and on to Cloudflare.

Please note: All of this testing is using IP4 with no domain names. As such, DNS is not involved.

What we believe we’ve confirmed is:

The WireGuard clients are successfully connected to the CRS326, with a keepalive handshake every 25 seconds.
The WireGuard clients can initiate IP4 pings to any internal client they should be able to reach and receive a reply.
The WireGuard clients are blocked by the CRS326 from making any sustained connection to any internal target client, or the internal target clients are blocked from any sustained reply.

We have attempted a variety of firewall configurations to explicitly allow connections to or from the WireGuard clients, with no success. For instance:

add action=accept chain=forward comment="Allow WIREGUARD IP to WORKNET IP" src-address=10.76.42.0/24 dst-address=10.76.47.0/24 log=yes log-prefix="TEST ALLOW WIREGUARD IP to WORKNET IP"
add action=accept chain=forward comment="Allow WORKNET IP to WIREGUARD IP" src-address=10.76.47.0/24 dst-address=10.76.42.0/24 log=yes log-prefix="ALLOW WORKNET IP to WIREGUARD IP"```

add action=accept chain=forward comment="Allow WIREGUARD INTERFACE to WORKNET INTERFACE" in-interface=wg1 out-interface=worknet log=yes log-prefix="ALLOW WIREGUARD INTERFACE to WORKNET INTERFACE"
add action=accept chain=forward comment="Allow WORKNET INTERFACE to WIREGUARD INTERFACE" in-interface=worknet out-interface=wg1 log=yes log-prefix="ALLOW WORKNET INTERFACE to WIREGUARD INTERFACE"

add action=accept chain=forward comment="Allow WIREGUARD INTERFACE to WORKNET IP" in-interface=wg1 dst-address=10.76.47.0/24 log=yes log-prefix="TEST ALLOW WIREGUARD INTERFACE to WORKNET IP"
add action=accept chain=forward comment="Allow WORKNET IP to WIREGUARD INTERFACE" src-address=10.76.47.0/24 out-interface=wg1 log=yes log-prefix="ALLOW WORKNET IP to WIREGUARD INTERFACE"```

add action=accept chain=forward comment="Allow WIREGUARD INTERFACE to WORKNET IP" in-interface=wg1 dst-address=10.76.47.0/24 log=yes log-prefix="ALLOW WIREGUARD INTERFACE to WORKNET IP"
add action=accept chain=forward comment="Allow WORKNET IP to WIREGUARD INTERFACE" src-address=10.76.47.0/24 out-interface=wg1 log=yes log-prefix="ALLOW WORKNET IP to WIREGUARD INTERFACE"

...and every permutation we can think of. In every case, we have the same result.

The WireGuard client can ping internal clients, and internal clients can ping the WireGuard clients – but they are unable to establish any deeper connection. The one exception is that the WireGuard clients can authenticate into an SSH session on the CRS326, but it locks up after a small amount of traffic is exchanged.

Out an abundance of thoroughness, we even disabled the accept ICMP rule in the firewall input chain. This is the only ping-related rule in the firewall. As expected, disabling it did not block the pings from connected WireGuard clients, since the originate on the wg1 interface and would be handled by the forward chain.

What is the pattern? Why can connected WireGuard clients ping and (almost) nothing else?

CGGXANNX · November 17, 2025, 7:00am

How did you get the 10.76.42.1 address in your traceroute? in your posted export the router has the 10.76.42.0 address on the wg1 interface.

You should try the mangle rule to clamp MSS, but using an explicit value instead of clamp-to-pmtu. And try with 1340 instead of the usual 1380 that is used with MTU 1420

/ip firewall mangle
add action=change-mss chain=forward comment="reduce MSS for WG" \
    new-mss=1340 out-interface=wg1 protocol=tcp tcp-flags=syn tcp-mss=1341-65535
add action=change-mss chain=forward comment="reduce MSS for WG" \
    new-mss=1340 in-interface=wg1 protocol=tcp tcp-flags=syn tcp-mss=1341-65535

anav · November 17, 2025, 12:52pm

First yes if that is indeed the IP address of your wireguard interface it needs to be fixed to:
add address=10.76.42.1/24 interface=wg1 network=10.76.42.0

To respond to the list of observations:

You can keep the ether24 on the bridge for management purposes. My point was that if there is an isssue with vlan bridge filtering, ALL the vlans may not be accessible including the management vlan, but the OffBridge port will always be available! ( For me yes, its an emergency access and initial configuration safe place ).
The easy and effective way to isolate traffic, at layer 3, is to, in the forward chain, simply identify the traffic needed and then with a drop all rule at the end of the forward chain, DROP all else.
Yes, it shows where your thinking goes wrong LOL.
Interface lists are not for ports, they are for VLANS/SUBNETS etc..........
Recently Mikrotik starting making it possible to use interface lists on Bridge settings. I have not used them and some more astute colleagues (actually IT & networked trained - I have no formal training ), also prefer not to use that new functionality yet. Others may be more apt at providing advice if you want to use that functionality. In any case, the lists would have to contain vlans/subnets NOT ports.
My advice, since still learning ROS is stick to the basics and what works
Same point, yes its allowed, and if you feel more comfortable doing it that way, fill yer boots.
However, I will be unable to assess what you have done wrong if things dont work, not having done it that way.
If you are clear on the limitations, then by all means keep it as is. Loose has never posed any security issues, here on the forum (aka never reported).
Well I was asking for reasons, and you supplied them.
What is interesting then is that locnet NEEDS to be REMOVED from LAN interface list.
It does not need access to DNS services on input chain
It does not need access to WAN on forward chain
conclusion: remove from LAN interface list.

DNS is often personal preference, however you seem to be content not knowing how devices get DNS whereas I would rather be in control of that functionality. I just noticed there was a lack of consistency in approach.

Many of us use winbox for config, either via wireguard or local. Again personal preference, much easier to click on the entry that shows up and not have to remember the IP address and more so the particular winbox port for that device.

Borg reference is simply a reaction to the usage of WE in your texts.
It is unknown if this means you:
a. have multiple personalities
b. are part of a royal family
c. are referring to the Borg Collective ( see star trek )
d. are part of a board, whose purpose is to avoid personal responsibility or accountability for any decisions...

Just some of the thoughts that spin around when I hear WE in the text, aka its unusual

rplant · November 17, 2025, 11:15pm

My current guess is that (one option) you might need to Src-nat the packets from the wireguard link, to any output interface/vlan.

The other devices on the local network probably don't know how to get back to 10.76.42.0/24 so send them via their default gateway, (which I assume is not the CRS)

Even if the default gateway has a route back to 10.76.42.0/24 it (the gateway) will likely get rapidly upset if the packets follow an asymmetric path. Outbound direct from crs to device, return from device to default gateway, from default gateway back to crs.

a src-nat rule like the following might work.

/ip firewall nat
add action=masquerade chain=srcnat src-address=10.76.42.0/24

You could src-nat (rather than masquerade) it to a fixed CRS ip address, which would likely be better.