New vs Established packet state with firewall (beta)?

[thab]

Is there any way to indicate that filters should only be applied to NEW connections using the firewall system available via the control panel (not talking about iptables -- rather, the UI-based firewall config marked as Beta in the control panel)? I'm trying to filter on tcp & NEW, but it doesn't seem like there's an option. Not even sure I can craft a tcpdump string for that in the BPF option. Any thoughts?

Thanks!

[Edge100x]

The firewall on our end is stateless. Keeping track of connection state is something that is almost always best left to the destination devices, for performance reasons; it is rarely a good idea to do it on network devices in between the sender and receiver.

If you need to track state, I recommend installing a Linux OS, such as Ubuntu. iptables is very fast and powerful. The Windows firewall tool, in contrast, has serious performance problems and is quite limited in its options (for instance, it doesn't allow rule ordering, and traffic in established flows is always accepted, with no exceptions; Windows also doesn't offer pattern matching or other features offered by netfilter modules).

What type of traffic are you looking to block? I may be able to help you construct a rule that would get the desired effect.

[thab]

Thanks Edge. Yeah, I get it. SPI upstream would be a bit of a performance pig. I have no problem crafting the needed rules in iptables -- was just wondering if I was missing something in the upstream firewall.

Thanks!

[thab]

Just to bring closure (and make sure I'm sane), here's the intent.

I'm running multiple srcds instances and would like to protect rcon via a fw rule. The external firewall (ie, the beta system, the one available via the web control panel) doesn't allow multiple individual ports on a single rule, so I'm left creating multiple rules (18 of them) to protect each rcon. That seems wasteful. Protecting a range of TCP addresses (ie, 27000 -30000, to cover my rcons) creates other issues (wrecks Cinema's ability to run movies, etc), likely related to statelessness of the fw rule. Not really sure.

Anyway, long story short, I added the following as a local iptables ruleset, and left the other rules on the external firewall (protecting ssh, blocking icmp, etc). Do you see any value in moving those over to the local iptables install as well? Or is it fine to leave them at the external firewall and potentially use those rules to similarly protect other servers I might add in the future.

Thanks again!


-A INPUT -s my.home.wan.ip-j ACCEPT
-A INPUT -i lo -j ACCEPT
# Protect RCON
-A INPUT -p tcp -m tcp -m state --dport 27000:30000 --state NEW -j DROP

[Edge100x]

It should work just fine to use rules in both places.

If you can avoid using state, though, I recommend that. If you're not running other listening services on this port range, that would be fairly easy -- allow everything from your address, but block inbound "syn" traffic for everything else.

[thab]

Ahhh. That is much more elegant, and allows me to put everything back on the upstream firewall (I'd much rather have it all in one place and avoid forgetting where I've done what, etc). Thank you!