On 07/03, Erik Huizing wrote:
> Hello,
> I've been noticing some odd behaviour with ipfilter where it looks
> like ipfilter forgets about some session states. Typical scenarion: I'm
> logged in over ssh. The session becomes unresponsive for some period of
> time, then starts responding again.
>
> Significant rules:
>
> pass in quick on lo0
> pass out quick on lo0
>
> pass out quick all keep state
> pass in quick proto icmp all
>
> pass in quick proto tcp from x.y.z.w/23 to any port = 22 flags S keep
> state keep frags
> block in quick proto tcp from any to any port = 80
> block in quick proto tcp from any to any port = 445
> block in quick proto tcp/udp from any to any port 134 >< 140
>
> block in log all
> block out log all
>
> # end of file
>
> Yet somehow this happens:
> Mar 7 10:29:20 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:19.738951 2x bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp
> len 20 52 -AF IN
> Mar 7 10:29:21 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:20.368464 2x bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp
> len 20 52 -AF IN
> Mar 7 10:29:23 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:22.888185 bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:29:26 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:26.248255 bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:29:29 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:29.118347 bge1 @0:29 b x.y.z.w,46505 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:29:33 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:32.968364 bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:29:47 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:29:46.408355 bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:30:14 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:30:13.288244 bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:30:50 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:30:49.757638 bge1 @0:29 b x.y.z.w,46505 -> nn.nn.nn.nn,22 PR tcp len
> 20 52 -AF IN
> Mar 7 10:31:21 ns11.so ipmon[92]: [ID 702911 local0.warning]
> 10:31:20.608037 bge1 @0:29 b x.y.z.w,46562 -> nn.nn.nn.nn,22 PR tcp len
> 20 40 -A IN
>
> This is on Solaris 9, ipf: IP Filter: v3.4.31 (496),
>
> Other particulars:
> IP states added:
> 8133040 TCP
> 1361747248 UDP
> 32 ICMP
> 4261437398 hits
> 1411216724 misses
> 21971301 maximum
> 0 no memory
> 2727 bkts in use
> 3747 active
> 1361743726 expired
> 8132847 closed
>
> Is there any explaination for this behaviour? Any rules I could
> tweak/add/alter?
>
> Thanks in advance
>
> --
> Erik Huizing
> Regional Services
> (403)-781-4906
Hi Erik,
I know that I had problems with 3.4.29-31 and TCP window scaling (RFC1323). It
seems that this and previous versions of ipfilter doesn't really handle scaling
at all and that the window grows until it gets bigger than the maximum accepted
window size.
I'm not sure if this has been fixed in 3.4.33/34/35, otherwise there is a
patch which Guido van Rooij wrote (included below).
As a test, try turning window scaling off at the client system and see if that
helps.
-km
--- ip_state.c.orig Thu Mar 13 09:20:45 2003
+++ ip_state.c Thu Mar 13 09:20:28 2003
@@ -957,8 +957,8 @@
(SEQ_GE(seq, fdata->td_end - maxwin)) &&
/* XXX what about big packets */
#define MAXACKWINDOW 66000
- (ackskew >= -MAXACKWINDOW) &&
- (ackskew <= MAXACKWINDOW)) {
+ (-ackskew <= (MAXACKWINDOW << tdata->td_wscale)) &&
+ ( ackskew <= (MAXACKWINDOW << tdata->td_wscale))) {
/* if ackskew < 0 then this should be due to fragented
* packets. There is no way to know the length of the
* total packet in advance.
