Traffic passes firewall rules - what I don't understand?

RouterOS General
1

Hello everybody,

I’m relatively new to RouterOS but I believe I have basic network knowledge. I must have done something wrong but I can’t figure what. Device is RB952Ui-5ac2nD-TC.

I’m trying to create separate network for router management and another network for normal users. Wireless and ethernet ports (all but one) are bridged and within 192.168.88.0/24 network (IP of the router is 192.168.88.1). Only one ethernet port is not part of the bridge and that port should be in management network for router configuring (IP address of that port is 192.168.87.1).

Idea is that only wired connection to ethernet port that is not part of the bridge (192.168.87.1) should be allowed access path to router.

Traffic from bridged interfaces to router is blocked with firewall rules, and that works as expected. Every client use static configuration, IP-s in it’s range and use gateway 192.168.88.1 and clients can access Internet but have no access to router.

I tried to block traffic between 192.168.87.0/24 and 192.168.88.0/24 by firewall rules (tried input and forward chains) on appropriate interfaces.

What confuses me that if I connect to ethernet port for network management with IP 192.168.87.2 and set gateway 192.168.87.1 everything work fine, but if I set gateway to 192.168.88.1 (IP of client is still 192.168.87.2) access to router is allowed (in WinBox (by IP address) and also WebFig). I can’t figure why and I would like to understand what I’m doing wrong.

Thanks for your help.

2

Are you sure you’re talking about gateway=192.168.88.1 in this context? I can’t see a condition a gateway outside a connected network would work on a regular client computer.
Either way - it looks like your input filter rule is missing something.
I could bet you created a rule or a set of rules in the input chain that only matches the src-addresses and probably in-interfaces.
Try to add dst-address=192.168.88.1 to that rule(s).

You should probably disable MAC-server on the 192.168.88.0/24-facing interfaces as well.

Good luck!
-Chris

3

Hi, Chris,

maybe I don’t understand as well as I thought that I do. Picture should be worth a thousand words (bridge interface is for normal users, ether4 is for management).
Scr01.jpg
How can this work? Shouldn’t above firewall rules block all traffic between 192.168.87.0 and 192.168.88.0? (I’m getting same result if I change chain to input.) I’m able to access web fig with IP address 192.168.87.1 with gateway IP address set to 192.168.88.1 from client computer with IP address 192.168.87.2. I’m just trying to understand and learn why this works.

Thanks for suggestion on MAC server, and for your help.

4

Please show config information using /export instead of ‘screenshot’.
In this case: /export firewall

Do you understand the concept of the Linux iptables firewall?
Did you read about the function of the input and forward chains?

5

Remove in-interface on the forward drop rules !

6

Try to traceroute the connection to another host? I think it is not routable, but switchable. Try to check that management port is not in the same switch-group with bridged port. Ethernet interfaces, master-port, e.t.c. Your connections must be Layer 3 filtered, not Layer 2.

7

I’ve been using PFSense for some time, but now I’m trying to learn and understand RouterOS (much more complicated but also, as I can tell, more powerful).

First I tried input chain in firewall rules, forward chain in screenshot was (failed) experiment. As I understand Input chain handle incoming connections and if I try to connect to router from client then it should be handled by input chain on router?

I’m not sure that I understand correctly. Traffic is started from IP address 192.168.87.2 (client IP) with destination IP address 192.168.87.1 (router IP). But if client had gateway IP address set at 192.168.88.1, should’t traffic be going first from to gateway (192.168.88.1) which should then pass it to destination address (192.168.87.1) and shouldn’t traffic be droped by rules that prohibit traffic between 192,168.87.0 and 192.168.88.0? Since traffic was supposed to be passing between non-bridged interfaces I was confused if maybe I should use forward chain (it seem that I shouldn’t) or input chain.

Regretfully, removing in-interface on forward chain drop rules didn’t make a difference.

Regarding screenshot, I thought that picture will be more informative, so sorry, my mistake. Here is firewall configuration:

/ip firewall filter
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
add action=drop chain=input comment=“blocked traffic from 88 to 87” dst-address=192.168.87.0/24 src-address=192.168.88.0/24
add action=drop chain=input comment=“blocked traffic from 87 to 88” dst-address=192.168.88.0/24 src-address=192.168.87.0/24
add action=drop chain=input comment=“blocked traffic from bridge interface to router” dst-address=192.168.88.1 in-interface=bridge
add action=accept chain=input comment=“disabled - test only - allowed access to router from single 88 address (192.168.88.2)” disabled=yes dst-address=192.168.88.1
in-interface=bridge src-address=192.168.88.2
add action=accept chain=input comment=“allowed access to router from single IP from management port (ether4)” dst-address=192.168.87.1 in-interface=ether4 src-address=
192.168.87.2
add action=drop chain=input comment=“blocked traffic from management port” dst-address=192.168.87.1 in-interface=ether4
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
add action=accept chain=forward comment=“defconf: accept in ipsec policy” ipsec-policy=in,ipsec
add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade” ipsec-policy=out,none out-interface-list=WAN

Everything else is working as I expected, but I would like to understand what’s going on, because it’s obvious that I don’t understand what’s going on in this case.

Thanks for all replies.

8

Try this rule set and look at my changes.

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=forward comment="block traffic from 88 to 87" dst-address=192.168.87.0/24 src-address=192.168.88.0/24
add action=drop chain=forward comment="block traffic from 87 to 88" dst-address=192.168.88.0/24 src-address=192.168.87.0/24
add action=accept chain=input comment="allow DNS requests from 88" protocol=udp dst-port=53 dst-address=192.168.88.1 src-address=192.168.88.0/24
add action=drop chain=input comment="blocked traffic from bridge interface to router" dst-address=192.168.88.1 src-address=!192.168.87.0/24
add action=drop chain=input comment="blocked traffic from management port" dst-address=192.168.87.1 in-interface=ether4
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

It might be beneficial that connections from mgmt (87) to LAN (88) are allowed. Then you need to alter the rule set a bit with connection states (allow new connections from 87 to 88, allow established and related from 88 to 87 and drop the rest.

Good luck,
-Chris

9

Management port has no master port (it’s not on bridge (all other ports are)).

There are no other hosts on management network (as I would like to use it only when necessary, and only from single wired port) and on hosts on 192.168.88.0 range traceroute reports Destination host unreachable.

Not sure if it’s relevant, all ethernet ports have (under General tab) stated “Switch: switch1”.

Would you be so kind to explain what you mean with “it is not routable, but switchable”? Do you mean that this kind of connection is established at Level 2 (MAC addresses) and Level 3 (firewall rules) does not apply? Or did I got everything wrong?

10

Your rule is in chain forward. And you trying to get access to the router’s IP 192.168.88.1, so it is input chain, and it is allowed. There is routing, but it is only lookup of the host’s IP in the routing table. It is ok, because the router have multiple interfaces. In order not to decrement TTL of IP packet multiple times, router will answer only once, if he have the destination IP. In order to mitigate this access(in security reasons), you don’t need to add thousands of drop rules, but you need to setup DHCP server with option of adding arp for leases and setup arp-reply only for this interface in order to lock down static IP connectivity. And hosts behind this interface will forced to work only by dhcp, and their wiil be the gateway you set, not them. If the client realy need static IP, then you should use input rule on terminating interface.

11

Thanks everybody for their time, I really appreciate your help. Maybe I should explain what I’m trying to do.

Mikrotik device should be wireless access point for 192.168.88.0/24 wireless clients with DCHP server with pool 192.168.88.10 - 192.168.88.254. Wireless clients should only be allowed to access Internet. They are not allowed to comunicate with each other (I disabled Default forward), they are not allowed to access router or communicate with other parts of network (apart from exit to Internet). Mikrotik has 5 ethernet ports, ethernet port 1 is connected to PFSense router which handle all other (wired) network (firewall, OpenVPN, proxy server…) and handle Mikrotik’s access to Internet. Three other ethernet ports are in bridge with wireless interfaces, for possible future use (but maybe I should disable them, at least for now).

192.168.87.0 network should be only for Mikrotik management and accessible only from one physical ethernet port which is not part of bridge with other interfaces. Mikrotik router should be accessible from only one, predesignated, IP address (192.168.87.2) as additional layer of security (more obscurity, but still some additional security). Potential unwanted user should know to connect to particular ethernet port (not different in appereance from other ethernet ports) and with client that has predesignated particular IP address (my plan is that DHCP Server should not be active on that interface). That additional level of obscurity is not strictly neccessary, since router is in locked room, but I’m trying to understand and learn RouterOS so this is just part of process of learning.

Everything is working as expected, but when I tested configuration, only thing that I didn’t understand is what I’m asking here, why firewall rules didn’t block access from IP 192.168.87.2 to 192.168.87.1 by gateway 192.168.88.1. if these rules block communication from 192.168.87.0 to 192.168.88.0. Ping to 192.168.88.1 returns Destination host unreachable. Maybe I don’t understand what is gateway?

From my experience, if I don’t understand something it’s always good starting point for learning. I understand that there are many things I don’t understand, so it’s a start :slight_smile:

@ cdiedrich - Thanks for your suggestion, maybe I didn’t explain configuration enough before, but I’m not sure that I understand, so please help, your set of rules excluded rule:
“add action=accept chain=input comment=“allowed access to router from single IP from management port (ether4)” dst-address=192.168.87.1 in-interface=ether4 src-address=192.168.87.2”

Shouldn’t I block myself access to router if I exclude that rule because of other rules?
add action=drop chain=input comment=“blocked traffic from management port” dst-address=192.168.87.1 in-interface=ether4
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
I’m not sure if I understand correctly, shouldn’t rules you changed allowed access to DNS but block other traffic from 192.168.88.0 (and allow only access from 192.168.87.0)
add action=accept chain=input comment=“allow DNS requests from 88” protocol=udp dst-port=53 dst-address=192.168.88.1 src-address=192.168.88.0/24
add action=drop chain=input comment=“blocked traffic from bridge interface to router” dst-address=192.168.88.1 src-address=!192.168.87.0/24

@ Anumrak If I understand you correctly, you suggest that, using your solution, I enforce DHCP on that interface, and, by that, ensure that gateway for client is set by router rules and not client rules? That is certanly good solution, but I was thinking about dditional level of obscurity by enforcing access to router only from predefined IP address, without DHCP. I don’t really need that, but now I would like to know how/why above described situation works. Could you be so kind to explain what should be terminating interface in this situation and if input chain is applicable here?

Again, thanks everybody for your effort.

12

Terminating interface should be the address of clients subnet. It is standart. If you need predesignated IP’s without DHCP, you should use static arp records. IP will bind to only one mac, and shouldn’t be given to another mac. You need to define the hardware interface, in wich you will create this binding(IP - ARP). After that, client shouldn’t get access to another gateway, wich located on another interface. If this will fail, and you want to control the access to the router’s IP such as 87.1, 88.1, you have to use the input chain of firewall filter. Forward chain works only if destination IP is not the router’s itself.

13

I’ll adapt Anumrak suggestion and use it as a solution to my situation. Still, I don’t understand why firewall rules on input chain stated before didn’t block traffic in described situation. Maybe I’ll understand it some day :slight_smile:

Thanks.

14

Because actions of your input rules are accepting, not dropping some specify traffic or some other actions. Click on your rules and study every tab. Be careful, with dropping input actions you can cut off the access to router.