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 <hvdkooij AT VANDERKOOIJ DOT ORG> 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.
--
hvdkooij AT vanderkooij DOT org 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 LISTSERV AT amadeus.us.checkpoint DOT com
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
fw-1-owner AT ts.checkpoint DOT com
=================================================
---------------------------------
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 LISTSERV AT amadeus.us.checkpoint DOT com
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
fw-1-owner AT ts.checkpoint DOT com
=================================================
|
