Hello Pascal, > > > $IPTABLES -N Cid4A4A84F123430.0 > > > $IPTABLES -A INPUT -s myip -m state --state NEW -j > > Cid4A4A84F123430.0 > > > $IPTABLES -A INPUT -s 127.0.0.1 -m state --state NEW -j > > Cid4A4A84F123430.0 > > > $IPTABLES -A Cid4A4A84F123430.0 -d myip -j ACCEPT > > > $IPTABLES -A Cid4A4A84F123430.0 -d 127.0.0.1 -j ACCEPT > > > $IPTABLES -N Cid4A4A84F123430.1 > > > $IPTABLES -A OUTPUT -s myip -m state --state NEW -j > > Cid4A4A84F123430.1 > > > $IPTABLES -A OUTPUT -s 127.0.0.1 -m state --state NEW -j > > Cid4A4A84F123430.1 > > > $IPTABLES -A Cid4A4A84F123430.1 -d myip -j ACCEPT > > > $IPTABLES -A Cid4A4A84F123430.1 -d 127.0.0.1 -j ACCEPT > > > > I do not see here "a rule which allows everything in/out on the > > lo interface". Such rules would be : > > > > iptables -A INPUT -i lo -j ACCCEPT > > iptables -A OUTPUT -o lo -j ACCCEPT > > > > Instead, your rules accept only packets in the NEW state (RST packets > > are never in that state) whose source and destination addresses are > > "myip" or 127.0.0.1 (not only 127.0.0.1 but also the whole > 127.0.0.0/8 > > range may be used on the loopback interface). > > Ok, > > I see what you mean, is the RST not (one of) the last packet when a > connection > is closed/dropped ? I had a rule as #1 in the chain with: $IPTABLES -A INPUT -i lo -m state --state NEW -j ACCEPT $IPTABLES -A OUTPUT -o lo -m state --state NEW -j ACCEPT So I assume here also the --state NEW is causing the RTS not be matched, even it was related to some established connection... André
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
