All of lore.kernel.org
 help / color / mirror / Atom feed
* strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel
@ 2004-12-17 11:07 Roberto Nibali
  2004-12-17 11:32 ` Jozsef Kadlecsik
  0 siblings, 1 reply; 3+ messages in thread
From: Roberto Nibali @ 2004-12-17 11:07 UTC (permalink / raw)
  To: Netfilter Developers; +Cc: chris

Hello,

I just wanted to know if this is a known feature of the conntrack code. When I 
issue a local redirect ssh command, I get an ACCEPT followed by an INVALID on 
the SYN packet but the connection still works (kernel 2.4.27).

# /foobar/bin/sshc www@172.23.139.11 -o BatchMode=yes -2 -q -f -N -p 2345 -R 
1513:127.0.0.1:1514

# tail -f /var/log/kernlog
Dec 17 11:18:41 s_int@foobar tfx3: fw-tcp2fw [110] a:ACCEPT s:NEW
f:INPUT IN=eth0 OUT= SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059
DPT=2345 SYN
Dec 17 11:18:41 s_int@foobar ip_conntrack_tcp: INVALID: invalid SYN
(ignored) SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059 DPT=2345
SYN OPT (020405B40402080A0085041F0000000001030300)

The connection is established and the traffic works through the tunnel, but I'm 
curious as to what could actually create those two lines. I've straced the call 
but haven't found anything odd in particular.

ip_ct_tcp_log_invalid is set. Reading ip_conntrack_proto_tcp.c I learn that this 
can be because we're in TCP_CONNTRACK_IGNORE state (sIG). According to the comment:

         /* This SYN/ACK acknowledges a SYN that we earlier ignored
          * as invalid. This means that the client and the server
          * are both in sync, while the firewall is not. We kill
          * this session and block the SYN/ACK so that the client
          * cannot but retransmit its SYN and thus initiate a
          * clean new session.
          */

 From a TCP state transition point of view I reopen a new connection and thus 
I've checked the /* ORIGINAL */ table which mentions following possible sIG 
transitions under /*syn*/:

  *      sSR -> sIG      Late retransmitted SYN?
  *      sES -> sIG      Error: SYNs in window outside the SYN_SENT state
  *                      are errors. Receiver will reply with RST
  *                      and close the connection.
  *                      Or we are not in sync and hold a dead connection.
  *      sFW -> sIG
  *      sCW -> sIG
  *      sLA -> sIG

The strange thing is that I even when I believe to be in sNO state on the packet 
filter the connections is made to I get this message. I know I can safely ignore 
it but I'm wondering why it is like that.

Best regards,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Rathausgasse 31, CH-5001 Aarau  tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel
  2004-12-17 11:07 strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel Roberto Nibali
@ 2004-12-17 11:32 ` Jozsef Kadlecsik
  2004-12-17 12:01   ` Roberto Nibali
  0 siblings, 1 reply; 3+ messages in thread
From: Jozsef Kadlecsik @ 2004-12-17 11:32 UTC (permalink / raw)
  To: Roberto Nibali; +Cc: Netfilter Developers, chris

Hi,

On Fri, 17 Dec 2004, Roberto Nibali wrote:

> I just wanted to know if this is a known feature of the conntrack code. When I
> issue a local redirect ssh command, I get an ACCEPT followed by an INVALID on
> the SYN packet but the connection still works (kernel 2.4.27).
>
> # /foobar/bin/sshc www@172.23.139.11 -o BatchMode=yes -2 -q -f -N -p 2345 -R
> 1513:127.0.0.1:1514
>
> # tail -f /var/log/kernlog
> Dec 17 11:18:41 s_int@foobar tfx3: fw-tcp2fw [110] a:ACCEPT s:NEW
> f:INPUT IN=eth0 OUT= SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059
> DPT=2345 SYN
> Dec 17 11:18:41 s_int@foobar ip_conntrack_tcp: INVALID: invalid SYN
> (ignored) SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059 DPT=2345
> SYN OPT (020405B40402080A0085041F0000000001030300)

Please dump the traffic and send the corresponding log lines. (It seems to
be a retransmitted SYN, which is harmless.)

> The connection is established and the traffic works through the tunnel, but I'm
> curious as to what could actually create those two lines. I've straced the call
> but haven't found anything odd in particular.
>
> ip_ct_tcp_log_invalid is set. Reading ip_conntrack_proto_tcp.c I learn that this
> can be because we're in TCP_CONNTRACK_IGNORE state (sIG). According to the comment:
>
>          /* This SYN/ACK acknowledges a SYN that we earlier ignored
>           * as invalid. This means that the client and the server
>           * are both in sync, while the firewall is not. We kill
>           * this session and block the SYN/ACK so that the client
>           * cannot but retransmit its SYN and thus initiate a
>           * clean new session.
>           */

That path covers multiple cases and the comment refers to ignored SYN/ACK
packets :-) .

> The strange thing is that I even when I believe to be in sNO state on the packet
> filter the connections is made to I get this message. I know I can safely ignore
> it but I'm wondering why it is like that.

You can't be in sNO state: if the assumption is valid (i.e. that's a
resent SYN) then the connection is in sSR or above.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel
  2004-12-17 11:32 ` Jozsef Kadlecsik
@ 2004-12-17 12:01   ` Roberto Nibali
  0 siblings, 0 replies; 3+ messages in thread
From: Roberto Nibali @ 2004-12-17 12:01 UTC (permalink / raw)
  To: Netfilter Developers; +Cc: chris

Hello,

>>I just wanted to know if this is a known feature of the conntrack code. When I
>>issue a local redirect ssh command, I get an ACCEPT followed by an INVALID on
>>the SYN packet but the connection still works (kernel 2.4.27).
>>
>># /foobar/bin/sshc www@172.23.139.11 -o BatchMode=yes -2 -q -f -N -p 2345 -R
>>1513:127.0.0.1:1514
>>
>># tail -f /var/log/kernlog
>>Dec 17 11:18:41 s_int@foobar tfx3: fw-tcp2fw [110] a:ACCEPT s:NEW
>>f:INPUT IN=eth0 OUT= SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059
>>DPT=2345 SYN
>>Dec 17 11:18:41 s_int@foobar ip_conntrack_tcp: INVALID: invalid SYN
>>(ignored) SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1059 DPT=2345
>>SYN OPT (020405B40402080A0085041F0000000001030300)
> Please dump the traffic and send the corresponding log lines. (It seems to
> be a retransmitted SYN, which is harmless.)

foobar:~# grep DPT=2345 /var/log/kernlog | tail -2
Dec 17 12:40:49 s_int@foobar tfx3: fw-tcp2fw [110] a:ACCEPT s:NEW
f:INPUT IN=eth0 OUT= SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1040
DPT=2345 SYN
Dec 17 12:40:49 s_int@foobar ip_conntrack_tcp: INVALID: invalid SYN
(ignored) SRC=172.23.139.20 DST=172.23.139.11 DF PROTO=TCP SPT=1040 DPT=2345
SYN OPT (020405B40402080A00007E750000000001030300)

foobar:~# tcpdump -nvi eth0 port 2345 and tcp #edited for ledgibility
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes

12:40:49.907439 IP (tos 0x0, ttl  64, id 59607, offset 0, flags [DF], length:
60) 172.23.139.20.1040 > 172.23.139.11.2345: S 1063163554:1063163554(0) win
5840 <mss 1460,sackOK,timestamp 32373[|tcp]>

#SYN 172.23.139.20.1040 > 172.23.139.11.2345

12:40:49.907583 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 60)
172.23.139.11.2345 > 172.23.139.20.1040: S 1491192392:1491192392(0) ack
1063163555 win 5792 <mss 1460,sackOK,timestamp 9210436[|tcp]>

#SYN/ACK 172.23.139.11.2345 > 172.23.139.20.1040

12:40:49.907443 IP (tos 0x0, ttl  64, id 59607, offset 0, flags [DF], length:
60) 172.23.139.20.1040 > 172.23.139.11.2345: S 1063163554:1063163554(0) win
5840 <mss 1460,sackOK,timestamp 32373[|tcp]>

#SYN 172.23.139.20.1040 > 172.23.139.11.2345

12:40:49.907748 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], length: 60)
172.23.139.11.2345 > 172.23.139.20.1040: S 1491192392:1491192392(0) ack
1063163555 win 5792 <mss 1460,sackOK,timestamp 9210436[|tcp]>

#SYN/ACK 172.23.139.11.2345 > 172.23.139.20.1040

12:40:49.908559 IP (tos 0x0, ttl  64, id 59608, offset 0, flags [DF], length:
52) 172.23.139.20.1040 > 172.23.139.11.2345: . [tcp sum ok] ack 1 win 5840
<nop,nop,timestamp 32373 9210436>

#ACK 172.23.139.20.1040 > 172.23.139.11.2345

12:40:49.908562 IP (tos 0x0, ttl  64, id 59608, offset 0, flags [DF], length:
52) 172.23.139.20.1040 > 172.23.139.11.2345: . [tcp sum ok] ack 1 win 5840
<nop,nop,timestamp 32373 9210436>

#ACK 172.23.139.20.1040 > 172.23.139.11.2345

[repeat ad nauseum]

foobar:~# ping 172.23.139.11
PING 172.23.139.11 (172.23.139.11): 56 data bytes
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=0.963 ms
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=1.343 ms (DUP!)
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=1.609 ms (DUP!)
64 bytes from 172.23.139.11: icmp_seq=0 ttl=64 time=1.704 ms (DUP!)
--- 172.23.139.11 ping statistics ---
1 packets transmitted, 1 packets received, +3 duplicates, 0% packet loss
round-trip min/avg/max = 0.963/1.404/1.704 ms
taclog-central:~#

D'oh, I feel kind of stupid now. I should have looked closer at the tcpdump 
output. Thanks for helping me engaging my brain. We set up a cluster on VMWare 
GSX and configure multiple secondary IP addresses on the same virtual bridge.

> That path covers multiple cases and the comment refers to ignored SYN/ACK
> packets :-) .

True.

> You can't be in sNO state: if the assumption is valid (i.e. that's a
> resent SYN) then the connection is in sSR or above.

Of course it's in sSR, I was just being mentally slow. Unfortunately I've got to 
debug on so many things right now that my brain stack flushes every 10 minutes.

Best regards,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Rathausgasse 31, CH-5001 Aarau  tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-12-17 12:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-17 11:07 strange INVALID SYN in ip_conntrack (tcp window tracking enabled) in 2.4.27 kernel Roberto Nibali
2004-12-17 11:32 ` Jozsef Kadlecsik
2004-12-17 12:01   ` Roberto Nibali

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.