I understand what that rule is doing and I tried it, and put my laptop on the 20.0 subnet and was still able to hit the page. Funny thing is, I could see the filter processing packets, yet the page still displayed. When I hopped on my 1.0/30 subnet I experienced the same behavior.
Those rules block traffic forwarding from the specified networks to 192.168.100.0/30. That has nothing to do with the administrative ports on the router itself. To block those, you want to drop traffic in the input chain to the service ports from anywhere that is not 192.168.100.0/30. Assuming the default ports (21,22,23,80,443,8291,8728) that would look like this:
OK, I removed the other rules and tried adding the new filter rule you provided.
Same thing. It is processing packets but I can still access that page.
Both ether2 (1.0/30) and wlan (20.0/27) are part of a hotspot profile. ether1 (0.0/30) is a HughesNet sat modem, the default gateway and is masqueraded.
The new rule is #11 in the order, below the automatically added hotspot rules.
How do you masquerade? Depending on how that rule is set up it could change the source IP address seen. Can you post all your firewall rules (filter, mangle and nat)?
Anything going out ether1 is going to have an IP of 192.168.0.2 attached to it - then will goto the HughesNet sat modem and then out to the internet with the dynamic IP assigned by Hughes. If a client requests 192.168.100.1 (the address of my management lan on ether3) I do not believe the masquerading will take place.
Thanks for your help so far! Appreciated very much.
My firewall ruleset is fairly simple - allow a few services (DNS, DHCP, NTP) from the LAN, allow rate limited ICMP, allow all router access from an address-list populated with IP addresses that get access. Block NetBIOS and a few other ports from being forwarded, and don’t forward traffic between customer networks:
[admin@MikroTik] > /ip fire fil pri det
Flags: X - disabled, I - invalid, D - dynamic
0 X ;;; place hotspot rules here
chain=unused-hs-chain action=passthrough
1 ;;; allow established
chain=input action=accept connection-state=established
2 ;;; allow related
chain=input action=accept connection-state=related
3 ;;; allow local service UDP ports from LAN
chain=input action=accept protocol=udp in-interface=!outside dst-port=53,67,123
4 ;;; allow local service TCP ports from LAN
chain=input action=accept protocol=tcp in-interface=!outside dst-port=53
5 ;;; allow rate-limited ICMP
chain=input action=accept protocol=icmp limit=20,20
6 ;;; allow everything from admin networks
chain=input action=accept src-address-list=Administrative_Networks
7 ;;; drop everything else
chain=input action=drop
8 ;;; forward established traffic
chain=forward action=accept connection-state=established
9 ;;; forward related traffic
chain=forward action=accept connection-state=related
10 ;;; drop undesired TCP
chain=forward action=drop protocol=tcp dst-port=135-139,445,1434,4444
11 ;;; drop undesired UDP
chain=forward action=drop protocol=udp dst-port=135-139,445,1434,4444
12 ;;; forward traffic from customer interfaces to WAN (all other networks cannot talk to one another)
chain=forward action=accept out-interface=outside
13 ;;; drop everything else
chain=forward action=drop
That system also runs Hotspots. Using those rules, trying to access the router webpage from a client on the Hotspot network that isn’t authenticated redirects me to the Hotspot login page. Once authenticated, I cannot access the router webpage. Once I add the client network to the Administrative_Networks address list, I can load the router webpage. Once I remove the network from the address list again, I cannot access the router anymore.
Did some more messing around and found that if you create the rule as you initially stated and put it before the hotspot rules then it works as we expected and the subsequent hs-input rule is no longer even processing packets.
Actually, the subsequent rule isn’t even processing packets after the client authenticates with the hotspot.
More idle curiosity: can you post the output of “/ip hotspot export” (just mask the passwords, I guess)? Maybe address pools or transparent proxy settings change packet flow in a way that makes hs-input irrelevant on my system.
My next step is to enable Web Proxy for filtering by DNS names, and I know from the past on another RB433 in a different environment that firewall rules are affected by that too.