Blackberry problem

[newbie_zeng]

hi all, help needed as i newbie to this.

i'm setting up blackberry enterprise server (for domino) in the internal segment of my network (10.xxx.xxx.xxx.xxx).

My company network consist of 3 segment: internal (10.x.x.x), dmz(192.x.x.x) and then external(internet)(58.x.x.x)

i have added 2 rules to allowed the server to the blackberry host and vice versa.

And accessing the internet is working at our server.

but i have problem when trying to test connection to the external blackberry host (206.51.26.124).

the connection always timed out.

the test connection will test connection between our server and srp.ap.blackberry.net using tcp port 3101 for both inbound and outbound.

the result of test is: connection failed. connection timed out.(10060)

I had already allowed *any service from the internal server to go to the blackberry host, but it still timed out.

I don't understand why i can access the internet from the server but still timed out when testing connection to the blackberry host.

appreciate any help i can get.

[RayPesek]

From the BES box, can you do a

telnet srp.ap.blackberry.net 3101

and get a connection? If so, your rules are correct and something is wrong with the BES installation.

Does the BES server go through a proxy for Internet access? If so, you may have a NAT issue if telnet doesn't work as noted above.

Ray

[newbie_zeng]

Ray, tks for your help.


telnet srp.ap.blackberry.net - the result was could not open connection to the host, on port 23. Connection failed.

the BES is configured to access the internet directly, bypassing the proxy server. it is configured to point to our ISP dns instead our internal dns.

how is that telnet still fails when i had allow *any service from the srp.ap.blackberry.net to our BES in the firewall rule?

[mcnallym]

From that you hadn't added the 3101 on the end as said that port23 not open. Port 23 is the standard telnet port.

I would suggest that possibly you have no service definition for tcp 3101.

Don't forget that ANY on a check point box is any defined service that has match any ticked in the service definition. It does not actually mean all ports.

[chillyjim]

Originally Posted by mcnallym

Don't forget that ANY on a check point box is any defined service that has match any ticked in the service definition. It does not actually mean all ports.

Not exactly true. This is the answer I got from a Check Point developer a while ago

“Any” service means every port (known, defined, unknown, or undefined) when used in the rulebase. Otherwise, “any, any, any, any, drop” rule would be completely worthless.

However, there are various reasons why a packet may get dropped despite having a single any,any,any,any,accept rule in the rulebase. These reasons vary from version to version and hotfix to hotfix primarily because these versions can include new deep-level application inspect (service dropped by SmartDefense protocol enforcement such as SIP drop when encapsulated in http).
Some common reasons for drop packets despite “any-accept” rule:
- Protocol enforcement (i.e. port 80 really is http traffic)
- IP Options flags exist on the IP header and is dropped before rulebase (i.e. PIM multicast traffic in version 4.1)
- (Rare) Limitation in Firewall, Acceleration, QOS, or Clustering implementation that see the traffic as invalid (usually quickly fixed in a later HFA or SHF)
- TCP out of state (asymmetric routing problems or long delays that allow tcp start timeout to expire before syn-ack)
- UDP or undefined service out of state caused by bi-directional data traffic
- Complex code required for NAT and other functions but proper inspect is not being called by “any” rule (mentioned by Adam)
o this can happen when more than one service of a specific port # is defined with “match for any” checked
o or, if “match for any” checkbox was removed from an important service definition and other duplicate service objects exist with less complex inspect code calls
o or, if a new service was defined and selected as “match for any” which negates the inspect code of other pre-defined services. An example of this would be manually creating a tcp service for port 135 and configuring it for “match for any”. This would potentially prevent the portmap service from properly matching the dce-rpc code uuid’s defined in the dce-rpc pre-defined services.

In short, because the list of reasons is dynamic from one version to the next and can be very specific to unpredictable customer mis-configurations, it is not practical to try to compile a complete list and keep it up-to-date.

I hope that the above information helps you respond effectively short of providing a simple list.

[chillyjim]

Originally Posted by newbie_zeng

the test connection will test connection between our server and srp.ap.blackberry.net using tcp port 3101 for both inbound and outbound.

the result of test is: connection failed. connection timed out.(10060)

Try the telnet again with "3101" at the end.

Check the logs to see if anything is being dropped from your BES server and/or the blackberry server (srp.ap.blackberry.net has address 206.51.26.124)

From the enforcement point, do a:

fw monitor -e 'accept (src=<BES-server> and dst=206.51.26.124) or (src=206.52.26.124 and dst=<BES-server>);'