In order to properly firewall different VLANS from each other what is the best practice way with the new VLAN filtering method (as here)? I have several VLAN interfaces on my bridge for DHCP, and using those interfaces as a firewall doesnt block broadcasts coming in the the VLAN. So I guess I can’t use an interface connected to a specific VLAN. I have been testing with these rules currently:
a.add action=drop chain=forward comment="Drop tries to reach not public addresses from LAN - #!public_from_LAN" dst-address-list=not_in_internet log=yes log-prefix=!public_from_LAN out-interface-list=WAN
b.add action=accept chain=forward out-interface-list=WAN src-address=192.168.110.0/24
1:add action=accept chain=forward in-interface="VLAN110" out-interface=\
"VLAN110"
2: add action=drop chain=forward comment="Interface test to grab everything" \
in-interface="VLAN110"
3: add action=drop chain=forward comment="drop multicast/broadcast outside subnet" \
dst-address-type=broadcast,multicast log-prefix=NO-CASTING src-address=\
192.168.110.0/24
4: add action=drop chain=forward comment="No Outside Access IP range" \
connection-nat-state=!dstnat connection-state=new dst-address=\
!192.168.110.0/24 log=yes log-prefix=LANescapey src-address=\
192.168.110.0/24
(IP firewall is set on in bridge)
I guess all thats left after a and b is multicast packets and packets with local routes, which I want to disallow
Rule 1 has blocked no packets in the last day.
rule 2 some.
rule 3 many.
rule 4 none.
So I assume for rule 1, this is done without reaching the firewall.
Not exactly sure what packets are coming in VLAN110 as in rule 2, have set a log and will investigate.
I believe I am correct in blocking broadcast/multicast in rule 3, in order to properly firewall these VLANS. Without this rule, I assume this VLAN could reach wherever it liked theoretically on the LAN, before being blocked from direct connections by rule 4..?
Will have to try out rule 4 from VLAN 110.
My question I guess is: am I on the right track here… this is the best solution I have been able to figure out myself
Firewall, unless you try hard, will only affect L3 (IP) traffic, traveling between L3 interfaces of router (e.g. VLAN110). It does not affect traffic that can be passed on L2 (e.g. between bridge port interfaces belonging to same VLAN as that forwarding is done by bridge directly).
To the rules:
remembering what I wrote above it’s only normal that this rule doesn’t catch anything … let alone block anything as action is accept
this rule will catch (with stated action it will block) traffic originating VLAN110 and going elsewhere (either other VLANs or WAN, but that depends on order of firewall rules)
hard to comment on this rule as you didn’t write anything about correlation between IP subnets and VLANs.
However, general rule is that router will not forward broadcasts to other subnets. Multicast is a whole different beast but usually routers have to be configured so that they do allow multicasts to pass …
this rule is actually overly complicated.
What could be a cleaner setup would be to set-up a pair of rules dropping any inter-VLAN communication. For exceptions you can add specific rules before those general drops. Example:
/ip firewall filter
# allow access from VLAN110 to internet
add chain=forward action=allow in-interface=VLAN110 out-interface-list=WAN
# allow access from certain client to NTP server in another subnet
add chain=forward action=allow src-address=192.168.110.42 dst-address=192.168.13.13 proto=udp dst-port=123
# block all communication from and to VLAN110
add chain=forward action=drop in-interface=VLAN110
add chain=forward action=drop out-interface=VLAN110
From firewall rule syntax point of view it would actually be more clean to only use IP addresses (subnets) … but that’s just subjective opinion.
yes, 192.168.110.0/24 corresponds to VLAN 110, where 192.168.110.10 sits on VLAN110, a slave to my LAN bridge. My actual hardware port which is the trunk for these VLANS has no VLANS as slaves, all done through bridge → VLAN (as in the initial linked forum post)
re number 1, yes I meant catch… (rule 32 in the img below)
Rule 4 (35 in the img) has a dstnat exception to allow for hairpin.. kinda complicated I know! perhaps the !dstnat is superfluous since hairpin is on a WAN IP, which is allowed earlier (rule 30)
.
Interesting I thought that rule 2 (33) isnt catching things caught by rule 3 (34) and 4 (35)…
Rule 3 (34) seems to be catching a bunch, which is what I was worried about that VLAN reaching out with multicasts/broadcasts. I used rule 3 before finally rule 4 so I could specifically log rule 4. I wanted to test filtering by interface which was the purpose for this ordering.. seems the new VLAN filtering doesn’t filter by VLAN interface as the old way, as I thought may be the case… Which means can only filter by IP, which means IP rules need to cover all possibilities to restrict VLANS to be isolated… The benefit being (I think) that switching can happen on the switch chip, if you wanted to bridge VLANs… which I actually dont after all this… Just want VLANs to be bridged with wifi through CAPsMAN.. through the CPU anyways…
sigh
also interesting that I have a new HP printer doing NetBIOS requests to an old nonexistant subnet, also this and other IP phones are making ntp requests from a NTP server I took out of the DHCP config many days ago… I actually had .110/24 being a /23 and had some issues with NetBIOS where a host (win 7) didn’t want to revert to /24, which may explain the NetBIOS requests..
