On Tue, 10 Jan 2017 10:09:55 +0000 Matt Killock <matt.killock@xxxxxxxxxxxx> wrote: > > The rule you made here makes little sense , It would be preferable to make a more simple rule at "the top" like this ... > > > > This will allow "all" traffic for rules you have already allowed through other rules in the FW ( no matter the IP or interface ) . > > I note that it would be simpler to have one such rule for RELATED,ESTABLISHED but that's not the way we've done things here, much to Noel's disgust. :) > > We've blocked everything, including OUTPUT, by default. There are no general SNAT rules or MASQUERADE. We've tried to allow only the bare minimum required for two-way traffic between a small set of host/port combinations. This has led to some unnecessary duplication of ESTABLISHED rules, and I didn't appreciate that RELATED traffic is what the 'REJECT with TCP-Reset' traffic is classed as but otherwise it makes (some) sense and does work. This doesn't make much sense. A RELATED packet is the first packet of a new conn that a helper has determined is related to an existing conn (e.g., the data conn of an FTP control session). Once a RELATED packet is replied to, the resulting conn is an ordinary, vanilla ESTABLISHED conn; specifically, the RELATED 'tag' is discarded. When a packet matches a "REJECT with TCP-Reset" rule, netfilter immediately sends a TCP RESET to the end that sent the packet. It may be that TCP RESET applies to the first TCP SYN packet of a conn. But RESETting only established TCP conns and using ICMP 'admin prohibited' for all other packets works well and is logical. It almost sounds like you built a nearly stateless firewall. A rule near the top that allows packets for ESTABLISHED,RELATED conns to pass is more efficient, and is probably significantly more-so on a busy router because *most* packets will be associated with established conns and should be handled without needlessly passing them through all the 'new conn' checks. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
