I am new to Mikrotik and have had help with my config from someone who is more versed with RouterOS. I have had the same firewall rules on both CRS310 and RB5009. On the CRS310 it works as expected, however on the RB5009 it does not work at all.
Wondering if it is a genuine bug or some config.
I have 3 rules
Accept 3389 RDP from MainLAN to WorkLAN
Block MainLAN to WorkLAN
Block WorkLAN to MainLAN
If I disable 2 I can get to both lan from each other
If I enable 2 and disable 3 I can get to both lan from each other
If enable all 3 I can’t see the LANs from each other but also can;'t RDP from Main to Work.
try inserting protocol TCP dstport 3389 in the accept rule and ditto for UDP. Otherwise, reset the packet counter and see when you start the rdp session which rule increments the packets
It’s unclear to me how it could have worked on the CRS310 at first place.
In today’s world, there are not enough abbreviations to stay unique, so there is the Reliable Data Protocol most of us have never heard of before, and then there’s the currently popular Remote Desktop Protokol, which is an application layer protocol that uses TCP, and sometimes UDP, as its transport.
The protocol field in firewall rules matches on IP protocol types, like UDP, ICMP etc., so a rule matching on protocol=rdp can only match on IP packets carrying the Reliable Data Protocol; to make this rule match on Remote Desktop Protocol packets as you actually need, you have to keep dst-port=3389 in place but change protocol to tcp; for better performance, copy this rule right below the existing one and change protocol to udp in the new one, as Microsoft RDP can switch over to UDP where doing so brings an advantage.
Other than that - given that the default handling in Mikrotik firewall chains is “accept”, your firewall allows packets coming in via WAN to reach devices in your LAN. In contrary to popular belief, src-nat is not a sufficient protection against such packet, so highly theoretically, neighboring customers of your ISP might be able to establish connections to your LAN.
I personally prefer to have an action=drop rule without any match conditions in the end of input and forward chains of filter and a bunch of action=accept rules before it, selectively matching on initial packets of connections I want to permit. If you forget to add a permissive rule to a firewall blocking everything by default, your legal users will quickly let you know; if you forget to add a block rule to a firewall permitting everything by default, your illegal users will take great care to keep you unaware of that.
Ok so if I have disabled rule 5 Accept, Established, Related and Untagged
I can’t ping between the networks as intended but I also can’t use port 3389 from main to work.
If I enable this I can get to 3389 and able to ping between networks. I only want to be able to get to 3389 and not have any other traffic between them.
This rule appears quite important but is creating a headache.
Can someone explain what it is doing and how I can get round it.
in terms of the packet counter when I reset it and try and get to port 3389 and can see the packets hit the rule but it still doesn’t; connect.
To understand the role of the “accept estabilshed, related, or untracked” rule, you have to grasp the concept of “stateful firewall”, which is centered about a “connection tracking” module that compares any received packet with a list of known ongoing connections and depending on the results of the comparison, it labels it with an additional attribute, connection-state; the value of that attribute can be new if the packet does not belong to any existing connection directly or indirectly and is capable to create a new one if accepted later in the filter, established if it directly belongs to an already established connection, related if it belongs to it indirectly (such as an ICMP “fragmentation needed” reaction to an oversized TCP packet belonging to an established connection), invalid (if the addresses and ports of the packet match an existing connection but the internal status information does not match the current internal state of the connection, such as a data packet received after a FIN one), and untracked (which is set if a rule in raw has exempted the packet from being handled by connection tracking the usual way).
Based on this approach, you can let the rule you don’t like handle all the “mid-connection” packets, reducing the amount of CPU spent per an average packet, and only use all the rules following this one to deal with the initial packet of each (potential) connection.