On 2014.05.21. 9:26, Ondřej Caletka wrote:
Hello list,
I just observed strange behaviour of one Atlas probe. It was unable to connect to the control server from a corporate network. I suspect that some IDS/IPS appliance detects and drops probe attempt to use port 443 for non-TLS traffic*. I've tested it by trying to SSH to control server from within that network and it failed. However, normal SSH to port 22 works fine.
It would be nice if the probe would be able to try more ways to reach the control server, eg. first attempt on port 443, second on port 22, third on some arbitrary high port number. I know that it would be better to put the probe in front of the firewall/IPS, but this is much more complicated in many corporate networks.
*) At least it doesn't do MitM on HTTPs traffic. I've checked that too.
Cheers, Ondřej Caletka
Hello, The probe and the infrastructure it connects to are doing mutual authentication (every actor has its own key pair for that) over SSH, meaning that if there's an appliance meddling with the traffic, the connection will fail. That's of course by design. We *could* try to fall back to other ports, but reality is that in the vast majority of the cases 443 works fine (*), and where it doesn't, other ports would very likely be blocked as well. It's difficult to justify the added complexity for the marginal benefit. Regards, Robert (*) As far as we know... We are aware of cases where it doesn't.