Re: state: INVALID

["Björn Schmidt" <bj-schmidt@uni-paderborn.de>]

Jason Opperisano wrote:
>>the ulogd logfile of my server shows many "INVALID state" packets. What could
>>be the reason for that?
> 
> my guess would be because you have a log rule that logs on "-m state
> --state INVALID"

Yes, of course. ;)

>>The server has one cardbus nic (eth0), one dsl-interface (ppp0) and, of course
>>lo. The client has only eth0 and lo. The kernel version of both computers is
>>2.6.10-rc2
>>
>>syslogemu.log:Nov 19 20:31:52 kilobyte INPUT_INVALID IN=eth0 OUT= 
>>MAC=00:d0:b7:01:ce:2a:00:04:e2:7f:90:41:08:00  SRC=192.168.0.2 DST=192.168.0.1 
>>LEN=52 TOS=00 PREC=0x00 TTL=64 ID=1680 DF PROTO=TCP SPT=32899 DPT=3130 
>>SEQ=4260699581 ACK=510793293 WINDOW=5080 ACK FIN URGP=0
 >
 > this is a FIN-ACK packet from the client to the server for an ICP
 > session.

Ooops, i picked exactly the entries from the log which are _really_ invalid.
Sorry for that (it was to late at night...).

Here is a(n older) packet that is _falsely_ classified as INVALID (should be
ESTABLISHED). I changed the IP-adress and hostname in the meantime:

Oct 29 13:51:05 skyron ILLEGAL_PACKET IN= OUT=eth0 MAC= SRC=192.168.1.1 
DST=192.168.1.2 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 
DPT=33085 SEQ=1048000056 ACK=1050690244 WINDOW=5792 ACK SYN URGP=0

Besides I forgot to mention that i only get "false INVALID" states with
activated IPsec (esp in transport mode, kernel 2.6). With IPsec _AND_ iptables
it es NOT possible to establish a new tcp connection due to these "INVALID
state packets".
There is also a (german) thread at debian-users-german where we tried to solve 
this problem, without success:
  http://lists.debian.org/debian-user-german/2004/10/msg02735.html

> the definition of an INVALID packet is simply a packet that is neither
> ESTABLISHED nor RELATED.  depending on the specific communication in
> question and the timeout values on the firewall for the CLOSE-WAIT
> state--you can see a *ton* of FIN-ACK packets that will be considered
> "invalid" as they arrive after the firewall has removed the connection
> in question from conntrack.  port-unreachables should normally match as
> "related," but there could have been something funny going on.

-- 
Greetings
Bjoern Schmidt