Re: Raptor and PIX: incompatibility ?

[Christiaan Meihsl <Christiaan.Meihsl () reuters com>]

Hello Wizards,

A month ago I submitted a question pertaining to TCP traffic that,
after crossing a Pix, was not accepted by a Raptor.
(& thank you Richard for your suggestions, was a lonely crowd !)

For those interested, here are the explanation & solution,
thanx to lots of sniffing & competent local Axent support (thanx Laurent !) :

Problem analysis:
==>  Traffic depending on ACK numbers (TCP, not UDP), after going
     through   Pix, is not accepted by Raptor !!!
- TCP RFC 793 does not specify value of ACK number in first SYN packet.
- NT4, Solaris 7 & 8, Cisco IOS 11.2.10 & 11.3.11, Raptor 6.0.2 set it to 0
   when initiating a connection.
  Is this just a matter of implementation filling in gaps of standard ?
  Other O/Ss: don't know, used what I had.
- Pix (5.1.2 & 5.2.3) changes ALL ACK numbers of ALL TCP headers of  ALL
  packets, in- & out-bound, whatever it's config (with/without PAT, NAT, etc).
  Therefore, they are never =0, even in a SYN packet.
  This feature can't be disabled using the "norandomseq" option.
- NT4 & Win2000 boxen don't care about ACK number in SYN packet.
  No surprise  ;-)  but I guess most non-security non-proxy boxen won't care.
  (I heard Gauntlet 4.1/NT doesn't care either, but have no proof).
- Raptor (6.0.2/Solaris) cares, and does NOT accept SYN packets with
  non-zero ACK number (tried with proxy and GSP, did not try a tunnel).
  Actually discards packet without any log, only way to see it is by sniffing
  the network (snoop on Raptor box).
  Seems to be for security reasons, but couldn't get official confirmation.
  Changing transparency, SYN flood protect, etc is useless.

Solution:
- Apply VPN Driver Hotfix (of 29 feb 2000) available at: :
  http://www.raptor.com/cs/patches/eunv602hotfixes.html
  Description says it fixes Solaris Panics (never had one) and packet
  reassembly problems, but (undocumented:) it also changes things in
  Raptor's virtual adapter, between levels 2 and 3, and makes it more
  tolerant ... (I'll not comment on whether this is secure or not :-# )

Maybe this can help you one day  :-)

Christiaan Meihsl
christiaan.meihsl () reuters com


-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards