Community discussions

MikroTik App
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

VLANs: Communicate with self

Tue Mar 07, 2023 7:57 pm

There is the thread "Using RouterOS to VLAN your network":
viewtopic.php?f=13&t=143620

In that there, there is the post of "Router-Switch-AP (all in one)":
viewtopic.php?f=13&t=143620#p706998

I followed the steps and written the VLANs that I want.

But, the VLANs only responsible for L2.
Now I need to setup L3 restrictions using IPv4 Firewall.

I want that *some* (NOT all) of the VLANs will be able to communicate with themselves.
In other words, a client which is associated with VLAN#3 will be able to communicate with other clients which are also associated with VLAN#3.

Let's assume that the VLAN interface name is "VLAN_interface_name" (created with the menu "/interface vlan").

In that case, then the firewall command should be:
/ip firewall filter
add chain=forward action=accept      \
in-interface="VLAN_interface_name"   \
out-interface="VLAN_interface_name"  \
comment="Allow VLAN to communicate with itself on L3 level"

Obviously, the last firewall filter drops all the packets (so my firewall is only accepting specific packets and dropping all the rest.)


Is this how I should perform this or maybe there is a better/conventional approach?
Last edited by moveik on Wed Mar 08, 2023 10:21 pm, edited 2 times in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19325
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: VLANs: Communicate with self

Tue Mar 07, 2023 10:42 pm

Here is a properly formed forward chain part of the firewall rules.
I will assume you have interface lists, the need for internet and port forwarding.....

{forward chain}
(default rules)
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

(admin rules)
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
*************************************************************************************************************************
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward[/i]

Now, you should note the last rule which is drop all! In other words, at L3 (ip address), all traffic is dropped unless it has matched any of the existing ADMIN RULES.
So lan to wan for internet, or port forwarding.

*********** This is where you need to put additional ALLOW RULES for needed traffic as everything else is already blocked.

In the forward chain, we have some default rules at the top (first three) and then Admin allocated rules.


Lets take the case where one has 5 vlans, vlans10-50. Vlans10-30 need internet. VLANS 10-40 need to access a shared printer on vlan50 (192.168.50.12/32).
VLAN10,20 should also be able to access vlan40,50.

/interface list
add name=WAN
add name=LAN
add name=Internet
add name=IOT/Devices


/interface list members
add interface=vlan10 list=LAN
add interface=vlan20 list=LAN
add interface=vlan30 list=LAN
add interface=vlan40 list=LAN
add interface=vlan50 list=LAN
add interface=vlan10 list=Internet
add interface=vlan20 list=Internet
add interface=vlan30 list=Internet
add interface=vlan10 list=TO_devices
add interface=vlan20 list=TO_devices
add interface=vlan40 list=IOT-devices
add interface=vlan50 list=IOTdevices


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=accept chain=forward comment="allow internet traffic" in-interface-list=Internet out-interface-list=WAN
add action=accept chain=forward comment="allow shared device access" in-interface-list=LAN dst-address=192.168.50.12
add action=accept chain=forward comment="lim access to iot-devices" in-interface-list=TO_devices out-interface-list=IOT-devices
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"


Thus you can see that if you need to identify one IP address, use the IP address,
If you have 2 or more subnets in a rule, its easiest to make an interface list entry.
If you want to identify a single subnet, you can either use in/out-InterfaceName or src/dst-address=SUBNET

The time to use firewall address lists ( for src/dst-address-list= ) is when you have a group of users within a subnet but not the whole subnet or even a group of users from various subnets.
Also anytime you have that plus whole subnets. Then just add the subnet(s) to the firewall address list as well.
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

Re: VLANs: Communicate with self

Wed Mar 08, 2023 10:20 pm

Here is a properly formed forward chain part of the firewall rules.
I will assume you have interface lists, the need for internet and port forwarding.....

{forward chain}
(default rules)
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

(admin rules)
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
*************************************************************************************************************************
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward[/i]

Now, you should note the last rule which is drop all! In other words, at L3 (ip address), all traffic is dropped unless it has matched any of the existing ADMIN RULES.
So lan to wan for internet, or port forwarding.

*********** This is where you need to put additional ALLOW RULES for needed traffic as everything else is already blocked.

In the forward chain, we have some default rules at the top (first three) and then Admin allocated rules.


Lets take the case where one has 5 vlans, vlans10-50. Vlans10-30 need internet. VLANS 10-40 need to access a shared printer on vlan50 (192.168.50.12/32).
VLAN10,20 should also be able to access vlan40,50.

/interface list
add name=WAN
add name=LAN
add name=Internet
add name=IOT/Devices


/interface list members
add interface=vlan10 list=LAN
add interface=vlan20 list=LAN
add interface=vlan30 list=LAN
add interface=vlan40 list=LAN
add interface=vlan50 list=LAN
add interface=vlan10 list=Internet
add interface=vlan20 list=Internet
add interface=vlan30 list=Internet
add interface=vlan10 list=TO_devices
add interface=vlan20 list=TO_devices
add interface=vlan40 list=IOT-devices
add interface=vlan50 list=IOTdevices


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=accept chain=forward comment="allow internet traffic" in-interface-list=Internet out-interface-list=WAN
add action=accept chain=forward comment="allow shared device access" in-interface-list=LAN dst-address=192.168.50.12
add action=accept chain=forward comment="lim access to iot-devices" in-interface-list=TO_devices out-interface-list=IOT-devices
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"


Thus you can see that if you need to identify one IP address, use the IP address,
If you have 2 or more subnets in a rule, its easiest to make an interface list entry.
If you want to identify a single subnet, you can either use in/out-InterfaceName or src/dst-address=SUBNET

The time to use firewall address lists ( for src/dst-address-list= ) is when you have a group of users within a subnet but not the whole subnet or even a group of users from various subnets.
Also anytime you have that plus whole subnets. Then just add the subnet(s) to the firewall address list as well.



Thank you anav!

That is a very descriptive answer, really appreciated!
I will use that for the remaining VLAN connections.

Then, according to the following sentence that you wrote:
"If you want to identify a single subnet, you can either use in/out-InterfaceName"

I understand that for allowing packets to transfer between clients which are associated to the same VLAN, I need to use the same code that I wrote in my first post, meaning this code:

/ip firewall filter
add chain=forward action=accept      \
in-interface="VLAN_interface_name"   \
out-interface="VLAN_interface_name"  \
comment="Allow VLAN to communicate with itself on L3 level"
Please correct me if I'm wrong.
 
tdw
Forum Guru
Forum Guru
Posts: 1847
Joined: Sat May 05, 2018 11:55 am

Re: VLANs: Communicate with self

Wed Mar 08, 2023 10:56 pm

But, the VLANs only responsible for L2.
Now I need to setup L3 restrictions using IPv4 Firewall.

I want that *some* (NOT all) of the VLANs will be able to communicate with themselves.
In other words, a client which is associated with VLAN#3 will be able to communicate with other clients which are also associated with VLAN#3.
IP traffic between devices within a layer2 network, be it physical ethernet or a VLAN, will not necessarily reach the IP firewall. It depends on the network topology, if you have other switches in the network to which the devices are attached the Mikrotik will not even see the traffic.

If the devices are attached to individual ports on the Mikrotik you can use bridge filters / switch rules for simple cases, otherwise the bridge settings use-ip-firewall=yes and use-ip-firewall-for-vlan together with disabling switch hardware offload can be used to force bridged packets through the IP firewall.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19325
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: VLANs: Communicate with self

Thu Mar 09, 2023 1:48 am

NO!
They are in the same vlan they are connected at layer2, No firewall rules are required.

On the flip side you cannot use firewall rules to break up folks within a vlan as they are already connected at layer2................
There are always ways but in general..............
 
tdw
Forum Guru
Forum Guru
Posts: 1847
Joined: Sat May 05, 2018 11:55 am

Re: VLANs: Communicate with self

Thu Mar 09, 2023 3:23 am

I read the OP that there may be a need to block traffic between devices within the same VLAN, hence the reply. However if there is only a need to block traffic between devices in different VLANs then regular firewall rules are sufficient.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19325
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: VLANs: Communicate with self

Thu Mar 09, 2023 3:36 am

I was responding to this statement (to be clear).........
I understand that for allowing packets to transfer between clients which are associated to the same VLAN, I need to use the same code that I wrote in my first post, meaning this code:
 
moveik
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 54
Joined: Tue Nov 24, 2020 1:16 am

Re: VLANs: Communicate with self

Thu Mar 09, 2023 11:14 pm

But, the VLANs only responsible for L2.
Now I need to setup L3 restrictions using IPv4 Firewall.

I want that *some* (NOT all) of the VLANs will be able to communicate with themselves.
In other words, a client which is associated with VLAN#3 will be able to communicate with other clients which are also associated with VLAN#3.
IP traffic between devices within a layer2 network, be it physical ethernet or a VLAN, will not necessarily reach the IP firewall. It depends on the network topology, if you have other switches in the network to which the devices are attached the Mikrotik will not even see the traffic.

If the devices are attached to individual ports on the Mikrotik you can use bridge filters / switch rules for simple cases, otherwise the bridge settings use-ip-firewall=yes and use-ip-firewall-for-vlan together with disabling switch hardware offload can be used to force bridged packets through the IP firewall.


My network topology is the same as the scenario of "Router-Switch-AP (all in one)", as described in the post.
So it is the simplest network topology, only one device.

I want Mikrotik's sniffer to be able to capture all traffic.

I will enable the options "use-ip-firewall=yes" and "use-ip-firewall-for-vlan=yes" in menu "/interface bridge settings".
This is also required for QoS (i.e. Queues), as written in the specs:
https://help.mikrotik.com/docs/display/ ... geSettings

I looked for the "hardware offload" feature, though I only found a similar feature called "L3 Hardware Offloading".
Found it in the specs here:
https://help.mikrotik.com/docs/display/ ... Offloading

I assume these two are identical?

Apparently my Mikrotik device doesn't support "L3 Hardware Offloading" (I don't find these option in the menu).
Therefore, I assume that it doesn't exist, so I don't need to disable it - correct?


I also found "Bridge Hardware Offloading" in this link:
https://help.mikrotik.com/docs/display/ ... Offloading

My switch model is "IPQ-PPE".
So, according to the table in the specs, its default mode is non-HW offloading - quote from specs:
Currently, HW offloaded bridge support for the IPQ-PPE switch chip is still a work in progress. We recommend using, the default, non-HW offloaded bridge (enabled RSTP).

Please let me know if I misunderstood or missed something.


NO!
They are in the same vlan they are connected at layer2, No firewall rules are required.

On the flip side you cannot use firewall rules to break up folks within a vlan as they are already connected at layer2................
There are always ways but in general..............

It sounds like this is a known issue in networking.
What is the subject that I should search in Google to learn/read more about it?
Just to make sure that my understanding is solid.

Who is online

Users browsing this forum: No registered users and 65 guests