Date: Wed, 6 Jul 2005 23:29:50 -0400 From: R A <bsdboxes@gmail.com> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: Bad State question Message-ID: <60bf53d705070620293812572b@mail.gmail.com> In-Reply-To: <20050706085939.GH6024@insomnia.benzedrine.cx> References: <60bf53d705070511595889365@mail.gmail.com> <20050706085939.GH6024@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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 fau=
lt.
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@benzedrine.cx> wrote:
> On Tue, Jul 05, 2005 at 02:59:47PM -0400, R A wrote:
>=20
> > 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:
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > 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=3D2680241336 high=3D2680307943 win=3D33304 modulator=3D0 wscale=3D1=
]
> > [lo=3D3834753739 high=3D3834820347 win=3D33304 modulator=3D0 wscale=3D1=
] 9:9 S
> > seq=3D2686921612 ack=3D3834753739 len=3D0 ackskew=3D0 pkts=3D9:8 dir=3D=
in,fwd
> > Jul 5 14:52:54 www1 kernel: pf: State failure on: 1 | 5
>=20
> 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.
>=20
> SEQ_GEQ(src->seqhi, end) ? ' ' : '1',
> SEQ_GEQ(src->seqhi + MAXACKWINDOW, end) ?' ' :'5',
>=20
> The end of the packet, that is the start of the packet (its th_seq,
> 2686921612) plus its length (len=3D0), is end=3D2686921612. 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.
>=20
> The "dir=3Din,fwd" means that the state entry was created for an
> incoming packet, and subsequently matched 9 incoming and 8 outgoing
> packets ("pkts=3D9: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.
>=20
> 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.
>=20
> Maybe it's not a new handshake, but a late arrival of a retransmission
> of the initial SYN, but then why is "seq=3D2686921612" (much higher than
> the initial sequence number)?
>=20
> 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?
>=20
> 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.
>=20
> Daniel
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?60bf53d705070620293812572b>