Firewall rules for an interface on a different subnet

RouterOS Beginner Basics
1

I have been doing some experiments with my Mikrotik hAP AC² and my home LAN.
My goal is now to set an interface of my Mikrotik apart from the rest of my LAN in order to enable it get traffic from internet without being affected by any mikrotik firewall rules, and isolate the two subnets as well.
Ok, I removed an interface from the bridge, set an IP for it in a different subnet than my bridge. I added the IP and its subnet to my mikrotik’s address list tab. I then set an Ip on the same subnet for my pc connected to the interface I removed from the bridge.
I’d like now to make sure that the two subnets wouldn’t talk each others, but I want just a pc (say 192.168.8.100) on the bridge get access to the pc on the second subnet (192.168.10.2). Futhermore, I’d liek to make sure that any interent traffic from and to 192.168.10.2 is not effected by any mikrotik rules
Which rules should I set in the firewall, ans what should I check?

Thanks

2

Provide a diagram

3

As for the rules I was thinking about something like this:

ip firewall filter add chain=forward src-address=192.168.10.0/24 dst-address=192.168.8.0/24 action=drop

ip firewall filter add chain=forward src-address=192.168.8.0/24 dst-address=192.168.10.0/16 action=drop

I want now to enable 192.168.8.100 get access to, say, 192.168.10.2.
What should I do?
Thanks

4

A cleaner simpler approach is only to add to the existing default rules:
a. users rules where you need to provide additional access
b. last rule dropping everything else.

FORWARD CHAIN
[default rules - fasttrack, allow established/related, drop invalid packets etc…]
User Rules examples:

  • allow subnet or vlan to internet
  • allow admin pc to all subnets or vlans
  • allow shared use of device(printer) between two separate subnets/vlans
    etc.
    Last Rule
    add chain=forward action=drop comment=“Drop all else”

This assumes subnets are separated by either bridges, or off a bridge, or vlans etc… (Layer 2 separation).
FW rules are only for L3 separation.

5

Can we please deepen these aspects? I’d like to make sure that I get it right

I now have this rules set:

/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=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=\
    127.0.0.1
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

What should I add to these rules above?
Thanks

6

(1) In the Input chain I would take this rule.
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN

Change it to this (as this rule includes everything noted above and more and put it as your last rule in the input chain.
add action= drop chain=input comment=“Drop all else”

(2) In the forward chain, I am not sure why untracked is there but if is part of the default it must be okay??
add action=accept chain=forward comment=“defconf: accept established,related, untracked”
connection-state=established,related,untracked**???**

(3) This rule in effect permits port forwarding but configured in a drop rule - a weird not-intuitive approach..
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=
!dstnat connection-state=new in-interface-list=WAN

But I prefer (allow rules in user rules) and a cleaner looking/reading rule!
add action=allow chain=forward comment=“allow port forwarding” connection-nat-state=dstnat

(4) What you need to add as last rule in the forward chain.
add action=drop chain=forward comment=“Drop all else”

7

Be very careful with (1)! If you change the rule before you add some other which will allow access from LAN, you won’t be able to connect to router. It may not be too bad, because connection to MAC address should still work, but anyway.

Before adding unconditional drop rule, it’s better to add unconditional logging rule and check what it logs (= what will be dropped when you change it to drop rule). Reconnect to router and only if your connection is not logged, it’s safe to add drop rule.

8

Hi Sob, not sure what you meant (discuss below) but it did get me to thinking about another slight modification.
The INPUT drop all else rule (last rule) should be installed prior to removing the rule noted in (1).
So that external attempts to access the router are still effectively stopped during the brief time period while changing the rules (assuming live connection to the internet).
However we need to safeguard admin access to the router via the Input chain as a FIRST STEP!!

Now I understand.
The rule in question does not permit traffic from the LAN explicitly its simply dropping traffic not from the LAN.
Ahhh, okay so that traffic is not blocked with the OPs setup but as soon as I add my drop all input rule then LAN traffic is blocked.

Thus to address that I should state at least one other rule that I use in my own config (allow admin PC access to router via input rule).
There may be need to allow port 53 to the router and any other service as well.
I like the idea of your logging rule to see which traffic is being dropped to understand from the LAN Side what traffic is being blocked which you may wish to allow.

Interestingly you didn’t comment on the UNTRACKED ??

9

So for the OP…
*****You will see the third rule states that incoming traffic from interfaces noted as RBwin and with source identified in src-address list are allowed to access the router (for admin config purposes).
In my case, the src-address list identifies the admin PC IP, and also the IP address the admin gets when attaching a pc to a subnet that only the admin uses and thus wants to be able to access the router when troubleshooting while on that subnet.
For extra paranoia I also detail the incoming interface - RBWin is an interface list I created, that includes the VLAN interface the admin PC is on and the vlan that describes the other subnet no one else uses.

As Sob pointed out, without this rule, I would have difficulty configuring the router when implementing the last drop all rule in my config! I also have DNS allow rule so LAN users have access the DNS service.

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" \
    connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="Allow ADMIN to Router" \**********************************
    in-interface-list=RBwin src-address-list=adminaccess
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
    connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
    connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="DROP ALL ELSE" log-prefix=\
    "INPUT DROP ALL"

You could make a much simpler rule for your access…
add action=accept chain=input comment=“Allow ADMIN to Router” *********************************************************************
in-interface=LAN src-address=AdminPC_IPaddress

Finally, if you want to implement Sobs idea, which is really a cool use of FW rules for a newbie or me an oldie who has limited knowledge (Faux Guru Status),
The concept is you want to see all the traffic that gets looked at by the next rule. So you put the logging rule just prior to the rule in question. Here it is…
add action=log chain=input comment=“Log Dropped Traffic”
(You will also want to add a LOG PREFIX text entry same spot where you delineate action= log in winbox so that when you go to the LOG page in winbox those entries will be easier to spot.)

10

Hi everyone,
First thing first, thank you all for your comments.
Please consider that I’m a newbie. In this case I first want to make sure that I correctly set the basic firewalls rules before going ahead and dealing with my final purpose which is, in this case, not to allow different subnets (on the bridge and the interface I removed from it) to talk each other, BUT to enable my main PC ( 192.168.8.100) on the bridge to get access to the PC on the second subnet (192.168.10.2). So a step at a time.
As far as I’ve understood, I should get rid of many rules, and just stick with these ones as my first step:

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=allow chain=forward comment="allow port forwarding" connection-nat-state=dstnat

Then add the other rules according to my needs I told you about.
BUT
What about these ones:

add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
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

Why should I delete rules about icmp, capsman etc.
Thanks

11

Hi Mur,
Sorry about that will dial it back and try to explain more so it becomes clearer.
First comment is dont mix and match input and forward chain rules.
List all the input rules together in the order in which they should be actioned, followed by the forward chain rules as I did below.

In general, If those are default rules then they do no harm.
They are usually intended to cover off all the possible services you may use on the router such as ipsec (VPNS) or capsman etc…
They can be removed if not using those services but if you leave them there, no harm done.

/ip firewall filter
{input chain}
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1

{forward chain}
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
+++++++++++++++++++++++++++++++++++++++
add action=allow chain=forward comment="allow port forwarding" connection-nat-state=dstnat
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

So using this as as starting point.
(1) Next you want to ensure that the subnet on the bridge cannot talk to the subnet off the bridge and vice versa. Since they are separated by a bridge, they will not see each other in Layer2.
To stop the router from routing them (layer3), simply add a last rule to the Forward chain. When someone tries to reach the other subnet either way, the firewall will go through your list of rules to find a match and if so execute the rule. If there is no match it will move to the next rule. In our case it will reach the last rule and drop the request.
You could make up two Drop Rules subnet A to subnet B drop, and subnet B to subnet A drop, but that is less efficient than one simple rule. Imagine if one has many interfaces, bridges, vlans etc, it gets messy fast!!

(2) Next you want to be able to from a single PC on the bridge to access a single PC on the other subnet.
Add any user made rules where I put the line ++++++++++++++++++
As per the previous example, the Router will examine your forward chain rules and when it finds the rule that matches it will execute that rule and allow your traffic to reach the PC and any return traffic associated. Note it will NOT allow the other PC to initiate any conversation or reach your PC. (since we did not make a rule allowing that, and thus such a request as per above would get dropped by the Last Rule.

{forward chain}
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward destination-address=192.168.10.2  (target PC)  source-address=192.168.8.100  (your PC) in-interface=bridge (request has to originate from the bridge)
add action=allow chain=forward comment="allow port forwarding" connection-nat-state=dstnat
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=drop chain=forward comment="Drop all else"
12

It makes much more sense to me now.
So the final setup would look something like this:

add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1

add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward destination-address=192.168.10.2  (target PC)  source-address=192.168.8.100  (your PC) in-interface=bridge (request has to originate from the bridge)
add action=allow chain=forward comment="allow port forwarding" connection-nat-state=dstnat
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=drop chain=forward comment="Drop all else"

This new rule below:
add action=drop chain=forward comment=“Drop all else”

has replaced my old one:
add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=
!dstnat connection-state=new in-interface-list=WAN

Why?

More, what is fasttrack for? Is it useless?

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=\
    established,related

Last thing, I do some reading about input chain and forward chain, but I don’t think I really got the difference between them?
Thank you very much indeed

13

You’ll want to allow also other stuff, for example access from LAN to internet:

/ip firewall filter
add chain=forward src-address-list=LAN dst-address-list=WAN action=accept

With the unconditional drop at the end, everything you don’t allow will be blocked. That’s the change from previous rule, where new connections from internet were blocked (except forwarded ports) and everything else was allowed.

Fasttrack: https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
TL;DR: it speeds things up

Chains: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow#Routing_Diagram
TL;DR: forward is for traffic going through router (e.g. devices in LAN connecting to internet), input is for traffic to router itself (e.g. connecting with WinBox)

@anav: Untracked is good. It’s when you mark packets as untracked in /ip firewall raw. But usually you don’t need it.

14

Okay, one item at a time.

  1. The rule we replaced had two functions.
    a. It allowed destination nat to occur through the firewall for any port forwarding you may wish to do in the future.
    b, It stopped all new traffic coming from the WAN that was not coming in on a recognized destination port (this is based upon what you have setup for firewall NAT rules).

Since I find this rule overly complex and confusing for the newbie I prefer to break it up such that, i still have an allow destination nat rule that is clear/direct and simple.
add action=allow chain=forward comment=“allow port forwarding” connection-nat-state=dstnat

The short story: What it is saying ( I think in conversation, is that any traffic coming through the router that has a destination port that is identified in one of my NAT rules, shall be allowed to pass through the firewall and reach the server IP identified in my destination nat rule.

The long story: A bit more info to discuss since its kinda done in layers or steps. First, the Router handles incoming traffic at NAT before the other forward filter rules. In other words, the incoming port matches a destination nat rule and is thus processed and the router now knows where to send the packets once passed by the firewall forward rule. So the traffic then hits the forward filter firewall chain. Since this is a NEW connection at the forward filter it goes down the list of rules till it finds a match. Since the router will find our destination NAT rule, the traffic is allowed to pass to the server. Typically there is a conversation back and forth now between the external user and the Server. The associated traffic coming from the external user then gets matched earlier in the list of rules the forward chain!!
add action=accept chain=forward comment=“defconf: accept established,related” connection-state=established,related

The drop all else rules drops all the traffic noted in 1 b. plus all other traffic that is not covered by the rules you enter to allow traffic. A catch all rule if you will. very effective!!

  1. Okay item number two. FAST Track is a way to speed up traffic in the router. It has a small engine that does nothing but track traffic around the router. With fast track enabled, the router allows shortcuts that in effect speed up traffic through the router. There is no downside. However to use some of the more powerful functionality with the router fastrack is disabled, I believe automatically??.

  2. Sob rightfully noted that BEFORE YOU PUT THE LAST RULE IN PLACE, the drop all rule, ensure you have all the traffic you wish to allow identified.
    ex.
    your pc to specific pc
    subnet A access to internet
    subnet B access to internet
    subnet A access to a shared printer in Subnet B etc…

  3. I see that you do not have a drop all rule on the input chain. That is okay for now. I would right away however put the following rule in place so YOU can always access the router, no matter what you do later…
    action=accept chain=input source address=yourPC IP address in-interface=bridge (or vlan whatever interface your pc uses).
    Once you figure out what legitimate services are using the input chain then you can add them as a user rule and eventually drop all else on the input chain as well. The log rule discussed earlier will show you all that traffic.

  4. The chains for firewall access or denial, in simple terms. INPUT = TO the ROUTER, FORWARD = THROUGH the router.
    If I want the Router to respond to an ICMP ping from an external source, then the rule has to be in the Input Chain.
    If I want an external user to access my server on the LAN, it has to a forward chain rule.

Chains work in all directions…
Input to the router can come from the internet or the LANS (internal or external)
Forward can be through the router going IN, can be through the router going out, can be internal to the router from lan to lan…

  1. Lastly, there are security steps to take with respect to WINBOX and router access but probably best for another day.
15

Ok, I’ll add this rule to my list above in my previous post. Thanks.


Fasttrack: > https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack
TL;DR: it speeds things up

Ok, I’ll then keep it in my first list
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=
established,related


Chains: > https://wiki.mikrotik.com/wiki/Manual:Packet_Flow#Routing_Diagram
TL;DR: forward is for traffic going through router (e.g. devices in LAN connecting to internet), input is for traffic to router itself (e.g. connecting with WinBox)

Thanks, but it is a bit hard for me to make sense of it, at least now; I’m still learning the basic.


@anav: Untracked is good. It’s when you mark packets as untracked in /ip firewall raw. But usually you don’t need it.

Good! Thanks

16

Great explanation, thanks. I’m not only learning over time how my Mikrotik device works , but also I am delving deeper in computer Networking thanks to it. That was the main reason why I bought it. I didn’t need it actually…not yet.
Thank you all guys. Very useful forum.