- 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.