TCP-RESET would typically be "ESTABLISHED" as that would be a normal part of a TCP session , In IPTABLES it might be that an EARLY TCP-RESET could be "RELATED" but I do not think so . "RELATED" is typically ICMP responses from systems in the path that are response to a TCP session that for some reason no longer is "reachable" , as this is not part of the TCP session directly it would not be in the conntrack table and IPTABLES would need to look at the DATA in the ICMP to see if that is RELATED to any active session . "RELATED" could also be sessions inspected with FTP or other protocols , where a NEW TCP session is created which can be inspected in the uncrypted FTP session on the primary FTP port of 21 and then RELATED as it is created if proper modules are used . Using "RELATED" is mostly safer and preferable instead of opening manually for ICMP TYPE 3 , TYPE 4 and TYPE 11 ( and all other types that may be needed to have correct and stable TCP/IP connectivity ) Best regards André Paulsberg-Csibi Senior Network Engineer Fault Handling IBM Services AS -----Original Message----- From: Matt Killock [mailto:matt.killock@xxxxxxxxxxxx] Sent: 10. januar 2017 11:10 To: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx>; Noel Kuntze <noel@xxxxxxxxxxxxxxxxx>; netfilter@xxxxxxxxxxxxxxx Subject: RE: Iptables Reject with TCP Reset > 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. Kind regards Matt ________________________________ Plum Software is a fully owned subsidiary of Praemium Limited. This e-mail is confidential. It may also be legally privileged. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return email. Internet communications cannot be guaranteed to be timely, secure, or error or virus free. The sender does not accept liability for any errors or omissions. In the UK the Praemium Group is: Praemium Portfolio Services Ltd (Company Number: 05362168), Praemium (UK) Ltd (Company Number: 05362153), Praemium Administration Ltd (Company Number: 06016828) and Smartfund Nominees Ltd (Company Number: 07153417) each having its registered office at 4th Floor, Suite 643-659, Salisbury House, London Wall, London, EC2M 5QQ, United Kingdom. Praemium Administration Ltd is authorised and regulated by the Financial Conduct Authority under reference 463566. See http://www.fca.org.uk/register for more details. In Jersey the Praemium Group is: Praemium International Ltd (Company Number: 107624) which has its registered office at 3rd Floor East, Salisbury House, 1-9 Union Street, St Helier, JE2 3RF and is regulated under the Financial Service (Jersey) Law 1998 by the Jersey Financial Services Commission for the conduct of investment business in Jersey. See http://www.jerseyfsc.org for more details. Thank you for your cooperation. Please contact us on +44 (0)207 5622 450 if you require assistance. ��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
