Have you checked Secure Knowledge?

Yes I did.  I looked at the sk prior to open a TAC case with CP.

I explained to them exactly what I am trying to accomplish.  With diamond
support, I do not deal with CP TAC first line of support.  I get a dedicated TAC
engineer to my account.  I told  him exactly what I want to accomplish and 
provided him with the necessary data (i.e. tcpdump, fw monitor) for him to 
move forward.  I even told  him that they need to mock this up in their own lab 
to test this because this is a very simple scenario.  By the way, I am doing 
this
for my remote trigger black hole scenario where R1 is inside my firewall and
R2 is the perimeter router outside the CP firewall.

The bottom line is that I want to be able to prevent bgp sessions from being
established between R1 and R2 like I would with pix without the keyword 
"norandomseq".  See below:

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a008009487d.shtml

When you are configuring BGP peers with MD5 authentication that pass     
through a PIX firewall, it is important to configure the PIX between the BGP    
 neighbors so that the sequence numbers for the TCP flows between the BGP     
neighbors are not random. This is because the TCP random sequence number     
feature on the PIX firewall is enabled by default, and it changes the TCP     
sequence number of the incoming packets before it forwards them.
    MD5 authentication is applied on the TCP psuedo-IP header, TCP header     
and data (refer to RFC 2385 ). TCP uses this data—which includes the TCP 
sequence     and ACK numbers—along with the BGP neighbor password to create a 
128 bit hash     number. The hash number is included in the packet in a TCP 
header option field.     By default, the PIX offsets the sequence number by a 
random number, per TCP     flow. On the sending BGP peer, TCP uses the original 
sequence number to create     the 128 bit MD5 hash number and includes this 
hash number in the packet. When     the receiving BGP peer gets the packet, TCP 
uses the PIX-modified sequence     number to create a 128 bit MD5 hash number 
and compares it to the hash number     that is included in the packet.
     The hash number is different because the TCP sequence value was     
changed by the PIX, and TCP on the BGP neighbor drops the packet and logs an    
 MD5 failed message similar to this one:


The case has been opened for almost 3 weeks with no resolution.  I get different
answers from CP regarding this.  There is a conf. call next week

Hugo van der Kooij <[EMAIL PROTECTED]> wrote: On Sat, 7 Apr 2007, cisco4ng 
wrote:

> I would have expected the the iBGP session with MD5 authentciation
> would not have established between R1 and R2 because the Checkpoint
> firewall will randomize the tcp sequence number and it will screw
> up the md5 authentication in iBGP.  Much to my suprise, it still
> works.  This tells me that the checkpoint firewall does NOT
> randomize the tcp sequence number at all when traversing from
> one interface to another interface.

Have you checked Secure Knowledge?
Details on how these action occur are in sk30331.

The only way to tell what it actually does is by capturing both sides and 
compare packets. At present you make an assumption here based on what 2 
routers do with BGP without the data to tell exactly what is going on.

You may very well be putting Check Point on the wrong foot by not 
including the proper data.

And as a side note. The first line of support is used to deal with people 
who hardly read the manual. You go over the details with them and make 
sure they got sufficient data and take it to the next level.

There is an art to getting Check Point support at the right level. But I 
usually get to bug status swiftly enough in most of the cases.

Some rules of thumbs for support questions:
  - Get cpinfo output in your initial report.
  - Describe it in a way the first line will be able to figure out. (Don't
    assume anything. Explain everything.)
  - Give them a call about 30 minutes after you logged the call to see who
    picked it up and go over it again to make sure they understand you.
    (Note that most of them do not use English as first language so some
    remarks may get misinterpreted. This is not just Check Point. I have
    this some other companies as well.)

Hugo.

-- 
  [EMAIL PROTECTED] http://hugo.vanderkooij.org/
      This message is using 100% recycled electrons.

  Some men see computers as they are and say "Windows"
  I use computers with Linux and say "Why Windows?"
   (Thanks JFK, for the insight.)

=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to [EMAIL PROTECTED]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[EMAIL PROTECTED]
=================================================


 
---------------------------------
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.

=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to [EMAIL PROTECTED]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[EMAIL PROTECTED]
=================================================

Reply via email to