WireGuard with VLAN Bridge

WireGuard with VLAN Bridge

Overview

WireGuard operates at Layer 3 (IP). It cannot be added as a bridge port because it has no Ethernet frame structure. Instead, a WireGuard interface gets its own IP subnet, and access to VLAN networks is granted through firewall forward rules.

The recommended pattern:

• WireGuard interface has a dedicated subnet (e.g., 10.10.20.0/24)
• VLAN interfaces are created on top of a VLAN-filtered bridge (e.g., vlan10-mgmt, vlan20-servers)
• Firewall rules control which VLANs WireGuard peers may reach
• WireGuard is added to interface lists for LAN and management access

This is the correct architecture regardless of how many VLANs exist. You do not assign WireGuard a VLAN IP directly — traffic routing through the router handles VLAN reachability.

Prerequisites

• RouterOS 7.x (WireGuard support is native from 7.0)
• An existing VLAN-filtered bridge with VLAN interfaces (/interface vlan) and IP addresses assigned to those interfaces
• A public IP or DDNS hostname on the WAN interface
• WireGuard key pairs for each client peer (router keys are auto-generated)

Configuration

1. Create the WireGuard Interface

RouterOS automatically generates a private/public key pair when the interface is created. No separate key generation command is needed.

/interface wireguard
add name=wireguard1 listen-port=13231 mtu=1420

Assign an IP address from a dedicated WireGuard subnet:

/ip address
add address=10.10.20.1/24 interface=wireguard1 network=10.10.20.0

2. Add Client Peers

For each remote client, add a peer entry with a unique allowed-address:

/interface wireguard peers
add interface=wireguard1 \
    public-key="<client-public-key>" \
    allowed-address=10.10.20.2/32

add interface=wireguard1 \
    public-key="<second-client-public-key>" \
    allowed-address=10.10.20.3/32

For road-warrior clients that roam (no fixed endpoint), omit endpoint-address and endpoint-port. Add persistent-keepalive=25 on the client side to maintain connectivity through NAT.

3. Add WireGuard to Interface Lists

Add WireGuard to the LAN list so forward rules apply, and to a MGMT list for management access control:

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

/interface list member
add interface=<wan-interface> list=WAN
add interface=wireguard1 list=LAN
add interface=wireguard1 list=MGMT

Replace <wan-interface> with the name of your WAN-facing interface (e.g., ether1 or pppoe-out1).

Also add the management VLAN interface to MGMT:

/interface list member
add interface=vlan10-mgmt list=MGMT

4. Create an Authorized Address List

Restrict which WireGuard peers (and local admin hosts) can access the router and sensitive VLANs:

/ip firewall address-list
add address=10.10.20.2/32 list=Authorized comment="admin remote wireguard"
add address=10.10.20.3/32 list=Authorized comment="admin mobile wireguard"
add address=192.168.10.250/32 list=Authorized comment="admin desktop local"

5. Firewall Rules

Input chain — allow WireGuard handshake and management access

/ip firewall filter
add chain=input action=accept \
    connection-state=established,related,untracked \
    comment="accept established/related"

add chain=input action=drop \
    connection-state=invalid \
    comment="drop invalid"

add chain=input action=accept \
    protocol=icmp \
    comment="accept ICMP"

add chain=input action=accept \
    protocol=udp dst-port=13231 \
    comment="WireGuard handshake"

add chain=input action=accept \
    in-interface-list=MGMT src-address-list=Authorized \
    comment="management access for authorized hosts"

add chain=input action=accept \
    in-interface-list=LAN dst-port=53 protocol=udp \
    comment="DNS from LAN"

add chain=input action=accept \
    in-interface-list=LAN dst-port=53 protocol=tcp \
    comment="DNS from LAN"

add chain=input action=drop \
    comment="drop all else"

Forward chain — allow WireGuard peers to reach VLANs

/ip firewall filter
add chain=forward action=accept \
    connection-state=established,related,untracked \
    comment="accept established/related"

add chain=forward action=drop \
    connection-state=invalid \
    comment="drop invalid"

add chain=forward action=fasttrack-connection \
    connection-state=established,related hw-offload=yes \
    comment="fasttrack"

add chain=forward action=accept \
    in-interface-list=LAN out-interface-list=WAN \
    comment="LAN to internet"

add chain=forward action=accept \
    in-interface-list=MGMT out-interface-list=LAN \
    src-address-list=Authorized \
    comment="authorized WireGuard/mgmt peers to all VLANs"

add chain=forward action=drop \
    comment="drop all else"

Key point: WireGuard peers are routed, not bridged. The router forwards packets between the wireguard1 subnet and VLAN subnets. The MGMT interface list and Authorized address list together enforce which peers may access which VLANs.

6. NAT (WireGuard Clients Accessing the Internet)

If WireGuard clients should reach the internet through the router, the existing WAN masquerade rule covers this since wireguard1 is in the LAN list. No additional NAT rule is required.

If clients should only reach internal VLANs (split tunnel), configure allowed-address on the client to list only the VLAN subnets, not 0.0.0.0/0.

Verification

Check that the WireGuard interface is up and peers have performed a handshake:

/interface wireguard print
/interface wireguard peers print

A peer that has connected shows a non-zero last-handshake time and increments rx / tx byte counters.

Verify the WireGuard IP address is assigned:

/ip address print where interface=wireguard1

From a connected client, ping the router’s WireGuard address:

ping 10.10.20.1

Then ping a host on a VLAN to confirm routing:

ping 192.168.10.1

Check firewall hit counts to confirm rules are matching:

/ip firewall filter print stats

Troubleshooting

Client connects but cannot reach VLANs

• Confirm wireguard1 is in the LAN interface list (/interface list member print).
• Confirm the Authorized address list contains the client’s WireGuard IP.
• Check that the forward rule for MGMT → LAN is above the drop-all rule.
• On the client, verify allowed-address includes the VLAN subnets (e.g., 192.168.10.0/24).

Client cannot reach the internet through WireGuard

• On the client, allowed-address must include 0.0.0.0/0 for full tunnel.
• Confirm the WAN masquerade NAT rule covers the WireGuard subnet — add wireguard1 to the LAN list or adjust the srcnat rule if needed.
• Ensure the forward rule LAN → WAN is present and not blocked by a drop rule above it.

WireGuard peers show no handshake

• Confirm the input rule accepts UDP on the configured listen-port.
• Verify the WAN IP or DDNS hostname on the router is reachable from the client.
• If the router is behind a double-NAT, UDP port forwarding may be required at the upstream device.

VLAN loses internet access after adding WireGuard

• Check that VLAN interfaces are individually in the LAN list. Using br-Uplink directly in the list can conflict with VLAN filtering. Replace the bridge entry with explicit VLAN interface entries:

/interface list member
remove [find interface=br-Uplink list=LAN]
add interface=vlan10-mgmt list=LAN
add interface=vlan20-servers list=LAN
add interface=vlan30-iot list=LAN
add interface=vlan100-users list=LAN

WireGuard IP described as “not a VLAN IP”

This is by design. The WireGuard subnet is separate from all VLANs. Access to VLAN resources is provided by routing through the router, controlled by firewall forward rules. Do not attempt to assign a VLAN IP to the WireGuard interface or add wireguard1 as a bridge port — neither is supported.

See Also

• Bridging and Switching
• Bridge VLAN Filtering
• WireGuard
• Firewall Basics