I have separate anchors for each type of traffic and the particular traffic I am trying to 'control' is roblox:
AFAIK (or thought), once I remove a device from the table, it should stop passing traffic. I also have another anchor at the very start of my firewall which is a bit more aggressive which serves to block entire devices by IP address. Despite both measures, traffic was still being passed.
In hindsight, I did NOT think of flushing the anchor and the corresponding state tables. That would have probably also worked, but in this case I want to understand why merely removing the device failed to work. Because AFAIK or have observed, when I do the same for TCP traffic (general web), traffic stops immediately. I also prefer to use the smallest tool for the job where possible as it would have the least impact to the rest of the system or network.
But, UDP state tracking and TCP state tracking are different and perhaps because of that, the UDP state was still being matched because I think my timeout for UDP traffic is whatever the default is, probably 10 minutes. TCP is synchronous, so that is probably why I observed traffic being cut immediately.
If that is the case, when I want to terminate traffic immediately for specific devices using UDP anchors, I should also flush the state table. While it would temporarily slow down throughput on the router, that would be minimal and this is a non-critical home environment.
Code:
ROBLOX_CIDR="128.116.0.0/17"
ROBLOX_PORTS="49152:65535"
# https://en.help.roblox.com/hc/en-us/articles/203312880-General-Connection-Problems
pass out quick on wan proto {udp} to {$ROBLOX_CIDR} port {$ROBLOX_PORTS}
pass in quick on wired proto {udp} from <roblox_client> to {$ROBLOX_CIDR} port {$ROBLOX_PORTS}AFAIK (or thought), once I remove a device from the table, it should stop passing traffic. I also have another anchor at the very start of my firewall which is a bit more aggressive which serves to block entire devices by IP address. Despite both measures, traffic was still being passed.
In hindsight, I did NOT think of flushing the anchor and the corresponding state tables. That would have probably also worked, but in this case I want to understand why merely removing the device failed to work. Because AFAIK or have observed, when I do the same for TCP traffic (general web), traffic stops immediately. I also prefer to use the smallest tool for the job where possible as it would have the least impact to the rest of the system or network.
But, UDP state tracking and TCP state tracking are different and perhaps because of that, the UDP state was still being matched because I think my timeout for UDP traffic is whatever the default is, probably 10 minutes. TCP is synchronous, so that is probably why I observed traffic being cut immediately.
If that is the case, when I want to terminate traffic immediately for specific devices using UDP anchors, I should also flush the state table. While it would temporarily slow down throughput on the router, that would be minimal and this is a non-critical home environment.