Re: return-rst does not work as expected

On Thu, 6 Jul 2006, Dr. Carsten Benecke wrote:
>
> my default rule for unwanted tcp connections to my server is
>
> block return-rst in log proto tcp all
>
> The vendor shipped version of ipfilter does not send back tcp resets but
> some strange fragments instead:
>
> (snooping on the client)
>
> client -> server TCP D=995 S=34357 Syn Seq=34853813 Len=0 Win=24820
> Options=<nop,nop,sackOK,mss 1460>
> server -> client TCP IP fragment ID=34048 Offset=512 MF=0
> client -> server TCP D=995 S=34357 Syn Seq=34853813 Len=0 Win=24820
> Options=<nop,nop,sackOK,mss 1460>
> server -> client TCP IP fragment ID=34304 Offset=512 MF=0
>
>
> Well, I would like to see something similar to this:
>
> client -> server TCP D=995 S=34358 Syn Seq=670532660 Len=0 Win=24820
> Options=<nop,nop,sackOK,mss 1460>
> server -> client TCP D=34358 S=995 Rst Ack=670532661 Win=0
>
>
> Here is some additional information about the server system:
>
> root@server:/etc/ipf# uname -a; /usr/sbin/ipf -V
> SunOS server 5.10 Generic_118855-14 i86pc i386 i86pc
> ipf: IP Filter: v4.0.3 (592)
> Kernel: IP Filter: v4.0.3
> Running: yes
> Log Flags: 0 = none set
> Default: pass all, Logging: available
> Active list: 1
>
>
> Any ideas?

I had something similar between two Solaris 10 U1 x86 boxes recently, but
on connections allowed to the server.
However, snoop showed that the packets were leaving the server correctly,
so you might check that too.
In my case, it appeared to be a Fortinet firewall appliance between the
two boxes that should have blocked those packets, and was shredding them
into fragments instead.

I haven't installed an U2 yet, though I might, also for an IPF problem
(ippool not reloading).

Laurent