Re: Reassemble frags?
This is a discussion on Re: Reassemble frags? within the IPFilter forums, part of the System Security and Security Related category; > This message is in MIME format. Since your mail reader does not understand this format, some or all of ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-17-2005
|
|||
|
|||
Re: Reassemble frags?
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible. --B_3191439049_1637757 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 2/16/05 9:02 PM, "Steve Bernacki" <steve@copacetic.net> wrote: > Peter Eisch wrote: >> I have two linux boxes (neither running ipfilter) that talk to each othe= r >> across a 3DES vpn. Between the vpn concentrator on my side and my insid= e >> linux host I have an ipfilter firewall. When my local host opens an htt= ps >> 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 th= e >> packets down to 762 and 738 chunks (or thereabouts) and these arrive bac= k to >> my local linux host (the https client). >>=20 > [snip] >=20 > 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. >=20 > 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=3Dipfilter&m=3D108133775629797&w=3D2> for > more information. There are other threads in the mailing list archive > that go into more detail on this, as well. >=20 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,wscal= e 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:768@0+) 21:42:19.234735 remote.https > local.38643: . 1449:2185(736) ack 143 win 5792 <nop,nop,timestamp 168991531 384750599> (frag 33826:768@0+) 21:42:19.479398 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991557 384750599> (frag 33827:768@0+) 21:42:19.999030 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991609 384750599> (frag 33828:768@0+) 21:42:21.038987 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991713 384750599> (frag 33829:768@0+) 21:42:23.119178 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168991921 384750599> (frag 33830:768@0+) 21:42:27.277731 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168992337 384750599> (frag 33831:768@0+) 21:42:35.598628 remote.https > local.38643: . 1:737(736) ack 143 win 5792 <nop,nop,timestamp 168993169 384750599> (frag 33832:768@0+) 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 ha= s a default config, not special tuning. Shouldn=B9t 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=B9m thinking that it=B9s not anything ipfilter can help me with, but perhaps the SSL negotiation isn=B9t starting right... Anyone concur? Thanks, peter --B_3191439049_1637757 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: Reassemble frags?</TITLE> </HEAD> <BODY> <FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:12.0px'>On 2/16/05 9:02 PM, &qu= ot;Steve Bernacki" <steve@copacetic.net> wrote:<BR> <BR> <FONT COLOR=3D"#0000FF">> Peter Eisch wrote:<BR> </FONT><FONT COLOR=3D"#008000">>> I have two linux boxes (neither runni= ng ipfilter) that talk to each other<BR> >> across a 3DES vpn. Between the vpn concentrator on my side a= nd my inside<BR> >> linux host I have an ipfilter firewall. When my local host o= pens an https<BR> >> connection to the remote linux server, I see 1500b packets being w= ritten out<BR> >> to the remote's LAN and I see the remote VPN concentrator fragment= ing the<BR> >> packets down to 762 and 738 chunks (or thereabouts) and these arri= ve back to<BR> >> my local linux host (the https client).<BR> >> <BR> </FONT><FONT COLOR=3D"#0000FF">> [snip]<BR> > <BR> > What do your IPF rules look like? Are you using the "= keep frags" <BR> > option in the appropriate rules? "keep frags" causes I= PF to watch for <BR> > fragmented packets and allow subsequent fragments to pass through.<BR> > <BR> > Another possibility is that your VPN concentrator is sending the <BR> > fragmented packets out of order, which is something that IPF cannot de= al <BR> > with; it must receive the first segment before any of the others. &nbs= p;See <BR> > <a href=3D"http://marc.theaimsgroup.com/?l=3Dipfilter&m=3D108133775629797&w=3D= 2"><http://marc.theaimsgroup.com/?l=3Dip...9797&w=3D= 2></a> for <BR> > more information. There are other threads in the mailing l= ist archive <BR> > that go into more detail on this, as well.<BR> > <BR> </FONT><BR> All my rules have the 'keep frags' -- everything from the time I see the pa= ckets off the Internet until they show up on the local host are in the same = order.<BR> <BR> 21:42:19.044361 local.38643 > remote.https: S 844439365:844439365(0) win= 5840 <mss 1460,sackOK,timestamp 384750592 0,nop,wscale 0> (DF)<BR> 21:42:19.106193 remote.https > local.38643: S 2445745926:2445745926(0) a= ck 844439366 win 5792 <mss 1460,sackOK,timestamp 168991521 384750592,nop,= wscale 0> (DF)<BR> 21:42:19.106230 local.38643 > remote.https: . ack 1 win 5840 <nop,nop= ,timestamp 384750599 168991521> (DF)<BR> 21:42:19.107695 local.38643 > remote.https: P 1:143(142) ack 1 win 5840 = <nop,nop,timestamp 384750599 168991521> (DF)<BR> 21:42:19.169955 remote.https > local.38643: . ack 143 win 5792 <nop,n= op,timestamp 168991527 384750599> (DF)<BR> 21:42:19.226599 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168991531 384750599> (frag 33825:768@0+)<BR> 21:42:19.234735 remote.https > local.38643: . 1449:2185(736) ack 143 win= 5792 <nop,nop,timestamp 168991531 384750599> (frag 33826:768@0+)<BR> 21:42:19.479398 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168991557 384750599> (frag 33827:768@0+)<BR> 21:42:19.999030 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168991609 384750599> (frag 33828:768@0+)<BR> 21:42:21.038987 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168991713 384750599> (frag 33829:768@0+)<BR> 21:42:23.119178 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168991921 384750599> (frag 33830:768@0+)<BR> 21:42:27.277731 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168992337 384750599> (frag 33831:768@0+)<BR> 21:42:35.598628 remote.https > local.38643: . 1:737(736) ack 143 win 579= 2 <nop,nop,timestamp 168993169 384750599> (frag 33832:768@0+)<BR> 21:42:49.225071 local > remote: icmp: ip reassembly time exceeded [tos 0= xc0] <BR> 21:42:49.225101 local > remote: icmp: ip reassembly time exceeded [tos 0= xc0] <BR> 21:42:49.475046 local > remote: icmp: ip reassembly time exceeded [tos 0= xc0] <BR> 21:42:49.995061 local > remote: icmp: ip reassembly time exceeded [tos 0= xc0] <BR> 21:42:51.035047 local > remote: icmp: ip reassembly time exceeded [tos 0= xc0] <BR> ....<BR> <BR> The dump here shows what the local linux system is receiving. The sta= ck has a default config, not special tuning. Shouldn’t it be abl= e to take the packets arriving at 21:42:19.226599 and just after and make th= em back into a usable frame?<BR> <BR> I guess I’m thinking that it’s not anything ipfilter can help m= e with, but perhaps the SSL negotiation isn’t starting right... = Anyone concur?<BR> <BR> Thanks,<BR> <BR> <BR> peter<BR> </SPAN></FONT> </BODY> </HTML> --B_3191439049_1637757-- 
|
Linear Mode
