I am currently trying to to setup my home network with help of a NanoPi R4S (only one physical port on the lan side) as "heart" of the network and some surrounding Unifi devices (APs + Switch). The setup is based on different (tagged) vlans, for myself but asw well because different neighbours are involved + untagged traffic to keep the Unifi world as default as possible (from what I understand default is to handle the manamgement traffic untagged).
So far so good. But, I am already failing a the basics. I've setup different interfaces and corresponding firewall zones. See below (minimal and abstracted) example. All "worked" so far (e.g. dhcp handed out correctly via correct vlan) until I started trying to break things.
Specific: I am able to send untagged traffic to the route targeting both IPs (10.2.0.1 and 10.2.10.1) getting a 200 response / the OpenWrt Web interface is opening. Sure, I can reject input via firewall. BUT: my expectation is that traffic is not even forwarded between the zones from "mgm" to "clients1" if I address via 10.2.10.1 (there are no forwardings or rules configured).
What am I doing wrong, or is my expectation wrong?
Thanks and best regards
Robert
config device
option name 'eth1'
option macaddr '123456778'
config interface 'mgm'
option device 'eth1'
option proto 'static'
option ipaddr '10.2.0.1'
option netmask '255.255.255.0'
config interface 'clients1'
option device 'eth1.10'
option proto 'static'
option ipaddr '10.2.10.1'
option netmask '255.255.255.0'
config zone
option name 'mgm'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'mgm'
config zone
option name 'clients1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'clients1'
This is because of the input = ACCEPT rule on both of those networks
This is where it can be a bit confusing...
It is not forwarding here... the router itself holds these two addresses, so it is subject to the input rule. The input rule affects traffic coming from a given network/zone into the router itself.
When you are on the clients1 network (10.2.10.0/24) and you try to connect to the management network (10.2.0.0/24) as a whole (excluding 10.2.0.1), it will not be possible since there are no forwarding rules, as you have stated. However, when you make a connection to 10.2.0.1 (the router), the router itself is the target and it knows that -- you can think of it as a nickname... if 10.2.0.1's name is "James", and 10.2.10.1 is "Jim", it stands to reason that they will both respond to requests for Jim or James.
If you change the input rule on the clients1 zone to REJECT or DROP, it will prevent the connections you are asking about.
thanks for your reply! This explains the behavior. At least I think this. At the same time this is kind of pretty unexpected and prevents me from implementing what I thought was a good idea so far.
My plan is to have different containerized services running at the machine. Every service talks to the outside world via a separate interface (bridge) and has its own firewall zone. Afterwards I wanted to assign specific forwarding rules from other zones for each service. But: not every service should be accessible from every zone. So, e.g. the router web interface should be only accessible from the management network, while e.g. DNS should work from every zone. So there are different combinations. With the above in mind, this is unsecure in terms of it is possible to access every service on the router from every zone as long as I know the right IP address.
Only way I can think of solving this a single firewall (traffic) rules while deny the gener input in the zone. Do you think this will work?
This is where it can be a bit confusing...
It is not forwarding here... the router itself holds these two addresses, so it is subject to the input rule. The input rule affects traffic coming from a given network/zone into the router itself.
What is the definition of "the router itself"? Is every layer 3 interface / IP address assumed to be part of it?
Yes. A l3 interface on the router will have an address. The router can thus have many addresses that refer to the “router itself “
As for securing the router - as @NPeca75 said, for a untrusted/restricted zone- set the zone input rule to reject and then create firewall rules to allow the services. This is done commonly for guest and IoT networks (dhcp, dns allowed; all else blocked).