Address range for adm interface ist 172.19.1.0/24 (with router 172.19.1.1).
Address range for lan interface ist 172.19.10.0/24 (with router 172.19.10.1).
But an access from a lan client is not rejected. Why? Logread says:
Mon Jun 26 19:23:16 2023 authpriv.info dropbear[31916]: Child connection from 172.19.10.22:43276
Mon Jun 26 19:23:16 2023 authpriv.notice dropbear[31916]: Pubkey auth succeeded for 'root' with ssh-rsa key SHA256:TOP-SECRET from 172.19.10.22:43276
Because the traffic crosses the router to the adm zone and the firewall doesn't inhibit the attempt.
You will find that this will fail: ssh from 172.19.10.22 to 172.19.10.1.
But this will work: 172.19.10.22 to 179.19.1.1
This is because:
172.19.1.1 is in a different subnet, so ssh hits the default gateway: the router.
The router looks at the packet and says, "Where do I send this? Oh! It's to me! I don't need to send it anywhere else!"
The target IP address is the IP address of the interface in the adm zone.
If you put a corresponding rule in place to inhibit SSH from the LAN (or from anywhere you don't want it), then the unwanted attempts will fail.
config rule
option name 'Stop SSH'
list proto 'tcp'
option src 'lan'
option dest_port '22'
option target 'REJECT'
The absence of a dest directive means that the destination is "this device", i.e. the router. You can see an illustration of this in the display of the firewall traffic rules in LuCI.
Bother. You are right, and I was wrong. At least, my explanation was wrong. Apologies for that. It's late, and I'm tired, and I got the netstat output backwards. I will correct my earlier explanation lest anyone else stumble across it and be misled.
However, the fix is as I described: stick a rule in to stop SSH traffic crossing the router and landing at the interface in the permitted zone.
The reason that the lan client is not rejected is because input = accept on the lan zone.
When the ssh connection to 172.19.1.1 arrives at the router from the 172.19.10.0/24 network, the router determines that it holds the address in question. Because input is allowed on the lan firewall zone, the connection can be established, even though it would seem that it is a different subnet.
The above only affects the address of the listening interface, not the permissions on the firewall. It is the firewall that allows or denys the connection. If you do not specify the interface, dropbear will listen on all addresses associated with the router (including the wan... but don't freak out), but the firewall (input = reject/drop, or specific granular traffic rules on a given zone/network/host IP) is what prevents access from the wan or any unauthorized zones/networks/hosts.
