We have a Blackberry Enterprise Server, which essentially uses an outbound TCP connection on port 3101 to a certain external server. We have configured the corresponding firewall rules on our Astaro (version 8.309) ages ago and things have worked for a long time. Yesterday, we had to restart the Blackberry server for some reason and no outbound contact was possible any more. Previous reboots have never posed a problem. Our research lead to the following results: According to tcpdump on the external Astaro interface, a valid three-way handshake occurs (SYN out, SYN/ACK in, ACK out), but after that no more traffic in either direction. (The expected behaviour is that the client sends data, i.e. there is no "greeting banner" on the server side) A test program on the Blackberry server (bbsrptest.exe) reports "connection established" and "sending packet"(!), then reports an error after timeout The same test program with using a different extenal server (we tried the US instead of European server) works like a charm (and tcpdump shows the outbound data packet after handshake) Trying a telnet on port 3101 from a different internal client shows the same behaviour: Connection with US server ok, connection with European server fails Trying to use a different external IP via SNAT shows the same behaviour: Connection with US server ok, connection with European server fails. While this seems to indicate a problem on the remote side as it depends on the destination server ip address, this is obviously not the case as the moment of failure is that the client side does not send a data packet. However, the actual client does send that data packet, but it is dropped somehow at the firewall althought the connection itself is granted and successfully established! We had no idea whatsoever what caused the blocking and tried a reboot of the firewall out of pure desperation - and it helped! Now I am just curious: What caused the problem? Which "feature" could have been responsible for the blocking? At least it was none of the rules I am aware of as these did not change across the reboot How could we have noticed that it was this "feature" that decided to block the - valid according to all rules and not blocked during connection initiation! - traffic? What can be done short of a reboot if this should happen again? Afterwards, a colleague recalled to have resolved a similar situation a few months ago using a restore of an older Astaro configuration and reboot - but with today's results, probably the reboot alone would have sufficed. A reboot during working hours is of course not desireable as it interrupts important VPN traffic for several minutes, nor is it desireable to kepp all Blackberries cut off all day until a nightly reboot is possible! Thanks for any insights, Hagen

This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Allowed outbound worked, then fails, works again after firewall reboot

We have a Blackberry Enterprise Server, which essentially uses an outbound TCP connection on port 3101 to a certain external server. We have configured the corresponding firewall rules on our Astaro (version 8.309) ages ago and things have worked for a long time. Yesterday, we had to restart the Blackberry server for some reason and no outbound contact was possible any more. Previous reboots have never posed a problem. Our research lead to the following results:

According to tcpdump on the external Astaro interface, a valid three-way handshake occurs (SYN out, SYN/ACK in, ACK out), but after that no more traffic in either direction. (The expected behaviour is that the client sends data, i.e. there is no "greeting banner" on the server side)
A test program on the Blackberry server (bbsrptest.exe) reports "connection established" and "sending packet"(!), then reports an error after timeout
The same test program with using a different extenal server (we tried the US instead of European server) works like a charm (and tcpdump shows the outbound data packet after handshake)
Trying a telnet on port 3101 from a different internal client shows the same behaviour: Connection with US server ok, connection with European server fails
Trying to use a different external IP via SNAT shows the same behaviour: Connection with US server ok, connection with European server fails.

While this seems to indicate a problem on the remote side as it depends on the destination server ip address, this is obviously not the case as the moment of failure is that the client side does not send a data packet. However, the actual client does send that data packet, but it is dropped somehow at the firewall althought the connection itself is granted and successfully established!

We had no idea whatsoever what caused the blocking and tried a reboot of the firewall out of pure desperation - and it helped!

Now I am just curious:

What caused the problem?
Which "feature" could have been responsible for the blocking? At least it was none of the rules I am aware of as these did not change across the reboot
How could we have noticed that it was this "feature" that decided to block the - valid according to all rules and not blocked during connection initiation! - traffic?
What can be done short of a reboot if this should happen again? Afterwards, a colleague recalled to have resolved a similar situation a few months ago using a restore of an older Astaro configuration and reboot - but with today's results, probably the reboot alone would have sufficed. A reboot during working hours is of course not desireable as it interrupts important VPN traffic for several minutes, nor is it desireable to kepp all Blackberries cut off all day until a nightly reboot is possible!

Thanks for any insights,
Hagen

This thread was automatically locked due to age.

Parents

0 BAlfson over 12 years ago

You might try what I call Rule #1:
Whenever something seems strange, always check the Intrusion Prevention and Firewall logs.

Anything there?

Cheers - Bob
Cancel
Vote Up 0 Vote Down

Cancel
0 BrucekConvergent over 12 years ago in reply to BAlfson

A hint; I have seen BES (in some installations) falsely trigger some rules in BOTH Application Control and IPS; check both logs and create exceptions as necessary.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 BrucekConvergent over 12 years ago in reply to BAlfson

A hint; I have seen BES (in some installations) falsely trigger some rules in BOTH Application Control and IPS; check both logs and create exceptions as necessary.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data