I got to put in firewall rules to separate the vlan from the office. Can you give me direction?
A firewall provides the best protection if it drops everything by default and only lets through exceptions you want to let through. The firewall rules provided in the default configuration of the hXX product line of Mikrotik do exactly that, but with some optimisation which complicates readability. So instead of three simple rules
action=accept in-interface-list=WAN connection-nat-state=dstnat
there is a single complex one in chain=forward
of /ip firewall filter
action=drop in-interface-list=WAN connection-nat-state=!dstnat
The effect is the same as long as you only have two logical groups of interfaces (or zones) - the WAN one(s) and the rest.
In your case, you have three zones - the internet (represented by interface-list WAN), the internal network for you and your colleagues/employees, and the network for customers/guests. So as for chain=forward
, which deals with traffic passing through the Tik, using the "what to forbid" thinking, you basically need that
- no connection can be initiated by a host in the internet towards a host in any of the two internal zones
- no connection can be initiated by a host in the zone GUEST (represented by the /interface vlan vlan-id=10) towards zone STAFF (represented by /interface bridge name=bridge1) and probably vice versa (no reason for your staff to connect to guests' devices).
The rest is allowed.
But the same can be also viewed from the "what to permit" perspective, and that way it is even simpler:
- permit anything from GUEST or STAFF to initiate connections to WAN
The rest is forbidden.
As we talk here about a stateful firewall, the detailed rules only deal with the initial packet of each connection; if we permit it, the first two rules saying "fasttrack whatever belongs to already existing connections or is related to them" and "accept whatever belongs to already existing connections or is related to them" take care about the rest of the connection.
So without optimisation, you would rename the existing interface-list
LAN to STAFF, create another interface-list
named GUEST and make the /interface vlan vlan-id=10
a single member of it, and then replace the very last rule in chain=forward by the following three ones:
chain=forward action=accept in-interface-list=STAFF out-interface-list=WAN
chain=forward action=accept in-interface-list=GUEST out-interface-list=WAN
Optimisation is possible due to the fact that the handling of STAFF and GUEST is actually the same - both can connect to external servers via WAN but cannot establish connections to each other. So you can use just two rules (and don't need to modify and add any interface-list
chain=forward action=accept in-interface-list=!WAN out-interface-list=WAN
But bear in mind that "optimisation" and "simplification" are not synonyms. Less rules mean less CPU load (so optimisation), but more brain load when you try to understand what you did 3 months ago, so not necessarily a simplification from this point of view.
As for chain=input, it controls access to your Tik itself. But there are three types of services awaiting connection:
- actual services for clients, such as DNS or NTP
- network control protocols, such as ICMP, VRRP, OSPF and others
- management of the router itself
Given that cross-platform malware exists these days, it is best to prevent access to management of the router even for the STAFF zone. So creating yet another IP subnet and attaching it to a dedicated Ethernet interface removed from the bridge is the second safest way (the first one being to manage the device via serial console and completely disable access to management services from any zone).
But you need to permit access to DNS if you want to run it on the router.
So instead of the last rule in chain=input
of the default firewall, chain=input action=drop in-interface-list=!LAN
, the following is the minimum:
chain=input action=accept protocol=udp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=53 in-interface-list=!WAN
chain=input action=accept protocol=tcp dst-port=22,443,8291 in-interface-list=LAN src-address=ip.of.your.laptop
53 is a port for DNS; 22, 443, and 8291 are SSH, HTTPS, and Winbox ports, respectively. To make https management possible, you need to generate a certificate and bind it with the "www-ssl" service. What in-interface-list
you choose to permit access to the management services depends on your decision, and you have to configure the rest of the system accordingly (assigning an IP address to the management laptop manually or creating a reserved DHCP lease for it are necessary to use src-address
in this rule, setting up a dedicated interface and a subnet attached to it for management purposes is necessary to use in-interface(-list)
as the only restriction in this rule).
Also bear in mind that Winbox can connect to the machine also using MAC address, so completely bypassing the L3 firewall. The access using MAC-Winbox and MAC-telnet is controlled by an interface-list
you set as a value of allowed-interface-list
under /tool mac-server
. So also here, the "second safest" approach is to create a dedicated interface-list such as MAC-MANAGEMENT, put to it a single Ethernet interface not connected to any bridge, and set it as the value of the allowed-interface-list
As you want to use hotspot: it adds rules to the beginning of chain=input
to prevent unautenthicated users from reaching the rules of the common firewall and to let them access the hotspot authentication service even if access to it is not permitted in the common firewall. As long as the hotspot user gets authenticated, it is only a matter of your common rules where they will get.
Before adding the hotspot, I'd recommend you to remove the /ip address
, /ip pool
, /ip dhcp-server
, and ip dhcp-server network
(which you've used for testing) from /interface vlan vlan-id=10
, as well as any existing configuration in the /ip hotspot
tree, and then run the /ip hotspot setup
wizard which will do all that for you from scratch and interlinks the configuration elements properly.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.