I have a security cam at ip 192.168.1.22 at port 7480. I need to get access to this cam by the time, everyday from 3 to 5 pm. I get NAT rule netmap from my white IP to ip 192.168.1.22 port 7480 by the time. When NAT rule is switching off, port 7480 is closed for all new connections. But all esablished connections are still working. I tried to make firewall rules at the top:
chain=forward action=reject dst-address=My white IP
chain=forward action=reject src-address=My white IP
Tried to block port 7480. No effect.
Is there any way to block all already established connections thrue the port?
The order of firewall rules matters. Each packet is matched to the rules in the chain starting from the topmost one until the first match is foundf (exceptions exist but not in /ip firewall filter, and even where a match doesn’t mean that the packet continues further through the chain the order still matters). So to make the action=reject rule work on packets belonging to already established connections, you have to place if before (above) the action=accept connection-state=…,established,… one.
There’s the tricky part: fast-track. To effectively control packets of certain connection(s), those connections should be excluded from fast-track rule … So perhaps easier (but also more resoulrce-demanding) way would be to add drop rules in raw firewall table … which gets executed before fast-track if I’m not much mistaken.
I’ve thought about this too, and the best approach depends on the type of traffic you want to handle:
if you just drop the packets in raw, they won’t get through, but this doesn’t remove the connection unless you drop them in both directions and the connection thus times out, which takes 3 minutes by default for UDP but a whole day by default for TCP.
if you place the reject rule to filter and send an ICMP message upstream, many UDP sources will ignore it, but if you send a TCP-reset, TCP sessions will get terminated. And every N-th (do you know the actual N? It is not stated anywhere) packet in each direction of a fasttracked connection takes the full path through the firewall, so sending the TCP-reset to that one is sufficient. And this can only be done in filter because raw doesn’t support action=reject.