I am using a RUTC50 with the latest Mass Production FW (7.13.4) and I have noticed a problem with the firewall settings.
Under Network > Firewall > Traffic Rules I have created a rule to block traffic from Lan to Wan for all IPs. My test computer in the LAN has the IP 192.168.1.100 and I use it to send a ping to a computer in the WAN. The ping is blocked, the rule works.
If I now edit the active rule and change the source IP from Any to e.g. 192.168.1.150 (Save&Apply), I receive the message: Configuration has been applied and indeed, the pings from 192.168.1.100 are no longer blocked. As expected, the change works.
If I now edit the rule again and enter 192.168.1.100 as the source IP, the pings from 192.168.1.100 continue to work, although the rule is supposed to prohibit it. To make the rule effective, I have to deactivate and reactivate it. This is an error when applying the edited rule.
To confirm your existing traffic rules, do you have an existing rule that also includes the same IP address, 192.168.1.100? Also, what priority do you have it set to? In other words, what place in the list does the rule youāve created have? You can drag the created traffic rules, with the top being the highest priority (or metric), and the bottom being the lowest.
conntrack application used for firewall tracks ICMP packages using their ID (if I remember correctly). You can check Status ā Realtime ā Connections page inside routers WebUI
Iāve tested this and this indeed seems to be the behaviour, even on the latest FW. Iāll create a request for the R&D to check this, and Iāll come back to you once I have more information.
thanks a lot for open the ticket on this issue. Iām a little bit confused. You said, that you can reproduce the issue, but R&D not? Maybe they misunderstood something?
For me it makes no difference how I do the ping. Permanent ping while Iām editing the rule or no ping, then editing the rule and then ping again. Itās the same result.
Thanks for the information. Iāll need to reach out to you personally. Iāve sent you a form to fill out so we can continue our conversation in private, to avoid accidentally leaking any sensitive information. In the Ticket ID field, simply enter the threadās number, which is 14019.
I looked at the real-time connections today and indeed a connection is established after a ping and then kept for ~20s. If you change the firewall rule to ā deny connectionā and send a new ping within this time, it will succeed and the 20s will start again. So I was simply too quick with the test. If you wait until the 20s have expired and then send a ping, it is blocked immediately.
The situation is different with continuous pings. No matter how long I ping, they work permanently, even if the rule prohibits them. Interestingly, you can see in the real-time connection data that the connection is lost very briefly every 20 seconds, but is immediately re-established.
Conclusion, even if the behavior in the test with continuous ping is a bit strange to me, it is not a problem in practice. If R&D finds this a problem, then please work on it, but from my point of view, itās done.