Hi
I believe this is caused by how the client handles ( read respect ) ICMP PORT UNREACHABLE packets .
If you see under you can see that you have 2 hits on the rule for using the ICMP contra RST , because some client software will RETRY with 1 second delay .
So it is not caused by the OS or IPTABLES which I am pretty sure sends the packet as soon as it prioritizes both times .
( even if this test cannot show the actual packets being sent , I cannot imagine it did not receive it - maybe your strace says different )
iptables -I OUTPUT 1 -d 10.99.12.15 -p tcp --dport 27016 -j REJECT --reject-with icmp-port-unreachable
iptables -I OUTPUT 2 -d 10.99.12.15 -p tcp --dport 27017 -j REJECT --reject-with tcp-reset
zotac:~/FireWall # date ; telnet 10.99.12.15 27016
Thu Jan 25 18:26:20 CET 2018
Trying 10.99.12.15...
telnet: connect to address 10.99.12.15: Connection refused
zotac:~/FireWall # date ; telnet 10.99.12.15 27017
Thu Jan 25 18:26:22 CET 2018
Trying 10.99.12.15...
telnet: connect to address 10.99.12.15: Connection refused
zotac:~ # tcpdump -nni lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
18:26:20.080349 IP 127.0.0.1 > 127.0.0.1: ICMP 10.99.12.15 tcp port 27016 unreachable, length 68
18:26:21.081463 IP 127.0.0.1 > 127.0.0.1: ICMP 10.99.12.15 tcp port 27016 unreachable, length 68
18:26:22.485777 IP 10.99.12.15.27017 > 127.0.0.1.53030: Flags [R.], seq 0, ack 2365051905, win 0, length 0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2 360 REJECT tcp -- * * 0.0.0.0/0 10.99.12.15 tcp dpt:27016 reject-with icmp-port-unreachable
1 180 REJECT tcp -- * * 0.0.0.0/0 10.99.12.15 tcp dpt:27017 reject-with tcp-reset
SIDENOTE : Typically when using TCP , it makes more sense to use "-j REJECT --reject-with tcp-reset" but doing otherwise is also OK ,
I am not saying this is the solution to your issue but it will work as a almost 100% workaround for all TCP sessions .
Best regards
André Paulsberg-Csibi
Senior Network Engineer
IBM Services AS
-----Opprinnelig melding-----
Fra: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] På vegne av Renaud Drousies
Sendt: torsdag 25. januar 2018 12.32
Til: netfilter@xxxxxxxxxxxxxxx
Emne: Slow 'connection refused' on REJECT rules
Hello,
I would like to force a 'connection refused' when connecting to a specific host/port and to do so I'm using the following rule:
iptables -A OUTPUT -d 10.99.12.15 -p tcp --dport 27017 -j REJECT --reject-with icmp-port-unreachable
This works fine except that it takes around 1 second for the reply to come (I've straced it and it's really the call to connect() that hangs). I've tried the following rules on multiple kernels from the 2.x, 3.x and 4.x branches and the behavior is always the same.
There wasn't any other rule in any chain when these tests were done.
Would anybody know what could cause this delay and how to address that?
Thanks!
Renaud
--
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�����٥
