Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "Björn Schmidt" <bj-schmidt@uni-paderborn.de>
To: Jason Opperisano <opie@817west.com>, netfilter@lists.netfilter.org
Subject: Re: state: INVALID
Date: Sun, 21 Nov 2004 23:46:45 +0100	[thread overview]
Message-ID: <41A11AD5.3080401@uni-paderborn.de> (raw)
In-Reply-To: <1101061543.3501.18.camel@hubcap.ljm.dom>

Jason Opperisano wrote:
> On Sat, 2004-11-20 at 18:18, Björn Schmidt wrote:
>>Jason Opperisano wrote:
>>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
> 
> well--this is a SYN-ACK packet...without seeing the log rule that
> creates this "ILLEGAL_PACKET" entry, i can't say.

I changed the log rule(s) that creates "ILLEGAL_PACKET", now it creates
"OUTPUT_INVALID", "INPUT_INVALID" and "FORWARD_INVALID". Here is one line
from the log with the new rules (client):

Nov 21 23:21:43 gigabyte OUTPUT_INVALID IN= OUT=eth0 MAC= SRC=192.168.1.2 
DST=192.168.1.1 LEN=52 TOS=00 PREC=0x00 TTL=64 ID=23692 DF PROTO=TCP SPT=32807 
DPT=22 SEQ=798630945 ACK=685050669 WINDOW=1460 ACK URGP=0

The state of this packet should be ESTABLISHED, but it _is_ INVALID.
Perhaps there is a bug in ipsec or netfilter...

 > my guess is that your rules do not match your intentions.

Impossible. I have this problem even with this _minimalistic_ ruleset:

gigabyte:~# cat firewall.tmp
#!/bin/sh

iptables  -P INPUT DROP
iptables  -P OUTPUT DROP
iptables  -P FORWARD DROP

iptables  -A INPUT   -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
iptables  -A OUTPUT  -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
iptables  -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT

iptables -A INPUT -m state --state INVALID -j ULOG --ulog-prefix INPUT_INVALID
iptables -A OUTPUT -m state --state INVALID -j ULOG --ulog-prefix OUTPUT_INVALID
iptables -A FORWARD -m state --state INVALID -j ULOG --ulog-prefix FORWARD_INVALID

>>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".
> 
> uh huh...  post your rules:
> 
> iptables -t mangle -vnxL

gigabyte:~# iptables -t mangle -vnxL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination


> iptables -t nat -vnxL

gigabyte:~# iptables -t nat -vnxL
Chain PREROUTING (policy ACCEPT 7 packets, 1515 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

Chain POSTROUTING (policy ACCEPT 26 packets, 2637 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

Chain OUTPUT (policy ACCEPT 26 packets, 2565 bytes)
     pkts      bytes target     prot opt in     out     source 
destination

> iptables -vnxL

gigabyte:~# iptables -vnxL
Chain INPUT (policy DROP 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination
     2460  2616788 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state NEW,RELATED,ESTABLISHED
        0        0 ULOG       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID ULOG copy_range 0 nlgroup 1 prefix 
`INPUT_INVALID' queue_threshold 1

Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts      bytes target     prot opt in     out     source 
destination
        0        0 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state NEW,RELATED,ESTABLISHED
        0        0 ULOG       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID ULOG copy_range 0 nlgroup 1 prefix 
`FORWARD_INVALID' queue_threshold 1

Chain OUTPUT (policy DROP 38 packets, 2036 bytes)
     pkts      bytes target     prot opt in     out     source 
destination
     1938   959688 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state NEW,RELATED,ESTABLISHED
       38     2036 ULOG       all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state INVALID ULOG copy_range 0 nlgroup 1 prefix 
`OUTPUT_INVALID' queue_threshold 1


Hmmm, it is not possible to establish a ssh connection, but it IS
possible to establish a telnet connection (but it needs ~148 seconds
until the "skyron login:" appears).

-- 
Greetings
Bjoern Schmidt



  reply	other threads:[~2004-11-21 22:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-19 22:37 state: INVALID Björn Schmidt
2004-11-20 22:46 ` Jason Opperisano
2004-11-20 23:18   ` Björn Schmidt
2004-11-21 18:25     ` Jason Opperisano
2004-11-21 22:46       ` Björn Schmidt [this message]
2004-11-22 13:45         ` Jason Opperisano
     [not found]           ` <41A2010A.9090601@uni-paderborn.de>
2004-11-22 17:54             ` Jason Opperisano
     [not found]               ` <41A23EE6.4080804@uni-paderborn.de>
2004-11-22 21:39                 ` Jason Opperisano
     [not found]                   ` <41A3007B.7090009@uni-paderborn.de>
2004-11-23  9:31                     ` Jason Opperisano
2004-11-23 14:05                       ` Jason Opperisano
     [not found]                         ` <41A3AFC4.4030109@uni-paderborn.de>
2004-11-24 13:07                           ` Björn Schmidt
     [not found]   ` <419FD149.50308@uni-paderborn.de>
2004-11-20 23:33     ` Björn Schmidt
2004-11-23  9:37 ` Jozsef Kadlecsik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41A11AD5.3080401@uni-paderborn.de \
    --to=bj-schmidt@uni-paderborn.de \
    --cc=netfilter@lists.netfilter.org \
    --cc=opie@817west.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox