Re: Reassemble frags?

[Peter Eisch]

Title: Re: Reassemble frags?

On 2/16/05 9:02 PM, "Steve Bernacki" <[EMAIL PROTECTED]> wrote:

> Peter Eisch wrote:
>> I have two linux boxes (neither running ipfilter) that talk to each other
>> across a 3DES vpn.  Between the vpn concentrator on my side and my inside
>> linux host I have an ipfilter firewall.  When my local host opens an https
>> connection to the remote linux server, I see 1500b packets being written out
>> to the remote's LAN and I see the remote VPN concentrator fragmenting the
>> packets down to 762 and 738 chunks (or thereabouts) and these arrive back to
>> my local linux host (the https client).
>>
> [snip]
>
> What do your IPF rules look like?   Are you using the "keep frags"
> option in the appropriate rules?  "keep frags" causes IPF to watch for
> fragmented packets and allow subsequent fragments to pass through.
>
> Another possibility is that your VPN concentrator is sending the
> fragmented packets out of order, which is something that IPF cannot deal
> with; it must receive the first segment before any of the others.  See
> <http://marc.theaimsgroup.com/?l=ipfilter&m=108133775629797&w=2> for
> more information.   There are other threads in the mailing list archive
> that go into more detail on this, as well.
>

All my rules have the 'keep frags' -- everything from the time I see the packets off the Internet until they show up on the local host are in the same order.

21:42:19.044361 local.38643 > remote.https: S 844439365:844439365(0) win 5840 <mss 1460,sackOK,timestamp 384750592 0,nop,wscale 0> (DF)
21:42:19.106193 remote.https > local.38643: S 2445745926:2445745926(0) ack 844439366 win 5792 <mss 1460,sackOK,timestamp 168991521 384750592,nop,wscale 0> (DF)
21:42:19.106230 local.38643 > remote.https: . ack 1 win 5840 <nop,nop,timestamp 384750599 168991521> (DF)
21:42:19.107695 local.38643 > remote.https: P 1:143(142) ack 1 win 5840 <nop,nop,timestamp 384750599 168991521> (DF)
21:42:19.169955 remote.https > local.38643: . ack 143 win 5792 <nop,nop,timestamp 168991527 384750599> (DF)
21:42:19.226599 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991531 384750599> (frag 33825:[EMAIL PROTECTED])
21:42:19.234735 remote.https > local.38643: . 1449:2185(736) ack 143 win 5792 <nop,nop,timestamp 168991531 384750599> (frag 33826:[EMAIL PROTECTED])
21:42:19.479398 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991557 384750599> (frag 33827:[EMAIL PROTECTED])
21:42:19.999030 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991609 384750599> (frag 33828:[EMAIL PROTECTED])
21:42:21.038987 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991713 384750599> (frag 33829:[EMAIL PROTECTED])
21:42:23.119178 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991921 384750599> (frag 33830:[EMAIL PROTECTED])
21:42:27.277731 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168992337 384750599> (frag 33831:[EMAIL PROTECTED])
21:42:35.598628 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168993169 384750599> (frag 33832:[EMAIL PROTECTED])
21:42:49.225071 local > remote: icmp: ip reassembly time exceeded [tos 0xc0]
21:42:49.225101 local > remote: icmp: ip reassembly time exceeded [tos 0xc0]
21:42:49.475046 local > remote: icmp: ip reassembly time exceeded [tos 0xc0]
21:42:49.995061 local > remote: icmp: ip reassembly time exceeded [tos 0xc0]
21:42:51.035047 local > remote: icmp: ip reassembly time exceeded [tos 0xc0]
...

The dump here shows what the local linux system is receiving.  The stack has a default config, not special tuning.  Shouldn’t it be able to take the packets arriving at 21:42:19.226599 and just after and make them back into a usable frame?

I guess I’m thinking that it’s not anything ipfilter can help me with, but perhaps the SSL negotiation isn’t starting right...  Anyone concur?

Thanks,


peter