Bad State question

[R A]

Thanks for the great breakdown on the code.

I think I may know what is going on, and it's quite possibly most of my fault.

The box that hosts the DEST host in the connection is running on about
5 total ip's, when you said:

> So, why would you see a SYN packet (with a too-high, but not completely
> different, th_seq), after the state has matched 9+8 packets already, and
> seems to have seen a connection shutdown?

It ended up that the host's IP  was in a NAT rule,but not the IP that
is in the state failure I sent to the list. I had to sanitize the
output a bit, from the sample I sent, but I think you'll get the
picture.

Once I changed that NAT entry to use another IP available on that
machine, the state errors went away, and I was able to hit the IP not
referenced at all by any rules, or masks in PF.conf at the same rates,
just as if I had the problem and turned PF off.

Easy fix it seems, but it took your comments to help me out.
If you need more info because I -should- be able to do the
aformentioned NAT rule without generating state erorrs, let me know.

Thanks for taking what time you do put out there for PF to help me.
I remember what life was life with IPfilter for many years, and I'm
glad PF is on FreeBSD.

This was my -first- problem in over two years of using PF, and it
didn't last long.

Now I'm curious if it's a freebsd problem with how the box was using a
different IP, but yet it seems maybe port values stay the same across
IP range. tcpdump will be next, but I'm knee deep in something else
right now.

Thanks again,
Robert

On 7/6/05, Daniel Hartmeier <daniel at benzedrine.cx> wrote:
> On Tue, Jul 05, 2005 at 02:59:47PM -0400, R A wrote:
> 
> > I've read through some of the pf.c, in order to attempt to figure out
> > what the state failure | 5 was, since it wasn't a really helpfull
> > number,  and the C code means very little to me, I'm still at a loss.
> >
> > At the end of this email, I do state what I hope to find out, or what
> > I am asking for.
> >
> > First, the output from PF, complaining:
> > =============================
> > Jul  5 14:52:54 www1 kernel: pf: BAD state: TCP dest_host
> > Jul  5 14:52:54 www1 kernel: :443 dest_host:443 src_host:60855
> > [lo=2680241336 high=2680307943 win=33304 modulator=0 wscale=1]
> > [lo=3834753739 high=3834820347 win=33304 modulator=0 wscale=1] 9:9 S
> > seq=2686921612 ack=3834753739 len=0 ackskew=0 pkts=9:8 dir=in,fwd
> > Jul  5 14:52:54 www1 kernel: pf: State failure on: 1       | 5
> 
> The digits correspond to the various sequence number comparisons pf
> does. Those checks that are ok are not printed, the digits you see (1
> and 5) show the checks failed.
> 
>                     SEQ_GEQ(src->seqhi, end) ? ' ' : '1',
>                     SEQ_GEQ(src->seqhi + MAXACKWINDOW, end) ?' ' :'5',
> 
> The end of the packet, that is the start of the packet (its th_seq,
> 2686921612) plus its length (len=0), is end=2686921612. This is both
> higher than the upper limit of the window (src->seqhi) and higher than
> the upper limit plus fudge factor (src->seqhi + MAXACKWINDOW). This is
> why pf blocks it.
> 
> The "dir=in,fwd" means that the state entry was created for an
> incoming packet, and subsequently matched 9 incoming and 8 outgoing
> packets ("pkts=9:8"). The "9:9" means the state entry is in
> "FIN_WAIT_2:FIN_WAIT_2", i.e. it has seen a normal connection close or
> RST, and the state will timeout in about 45s.
> 
> But the "S" means the packet being blocked has the SYN flag set, i.e. is
> part of a handshake for a new connection. The client seems to be
> re-using its source port 60855 to establish a new connection to the
> server port 443, before waiting 2MSL (about 90s), which violates the TCP
> RFC.
> 
> Maybe it's not a new handshake, but a late arrival of a retransmission
> of the initial SYN, but then why is "seq=2686921612" (much higher than
> the initial sequence number)?
> 
> So, why would you see a SYN packet (with a too-high, but not completely
> different, th_seq), after the state has matched 9+8 packets already, and
> seems to have seen a connection shutdown?
> 
> Maybe you can tcpdump on the real interface and try to capture one
> entire connection up to the point where it stalls. For instance, limit
> the dumping to one particular source port number, or dump everything for
> a while, then grep the dump for one particular connection.
> 
> Daniel
>