Assign VLAN to WireGuard Traffic

[kspr]

Hi everyone,

This is a follow-up to the thread: Guest Network: VLAN vs. Bridge

I finally managed to configure the VLANs on my hAP ax3 router. I set the appropriate PVIDs on the bridge ports (for both Wi-Fi and Ethernet), and everything seems to be working fine.

Now, I would like to assign a specific VLAN to all traffic coming through the WireGuard interface. However, unlike Wi-Fi and Ethernet interfaces, I noticed that WireGuard does not appear under Bridge > Ports, so I’m not sure how to tag or assign a VLAN to its traffic.

What’s the correct approach to achieve this?

Thanks in advance for any help!

[lurker888]

Wireguard is an L3 (ip) interface, not an L2 (ethernet) one, and as such cannot be part of a bridge (an L2 domain)

You have to route the packets, you probably guessed it by now, via policy routing.

If you want to use a wg connection and connect it to an ethernet port or vlan, the easiest way to go is probably via a vrf instance. It fits so nicely, it’s almost as if it was made for these situations.

[anserk]

@kspr

Now, I would like to assign a specific VLAN to all traffic coming through the WireGuard interface.

Can you explain what you are trying to achieve by doing this?

[kspr]

I want the clients that connect via WireGuard to have the same permissions — specifically the same firewall rules — as the devices in a particular VLAN. I know I could create separate firewall rules for the WireGuard clients, but I thought it would be cleaner to treat them as part of the VLAN instead, so I wouldn’t have to duplicate rules.
Please correct me if I’m wrong.

[lurker888]

@kspr

Please correct me if I’m wrong.

Well, you’re inviting this one… Yeah, as explained, it’s really not possible to make the wg interface a part of a bridge.

This is what interface lists are for. Where you previously had e.g. in-interface=my-trusted-vlan, instead put in-interface-list=my-trusted-ifs, and create the interface list with your vlan and the tunnel as members.

[spippan]

@lurker888

probably via a vrf instance

will only be possible as soon as MT makes WireGuard interfaces VRF aware/compatible

(waiting on that one for a long time now)

[lurker888]

@spippan

will only be possible as soon as MT makes WireGuard interfaces VRF aware/compatible

For the inner tunnel traffic (before-encryption/after-decryption) it is fully VRF-capable and has been since the introduction of wg. You simply assign the wireguard interface to a VRF and everything works as it should.

When we clamor for VRF-awareness, we would like the possibility to direct the outer tunnel traffic (after-encryption) to a VRF, or mark it for non-default routing.

I agree that it would be quite nice to have this...

[spippan]

@lurker888

For the inner tunnel traffic (before-encryption/after-decryption) it is fully VRF-capable and has been since the introduction of wg. You simply assign the wireguard interface to a VRF and everything works as it should.

When we clamor for VRF-awareness, we would like the possibility to direct the outer tunnel traffic (after-encryption) to a VRF, or mark it for non-default routing.

but afaik without the latter no handshake will be possible, am i right?

[lurker888]

@spippan

but afaik without the latter no handshake will be possible, am i right?

There's really nothing esoteric about what I'm saying. The handshake is part of the outer part of the tunnel and will always be routed according to the main table, along with all other outer traffic (before-decryption/after-encryption). This is what would change by becoming VRF-aware.

By that the inner side can be freely incorporated into a VRF, I mean e.g. the following setup:

• router acquires own address and gateway via DHCP (main table)
• has a wireguard tunnel with the endpoint being some central location
• has a VRF containing the wireguard interface and the bridge (of say ether2-5 ports)
• has an address on the bridge, let's say 192.168.200.1/24 and a DHCP server
• has a default route via the wireguard interface (in the VRF's table)

Then devices connected to the ether ports will get an address from this router, and all traffic to/from their subnet will be sent over the wireguard tunnel to the central router.

In this sense the inner part of the wg tunnel can be freely incorporated into a VRF. The above (skecth of an) example works perfectly.

[spippan]

@lurker888

By that the inner side can be freely incorporated into a VRF, I mean e.g. the following setup:

• router acquires own address and gateway via DHCP (main table)
• has a wireguard tunnel with the endpoint being some central location
• has a VRF containing the wireguard interface and the bridge (of say ether2-5 ports)
• has an address on the bridge, let’s say 192.168.200.1/24 and a DHCP server
• has a default route via the wireguard interface (in the VRF’s table)

Then devices connected to the ether ports will get an address from this router, and all traffic to/from their subnet will be sent over the wireguard tunnel to the central router.

In this sense the inner part of the wg tunnel can be freely incorporated into a VRF. The above (skecth of an) example works perfectly

oh, thanks a lot for clarification on that. never had time to try such a setup.
did not know mikrotik was able to do/handle it that way.

i only know this from cisco on tunnels
where “ip vrf forwarding VRFNAME” and “tunnel vrf VRFNAME” came to mind as i have read your description.

curious to try this ASAP.
appreciated

[kspr]

@lurker888

Well, you’re inviting this one… Yeah, as explained, it’s really not possible to make the wg interface a part of a bridge.

This is what interface lists are for. Where you previously had e.g. in-interface=my-trusted-vlan, instead put in-interface-list=my-trusted-ifs, and create the interface list with your vlan and the tunnel as members.

Thank you I’ll go with that approach