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 datawhich includes the TCP sequence and ACK numbersalong 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] =================================================