After your mail now I am prudent to test this more thou I have somewhat verified in a test FW that you do not need RELATED rule for the IPTABLES to be allowed to generate a TCP RST packet internally . >From what you sent me directly , you also allowed this in the OUTPUT chain which makes no sense to me ... ... but it maybe that the rules set has somehow been "broken" and it is now causing un-intended packet handling . I will try to change my OUTPUT rules to LOG any output that is regarded as RELATED with full options , That will not change anything in the FW rules itself just add a LOG entry at the start of the OUTPUT chain to see if TCP RST generated inside the IPTABLES FORWARD chain has to pass the OUTPUT chain at any time ... Best regards André Paulsberg-Csibi Senior Network Engineer Fault Handling IBM Services AS -----Original Message----- From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Matt Killock Sent: 10. januar 2017 20:30 To: Neal P. Murphy <neal.p.murphy@xxxxxxxxxxxx> Cc: netfilter@xxxxxxxxxxxxxxx; netfilter-owner@xxxxxxxxxxxxxxx Subject: Re: Iptables Reject with TCP Reset > 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. Sounds nice in theory, but reality bites back. RELATED also applies to the TCP Reset packets to SYN packets. I just tried this at home to confirm my findings. Please review the below firewall script. It does not send the TCP RST packets unless you make one minor change: To add 'RELATED,' to the line underneath '#General State Matching' Please note that it has the single state matching lines as recommended by various others on this list. > It almost sounds like you built a nearly stateless firewall. It's more or less like the below but duplicates ESTABLISHED everywhere ------------------------------ A='/sbin/iptables' EXIF='ppp0' LANIF='eth1' #Clear $A -F $A -F INPUT $A -F OUTPUT $A -F FORWARD $A -F -t mangle $A -F -t nat $A -X #Setup policies $A -P INPUT DROP $A -P OUTPUT DROP $A -P FORWARD DROP echo "1" > /proc/sys/net/ipv4/ip_forward # Some basics # Accept loopback interface $A -A INPUT -i lo -j ACCEPT A='/sbin/iptables' EXIF='ppp0' LANIF='eth1' #Clear $A -F $A -F INPUT $A -F OUTPUT $A -F FORWARD $A -F -t mangle $A -F -t nat $A -X #Setup policies $A -P INPUT DROP $A -P OUTPUT DROP $A -P FORWARD DROP echo "1" > /proc/sys/net/ipv4/ip_forward # Some basics # Accept loopback interface $A -A INPUT -i lo -j ACCEPT $A -A OUTPUT -o lo -j ACCEPT # SSH from LAN $A -A INPUT -i $LANIF -p tcp --dport 22 -j ACCEPT #general NAT $A -t nat -A POSTROUTING -o $EXIF -j MASQUERADE #General State Matching $A -A OUTPUT -m state --state ESTABLISHED -j ACCEPT $A -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT #Allowed HTTP/HTTPS Sites #bbc $A -A FORWARD -i $LANIF -o $EXIF -d 212.58.244.22 -p tcp -m multiport --dports '80,443' -j ACCEPT #Send RST to LAN for all other 80/443 connections $A -A FORWARD -i $LANIF -p tcp -m multiport --dports '80,443' -j REJECT --reject-with tcp-reset -------------------- Matt -- 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 ��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
