I have a network including a handful of physical workstations and printers plugged into a Mikrotik CRS-125, and a pair of virtualization host servers running VMWare ESXi 6.7.0. I am attempting to set up VLANs to separate internal users (the workstations and domain-based PCs) from the web server (accessable from the internet high seas) and then to further separate the VM management network into a VLAN and the backup traffic into a VLAN.
I did some reading up on mac-based VLAN, and I like this approach because it seems to help protect against a user plugging a foreign device into an ethernet port in their office and being a liability on the network. Last night I was working my way through the setup process. I managed to enable the FDB-based VLAN on an ethernet port (8), and I set up the ethernet port which goes to the virtualization servers (23) to be a trunk port, and I further set up the virtual switch on ESXi to use the same VLAN I had configured for ethernet port 8. I gave the VMs and the desktop some static IPs on a subnet of their own and was able to ping from one PC to the other on the same VLAN. So far so good.
I was not able to establish DHCP for the VLAN, and am also unable to find guides that describe how to enable multiple VLANs to route to the Mikrotik’s default gateway (I want two VLANs with different subnets to connect to the internet, but not to each other. Particularly in the case of the business VLAN, guest WiFi and the web server, I want all three to connect to the internet, I want the internet to connect to the webserver (NAT), and I want guests to be able to open websites on the web server, so some VLAN-to-VLAN traffic is needed. Does anyone have a guide or some tips on how I need to approach this particular step? Thanks in advance!
Post sanitized /export hide-sensitive output (obfuscate public IP addresses if any) in [__code][/code] environment. It is easier to tell what is missing than to throw in complete tutorial.
I was hoping there existed a guide already written that I just didn’t find, but that’s a fair approach. I did remove a couple things to restore the network back to functional, since it is a production system, so this has a couple things removed/unconfigured (like eth8 is no longer mac-vlan enabled). That said, here’s the export:
There are quite a few things that seem wrong … in order as they appear in the config file
vlan interface “VLAN 130 (Backups)” as a slave of another VLAN interface … do you really use Q-in-Q (frames with double VLAN tags)?
if you want to assign static leases to certain DHCP clients, then you shoukd do it in /ip dhcp-server lease, not in /ip pool
generally it’s not correct to have vlan interface both created off bridge (in /interface vlan) and member if same bridge (in /interface bridge port) … the offending vlan interface is “VLAN 110 (Business)”
apart from mac-based VLAN settings you don’t have any vlan config in /interface ethernet switch vlan … you should configure port-based vlans there for trunk ports as well as for access ports. Be sure to add switch1-cpu interface config as well if CRS needs to interact with certain VLAN on IP level.
/interface list member config is useless as none of entries mention name of address list (to be used elsewhere, e.g. in firewall filter rules)
only assigned IP address is set to interface (ether2), which is member of a bridge … IP address should be assigned to top-most interface (in your case for untagged that’s bridge … in case you want to assign address to be used in certain VLAN the address should be assigned to corresponding vlan interface)
in /ip dhcp-server lease address property should be single IP address, not string. If you need to add some comment, use comment property.
in firewall filter rules use as little matching criteria as possible. E.g. if you know src mac address or src IP address, then you probably don’t need to filter on in-interface as well …
one of firewall filter rules (not the last one) is add action=accept chain=forward … none of rules for the same chain below this point matter … firewall filter rules get evaluated in order from top to bottom. Generally firewall filter rule set seems a bit extensive, you might want to rethink them starting with default rules (if the default rule set is not empty)
You were asking about how to allow two VLANs to connect to internet but not each other. One of good ways is to use firewall rule pair such as this:
a router which will happily route IP traffic between all of its L3 interfaces (those that have IP address bound)
a firewall which will allow or block traffic flowing through device. Mind that packets are (implicitly) allowed if they reach the end of rule list for given chain.
Adding to the mix, possibly confusing things and possibly hurting things: we used to have a second office location and I had a site to site VPN link connecting the two (site B had a little 8port Mikrotik, but same RouterOS and it worked beautifully). I left that configuration in place in case the owners decided to reopen the remote site in a different location, but perhaps there’s some stuff that should get cleared out. Additionally, there are port-forwarded RDP connections, which I’m not a big fan of BUT there’s something wrong with the ISP’s handling of inbound VPN connectivity, so I’ve not been able to set up remote VPN sessions and the ISP has acknowledged they have a problem but don’t appear to be able to fix it.
The VLAN interfaces are disabled, and could just get deleted. My goal is not to slave VLANs, but that may have been misconfigured in testing things out.
This is intentional. The assignment is actually happening in /ip dhcp-server lease, but I’m assigning named pool entries instead of IP. The webui view of the leases page doesn’t correctly sort 1 before 10 before 100, so the naming of 001, 010 and 100 make it simpler to view the IPs in numerical order, and I’d rather view the intended name of each PC in-line instead of on the next line (the comment field is displayed on its own row and that’s just wasting space). And unless you named IP pool entries in this way, the interface is “smart” enough to change IP ending in .010 to .10. I can post screenshots if that helps explain the use case BUT this method has been very effective for a couple years so I’d just as soon leave it as-is unless someone is looking to make changes to the webui.
“VLAN 110 (Business)” is the new VLAN I’m tinkering with. I’m a little hazy on the off-bridge and “in the same bridge” concepts. I believe I really want to create this VLAN separate from the default “bridge” bridge because the default DHCP server is handing out IPs to “bridge”. Am I correct in presuming that I need to assign a bridge to each VLAN to allow me to assign the separate DHCP servers, or would one DHCP server assign IPs to the different mac addresses from multiple pools?
My goal is to allow a client PC plugged into a port to get one VLAN, while an administrative PC plugged into the same port would go to management VLAN. Wouldn’t configuring port-based VLAN for access ports break this intended functionality? I did have the trunk configured when I was on-site, but I deleted it in returning the network to its normal functional state. Ultimately CRS only needs managed on the management VLAN, which doesn’t yet exist. I started by adding switch1-cpu and a test port to a VLAN and locked myself out of configuring the CRS on all other ports. I reversed that quickly, as I’m only able to remotely manage the CRS from the business network at the moment.
The interface list was there by default; I have only added some description to the items that were there. I’m okay with deleting it if it serves no purpose but was not aware it was unnecessary.
Noted. Only issue there is adding a second DHCP server was marked “invalid” and I couldn’t figure out why. I think the best step forward for this particular note is to try to configure it again when I’m on-site and do another export if it doesn’t work.
As mentioned in #2, I definitely prefer to keep it this way (address property is an entry in pool), as this has worked quite well for a couple years. Comment property is more mess than helpful unless the interface is reworked.
& 9. Months ago I was working with firewall rules to allow outbound traffic from mail server and RDS server on port 25 but disallow all other port 25 outbound, and my intention was to eventually use this list to allow outbound traffic only on known ports. I did find that unless I was specific on my firewall rules, unexpected forwarding could happen (such as SMTP traffic being routed to our internal mail server instead of someone’s GMail). Rules below the “add action=accept chain=forward” are the ones I had moved there to disable them but did not want to delete them yet. At some point I intend to get back to this project, but time is a finite object. That being said, perhaps firewall is not an efficient place to manage the firewall in this manner? It’s worked pretty well so far, but maybe there’s improvements to be had here.
Your example of using a firewall rule looks like good advice for preventing all communication for a fully isolated VLAN such as the backup VLAN. Am I correct in assuming that if I want one-way inbound traffic with responses back then I’d set one action to allow and the other to filter out existing connections from the drop action?
You can keep using single bridge with vlan interfaces. As you’re dealing with VLANs using switch chip, VLAN separation should be maintained by properly configured switch chip and by using vlan interfaces. If wifi is active, configure it with vlan-mode=use-vlan vlan-id=. Then you assign separate DHCP servers to each vlan interface where needed, and configure it with appropriate address pool(s).
I’ve never dealt with mac-based VLANs, but my understanding is that mac-based vlans are overriding port-based vlans. But I may well be wrong here. I’d first try to have VLANs working in the simpler (port-based) scenarion and would add mac-based setup when simpler setup works …
Interface lists do serve purpose … but doesn’t seem to have purpose in your particular config. See example below …
Re firewall: default firewall has action=accept connection-state=established,related rule pretty high on the list. This rule takes care of most replies which means that further rules only deal with initial packets. If you had this rule active and wanted to allow connections from VLAN1 to VLAN2 and not in the other direction, then you’d keep only the second rule …
Example of use of interface lists: let’s say ether1 is WAN interface and ether2 and ether3 are LAN ..
Want to plug WAN line to sfp-sfpplus1 interface? No problem, add sfp-sfpplus1 interface to WAN interface list and you’re done with firewall and NAT. Want to add wireless to LAN? Sure, add wifi interface to LAN interface list …
Also MAC-based access to RB is by default limited to LAN interface list …