state: INVALID

state: INVALID

[Björn Schmidt]

Hi,

the ulogd logfile of my server shows many "INVALID state" packets. What could
be the reason for that?

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
syslogemu.log:Nov 19 20:31:52 kilobyte OUTPUT_INVALID IN= OUT=eth0 MAC= 
SRC=192.168.0.1 DST=192.168.0.2 LEN=80 TOS=00 PREC=0x00 TTL=255 ID=29481 
PROTO=ICMP TYPE=3 CODE=3
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=13326 DF PROTO=TCP SPT=32845 DPT=993 
SEQ=3094163529 ACK=3641510831 WINDOW=2908 ACK FIN URGP=0

Please CC... ;)

-- 
Greetings
Bjoern Schmidt

Re: state: INVALID

[Jason Opperisano]

On Fri, 2004-11-19 at 17:37, Björn Schmidt wrote:
> Hi,
> 
> 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"

> 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.

> syslogemu.log:Nov 19 20:31:52 kilobyte OUTPUT_INVALID IN= OUT=eth0 MAC= 
> SRC=192.168.0.1 DST=192.168.0.2 LEN=80 TOS=00 PREC=0x00 TTL=255 ID=29481 
> PROTO=ICMP TYPE=3 CODE=3

this is an ICMP Port Unreachable from 192.168.0.1 to 192.168.0.2

> 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=13326 DF PROTO=TCP SPT=32845 DPT=993 
> SEQ=3094163529 ACK=3641510831 WINDOW=2908 ACK FIN URGP=0

this is a FIN-ACK packet from the client to the server for an IMAP/SSL
session.

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.

-j

--
"No jury in the world is going to convict a baby ... Maybe Texas."
	--The Simpsons

Re: state: INVALID

[Björn Schmidt]

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

Re: state: INVALID

[Jason Opperisano]

On Sat, 2004-11-20 at 18:18, Björn Schmidt wrote:
> 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

well--this is a SYN-ACK packet...without seeing the log rule that
creates this "ILLEGAL_PACKET" entry, i can't say.  my guess is that your
rules do not match your intentions.
  
> 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 && iptables -t nat -vnxL && iptables -vnxL

> 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

-j

--
"'Nuke the whales?' You don't really believe that, do you?
 I dunno. Gotta nuke something."
	--The Simpsons

Re: state: INVALID

[Björn Schmidt]

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

Re: state: INVALID

[Jason Opperisano]

On Sun, 2004-11-21 at 17:46, Björn Schmidt wrote:
> 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...

it almost seems like you have an asymmetric routing situation--what i
mean by that is that the SYN packet is reaching 192.168.1.2 without
going through the firewall and therefore the SYN-ACK is NEW, not
RELATED...

also--you keep mentioning IPsec.  first off--i never use conntrack to
match IPsec traffic.  second--you need to be aware that packets traverse
the filter chains twice in a 2.6 kernel--once encrypted, and once
decrypted.  for 2.6 IPsec rules, i use something like:

  # mark ipsec traffic
  iptables -t mangle -A PREROUTING -p 50 -s $PEER -j MARK --set-mark 1

  # allow IKE & ESP in
  iptables -A INPUT -p udp -s $PEER --sport 500 --dport 500 -j ACCEPT
  iptables -A INPUT -p 50 -s $PEER -j ACCEPT

  # allow decrypted packets
  iptables -A INPUT -m mark --mark 1 -j ACCEPT

  # allow IKE & ESP out
  iptables -A OUTPUT -p udp -d $PEER --sport 500 --dport 500 -j ACCEPT
  iptables -A OUTPUT -p 50 -d $PEER -j ACCEPT

  [ your sepcific rules follow here ]

>  > 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

the only packet counters that are incrementing are the OUTPUT chain
filters...  so for *some* reason--you have packets that are leaking
through that first rule...

> 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).

sounds like a reverse name lookup issue.

can you provide a tcpdump (from 192.168.1.2) of a connection attempt?

-j

--
"Weaseling out of things is important to learn. It's what separates
 us from the animals...except the weasel."
	--The Simpsons

Re: state: INVALID

[Jason Opperisano]

alright--let's reset here.  this is how i understand the situation:

you have two machines:

192.168.1.1	(skyron)
192.168.1.2	(gigabyte)

there's an IPSec tunnel setup between the two machines to encrypt all
traffic between them.

you are trying to initiate an SSH connection from 192.168.1.1 to
192.168.1.2.

192.168.1.2 is running iptables.

with no rules loaded on 192.168.1.2, the SSH connection from 192.168.1.1
succeeds.

once you load a basic ruleset on 192.168.1.2--the ACK packets from
192.168.1.2 to 192.168.1.1 get dropped in the OUTPUT chain which allows
"-m state --state ESTABLISHED" packets.

is *all* of the above precisely correct?  if not--where am i losing it?

-j

Re: state: INVALID

[Jason Opperisano]

On Mon, Nov 22, 2004 at 08:32:54PM +0100, Björn Schmidt wrote:
> Jason Opperisano wrote:
> >alright--let's reset here.  this is how i understand the situation:
> >
> >you have two machines:
> >
> >192.168.1.1	(skyron)
> >192.168.1.2	(gigabyte)
> 
> Yes.
> 
> >there's an IPSec tunnel setup between the two machines to encrypt all
> >traffic between them.
> 
> No, not a tunnel. IPsec in transport mode:
> 
> http://www.ipsec-howto.org/x247.html
> 
> >you are trying to initiate an SSH connection from 192.168.1.1 to
> >192.168.1.2.
> 
> No, from 192.168.1.2 to 192.168.1.1
> 
> >192.168.1.2 is running iptables.
> 
> Yes.
> 
> >with no rules loaded on 192.168.1.2, the SSH connection from 192.168.1.1
> >succeeds.
> 
> No, but:
> 
> with no rules loaded on 192.168.1.2, the SSH connection from 192.168.1.2
> to 192.168.1.1 succeeds.
> 
> >once you load a basic ruleset on 192.168.1.2--the ACK packets from
> >192.168.1.2 to 192.168.1.1 get dropped in the OUTPUT chain which allows
> >"-m state --state ESTABLISHED" packets.
> 
> Yes.

would you be so kind as to humor me by loading the following rule set on
192.168.1.2?  essentially--it is the minimal ruleset you can load on
192.168.1.2 to allow bi-directional, IPSec-only communications between
the two machines.  if 192.168.1.2 needs to communicate outbound to other
hosts, or if other hosts need to communicate to 192.168.1.2--this rule
set DOES NOT take that into account (you've been warned).  you'll also
probably have to re-establish the VPN after the firewall rules are
loaded (i.e. load firewall rules first, then initiate VPN).

if you choose to load it--let us know what happens.

---BEGIN SCRIPT---

VPNPEER="192.168.1.1"

for table in mangle nat filter; do
  iptables -t $table -F
  iptables -t $table -X
  iptables -t $table -Z
done

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

iptables -t mangle -A PREROUTING -p 50 -s $VPNPEER -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p 51 -s $VPNPEER -j MARK --set-mark 1

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m mark --mark 1 -m state --state NEW -j ACCEPT
iptables -A INPUT -p 50 -s $VPNPEER -j ACCEPT
iptables -A INPUT -p 51 -s $VPNPEER -j ACCEPT
iptables -A INPUT -p udp -s $VPNPEER --sport 500 --dport 500 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p 50 -d $VPNPEER -j ACCEPT
iptables -A OUTPUT -p 51 -d $VPNPEER -j ACCEPT
iptables -A OUTPUT -p udp -d $VPNPEER --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -d $VPNPEER -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix "OUTPUT DROP: "

--- END SCRIPT ---

-j

--
"Ah, beer, my one weakness. My achilles heel, if you will."
        --The Simpsons

Re: state: INVALID

[Jason Opperisano]

On Tue, 2004-11-23 at 04:18, Björn Schmidt wrote:
> Does not work. I only changed "-J LOG -log-prefix" to "-j ULOG -ulog-prefix"

then either i'm an idiot or there's something horribly wrong with your
kernel.  both are about equally likely at this point.

-j

--
"I bent my wookie."
	--The Simpsons

Re: state: INVALID

[Jason Opperisano]

On Tue, 2004-11-23 at 04:31, Jason Opperisano wrote:
> On Tue, 2004-11-23 at 04:18, Björn Schmidt wrote:
> > Does not work. I only changed "-J LOG -log-prefix" to "-j ULOG -ulog-prefix"
> 
> then either i'm an idiot or there's something horribly wrong with your
> kernel.  both are about equally likely at this point.

just for my own edification--i installed that rule base on my wireless
laptop, which runs a VPN tunnel for all its traffic (but normally does
not use connection tracking), and it does work--so i don't think this is
a "bug" per se.

this is on Fedora Core 2, kernel 2.6.9-1.3, iptables version 1.2.9

(sorry about the line mangling)

Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out    
source               destination
     878   656329 ACCEPT     all  --  *      *      
0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
     883   718600 ACCEPT     all  --  *      *      
0.0.0.0/0            0.0.0.0/0           MARK match 0x1 state NEW
       0        0 ACCEPT     udp  --  eth1   *      
192.168.1.125         0.0.0.0/0           udp spt:500 dpt:500
       0        0 ACCEPT     esp  --  eth1   *      
192.168.1.125         0.0.0.0/0
       0        0 ACCEPT     all  --  lo     *      
0.0.0.0/0            0.0.0.0/0

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

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out    
source               destination
     778    88999 ACCEPT     all  --  *      *      
0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
      26     2037 ACCEPT     all  --  *      *      
0.0.0.0/0            0.0.0.0/0           state NEW
       0        0 ACCEPT     udp  --  *      eth1   
0.0.0.0/0            192.168.1.125        udp spt:500 dpt:500
       0        0 ACCEPT     esp  --  *      eth1   
0.0.0.0/0            192.168.1.125

-j

--
"I'm better than dirt. Well, most kinds of dirt... not that fancy
 store-bought dirt... that stuff's loaded with nutrients, I... I
 can't compete with that stuff."
	--The Simpsons

Re: state: INVALID

[Björn Schmidt]

Björn Schmidt wrote:
> Jason Opperisano wrote:
> 
>> just for my own edification--i installed that rule base on my wireless
>> laptop, which runs a VPN tunnel for all its traffic (but normally does
>> not use connection tracking), and it does work--so i don't think this is
>> a "bug" per se.
> 
> 
> Jason, it works with 2.6.3! Give me some time for some investigations...

It works with all kernels up to 2.6.8, but the patch "patch-2.6.9-rc1"
breaks iptables/ipsec (at least for me).

-- 
Greetings
Bjoern Schmidt

Re: state: INVALID

[Björn Schmidt]

Björn Schmidt 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

Here is one of the "false" INVALID-state packets of today, i tried to connect
from a workstation (192.168.1.2) to the server via ssh:

Nov 21 00:26:53 gigabyte INT_ILLEGAL_PACKET IN= OUT=eth0 MAC= SRC=192.168.1.2
DST=192.168.1.1 LEN=52 TOS=00 PREC=0x00 TTL=64 ID=16033 DF PROTO=TCP SPT=32921
DPT=22 SEQ=340786628 ACK=3785725711 WINDOW=1460 ACK URGP=0

-- 
Greetings
Bjoern Schmidt

Re: state: INVALID

[Jozsef Kadlecsik]

On Fri, 19 Nov 2004, [ISO-8859-15] Björn Schmidt wrote:

> the ulogd logfile of my server shows many "INVALID state" packets. What could
> be the reason for that?
>
> 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

Enable the logging of out-of-window packets and check whether the packets
in question are marked as INVALID by the TCP window tracking code.

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