First of all, I’d like to say thanks for all of the great resources in this forum. I have been reading loads and learning a lot, but I am now stuck on my little VLAN ↔ Wireguard setup.
One trunk port carries untagged and tagged traffic between the switch and MikroTik router (native LAN and one VLAN)
Router assigns IP addresses for the LAN and VLAN
Untagged traffic (native network) should flow over the PPPoE connection
VLAN traffic should be tunneled through the Wireguard connection (I am using the v7 beta)
After having established the base, I followed http://forum.mikrotik.com/t/wireguard-and-mullvad-vpn/148050/1 for the Wireguard setup. The Wireguard connection stands and I can ping the peer, but I am struggling to get VLAN traffic routed through the Wireguard interface. I think I am missing something in the routing and firewall section.
Besides the overall setup, I was wondering what the advantage of a VRF table is compared to a simple firewall mangle rule (routing mark) and the creation of a standard routing table and route referring to that routing table. Both seem to use the same underlying concept, but I am not sure how they differ apart from some automatic routes being set up.
Also, I believe the hAP ac2 has a switch chip, but I configured all VLAN settings in the Bridge section of the device. Would it be wise to optimise this setup to take some load off the router’s main CPU? Or is the setup above considered good practice?
I will soon be looking into a solution to enable remote staff to use physical telephony devices (VoIP phones) alongside their personal laptops running behind their home internet service plans. Allowing them to VPN into the corporate network using Wireguard, running on a MikroTik, is the goal.
My thinking is that corporate would install a WireGuard enabled MikroTik server behind whatever their main router is and then the home user would be shipped a preconfigured WireGuard enabled hAP. The home user would plug the hAP into a free port on their home router, then plug the phone into the hAP. With the laptop they would have the option of plugging in or using the wifi corporate SSID from the hAP. There will also be soft-phones on PCs and apps on mobile devices.
Hopefully this will be a drop in solution and everything just works. Naturally, there will be a port forward on the corporate side to the WireGuard server. Now, the fun part will be how to keep the phones a part of the VoIP VLAN and the laptops on the data VLAN.
I could have, but the beta forum has a tagline of “Please report all issues with RouterOS v7beta” and until I read @mducharme’s tip on the allowed-addresses glitch in the UI, nothing indicated that my problem is caused by ROSv7. And having fixed this one issue, my solution is still incomplete. Once I have studied and trialled & errored my way through to a working solution, I plan to summarise all (unreported) bugs related to Wireguard and post it in the beta forum, so that RouterOS developers can work with solid evidence rather than helping a new MikroTik customer learn the basics.
Thanks for this hint! I’ve worked with Wireguard before and when I first tried to set the Allowed Addresses field via WebFig, it turned 0.0.0.0/0 into to blank field, and I thought that’s just how MikroTik presents an “allow all” rule. But it really does seems like a ROS v7beta6 bug.
I was able to set the value via CLI instead:
/interface wireguard peers set <ID> allowed-addresses=0.0.0.0/0
The result is that I can now ping the internet but no other traffic seems to pass through (FWIW, I also can’t access WebFig from the VLAN). But I seem to be one step closer and will go through my routes and firewall rules again.
Nice! For the corporate side, you could simply install Wireguard on any Linux instance and port-forward to it instead of having an extra MikroTik device (unless you want or need to of course). I have done this before and it’s been very stable and reliable for my usage pattern (mind you, less than 5 devices connected on average).
For the hAPs in your scenario, Wireguard is only supported in the latest beta versions at the moment, and I would be conservative in my hopes around “everything just works”. In terms of VLANs, your plans sound very much like what I am trying to achieve, just on a larger scale and with less opportunities to reconfigure devices (I guess you’d have to remote-desktop into people’s home networks to update gateway settings if need be). Hopefully there will come a day soon when I have a working setup together, and I will of course be happy to share it here for others to learn and re-use.
I’m still learning, but I have been playing with a Raspberry Pi as a Wireguard server. The trouble is, I don’t yet know how to identify an incoming Wireguard peer as belonging to a particular VLAN or not. Traffic leaving the Wireguard server all has the same ip address. I was thinking that I needed a Linux box with multiple ports (aka a MikroTik hEX) and thus I would have a physical Ethernet port to represent each VLAN (each port on the hEX would be connected to different Access ports on a switch).
Is there a way, in Ubuntu 20.04, to VLAN tag traffic (based on ip address I guess) coming from the wg0 interface? I would need different VLAN tags based on which peer is sending traffic.
The Raspberry Pi might not have enough horsepower, I don’t know yet. I was using it as a test. Could build a Ubuntu system if necessary. Would also consider using MikroTik hardware if it tests well. Interesting reading here about Linux based tunneling.
Depends on your needs. For enterprise(ish) use cases I would personally not bank on a Raspberry Pi, even though mine have never let me down for small-scale projects. But even with a Pi, you can install VLAN support on it and let all traffic flow over one physical interface. But hard to be more precise without detailed network topology.
Either way, it might be worth creating a separate topic in this forum or in a general Linux/Wireguard forum like https://www.reddit.com/r/WireGuard. I’d also love to learn more about the VLAN filtering and routing requirements you mentioned, but feel like this discussion is starting to override the original intent of the thread.
AFAIK Wireguard is a layer 3 VPN so there is no concept of VLANs - it will route packets between different subnets at each end and firewall rules can be used to restrict which subnets can communicate with each other. If you really need to extend the layer 2 domain then VxLAN, GRETAP or in the Mikrotik case EoIP would work.
Correct, but I still want to use WireGuard. Just need a way to map VLANs as I don’t really need the tag itself on the frame to get propagated. I understand VxLAN support is on its way. If I could have two WG instances on the client, or two WG instances at the server, that could do it.
Regarding my initial post, I do not intend to extend the concept of VLANs beyond the Wireguard interface. My problem is simply that I haven’t been able to route internet traffic from my local VLAN to the Wireguard interface and back.
You need to provide a route from the vlan to the wireguard interface
use a routing table entry and a route rule reference the table, lookup only in, and the source address(es) that are appropriate
I am currently trying to solve this using VRF, since it nicely separates the VLANs by default.
Adding the VRF for my VLAN worked, but adding the default route for it fails to establish an internet connection for VLAN clients:
add comment="Default route for VLAN" dst-address=0.0.0.0/0 routing-table=*3 gateway
=pppoe-out1 distance=1
# I don't quite understand the *3 reference, but that what showed up for the rules that were automatically created after I set up the VRF, so I just copied it.
# Edit: Turns out that creating a VRF via CLI only creates an entry in /ip/vrf but not /routing/table. When I used WebFig to create the VRF, I get both. Then the *3 is replaced with the actual name of the routing table. Strange.
I think I have to research in detail how VRFs work on ROS v7 since it seems to be a bit different to older versions.
If that fails, I have to delete the VRF, create a simple second routing table, and add a routing lookup rule as you suggested.
I almost got this to work now. I eventually created a VRF (which automatically created a routing table), then I created a default route in that routing table. No extra mangle rule our routing rule - nice and simple.
Then the pings (ICMP) started to work. Traceroute shows that it’s tunneled through the VPN.
However, I cannot open a website on the client. So I thought it must be the firewall, until I realized that opening an IP address works.
Looks like something isn’t right with the DNS setup. Some sites which the browser had cached before work, until I empty the cache and try it again.
