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

ENTERPRISE CONSOLE - REMOTE CLIENT NOT CONNECTED

Good morning, our securty enterprise console from a couple of months is no longer able to communicate with customers' computers, even update managers have not been updated for months; client-side updates instead work correctly.
I tried with the following solutions:
- correct communication of  server-side ports and telnet tests from clients
- control of services started
- community.sophos.com/.../time-of-last-binary-update-is-a-long-time-ago
- https: //community.sophos.com/products/endpoint-security-control/f/sophos-enterprise-console/96059/most-clients-shown-as-disconnected-in-sec-5-5-0

I have not solved
thank you

Emanuele


This thread was automatically locked due to age.
Parents
  • Hello Emanuele,

    are you an MSP?

    client side updates [...] work correctly
    did you also check the Network Communication Report? You say that telnet yourSECserver 8192 works - you did get an IOR: in response= If so, you can parse it here (you have to remove the CRLFs so that the IOR: is a single line).

    Christian

  • Yes i am a partner.

     

    Network report says it's everything ok, 

     

    telet result internal network:

     

    _IIOP_ParseCDR:  byte order LittleEndian, repository id <IDL:SophosMessaging/MessageRouter:1.0>, 1 profile
    _IIOP_ParseCDR:  profile 1 is 164 bytes, tag 0 (INTERNET), LittleEndian byte order
    (iiop.c:parse_IIOP_Profile):  bo=LittleEndian, version=1.2, hostname=10.234.0.53, port=8193, object_key=<....NUP...!........RootPOA.RouterPersistent.........MessageRouter>
    (iiop.c:parse_IIOP_Profile):  encoded object key is <%14%01%0F%00NUP%00%00%00%21%00%00%00%00%01%00%00%00RootPOA%00RouterPersistent%00%03%00%00%00%01%00%00%00MessageRouter>
    (iiop.c:parse_IIOP_Profile):  non-native cinfo is <iiop_1_2_1_%2514%2501%250F%2500NUP%2500%2500%2500%2521%2500%2500%2500%2500%2501%2500%2500%2500RootPOA%2500RouterPersistent%2500%2503%2500%2500%2500%2501%2500%2500%2500MessageRouter@tcp_10.234.0.53_8193>
    object key is <#14#01#0F#00NUP#00#00#00!#00#00#00#00#01#00#00#00RootPOA#00RouterPersistent#00#03#00#00#00#01#00#00#00MessageRouter>;
     no trustworthy most-specific-type info; unrecognized ORB type;
     reachable with IIOP 1.2 at host "10.234.0.53", port 8193

    object key is <#14#01#0F#00NUP#00#00#00!#00#00#00#00#01#00#00#00RootPOA#00RouterPersistent#00#03#00#00#00#01#00#00#00MessageRouter>;
     no trustworthy most-specific-type info; unrecognized ORB type;
     reachable with IIOP 1.2 at host "10.234.0.53", port 8193



    telnet from remote client:

    _IIOP_ParseCDR:  byte order LittleEndian, repository id <IDL:SophosMessaging/MessageRouter:1.0>, 1 profile
    _IIOP_ParseCDR:  profile 1 is 164 bytes, tag 0 (INTERNET), LittleEndian byte order
    (iiop.c:parse_IIOP_Profile):  bo=LittleEndian, version=1.2, hostname=10.234.0.54, port=8193, object_key=<....NUP...!........RootPOA.RouterPersistent.........MessageRouter>
    (iiop.c:parse_IIOP_Profile):  encoded object key is <%14%01%0F%00NUP%00%00%00%21%00%00%00%00%01%00%00%00RootPOA%00RouterPersistent%00%03%00%00%00%01%00%00%00MessageRouter>
    (iiop.c:parse_IIOP_Profile):  non-native cinfo is <iiop_1_2_1_%2514%2501%250F%2500NUP%2500%2500%2500%2521%2500%2500%2500%2500%2501%2500%2500%2500RootPOA%2500RouterPersistent%2500%2503%2500%2500%2500%2501%2500%2500%2500MessageRouter@tcp_10.234.0.54_8193>
    object key is <#14#01#0F#00NUP#00#00#00!#00#00#00#00#01#00#00#00RootPOA#00RouterPersistent#00#03#00#00#00#01#00#00#00MessageRouter>;
     no trustworthy most-specific-type info; unrecognized ORB type;
     reachable with IIOP 1.2 at host "10.234.0.54", port 8193

    object key is <#14#01#0F#00NUP#00#00#00!#00#00#00#00#01#00#00#00RootPOA#00RouterPersistent#00#03#00#00#00#01#00#00#00MessageRouter>;
     no trustworthy most-specific-type info; unrecognized ORB type;
     reachable with IIOP 1.2 at host "10.234.0.54", port 8193


     

  • Hello Emanuele,

    sorry, I menat what does Wireshark show for the telnet connection?

    Christian

  • 21 5.084280 192.x.x.x 10.x.x.x TCP 62 61604 → 8194 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1

    96 19.082120 192.x.x.x  10.x.x.x  TCP 66 [TCP Port numbers reused] 61604 → 8194 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

    106 22.083265 192.x.x.x  10.x.x.x  TCP 66 [TCP Retransmission] 61604 → 8194 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

    129 28.081596 192.x.x.x  10.x.x.x  TCP 62 [TCP Retransmission] 61604 → 8194 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1

  • Hello Emanuele,

    also no connection established. Hm, telnet should return a Could not open ...: Connect failed. Wonder why you don't see it.
    Anyway - the SYN is not acknowledged, no connection is established. Either the port is not open on 10.x.x.x - we can rule this out -, or the firewall on 10.x.x.x quietly drops the packet (e.g. because 192.x.x.x is not in the permitted IP range), or some device on the route drops the SYN. In theory some device could drop the SYNACK answer but this is very unlikely.

    Christian 

  • I will check all the rules on firewall but local computers are ok and the behaviour is the same... it's very strange.

     

    Thanks


    Emanuele

  • Hello Emanuele,

    I don't think it's the local firewall - more likely the one on the relay or a firewall/ACLs  between the subnets (assuming these servers and the relay are not on the same subnet).

    Christian

  •  

     

    The Strange thing that update manager are connected but the last update try is two monts ago... any idea?

  • 10.x.x.x is my local network behind a firewall, and i cannot see any computer on the local subnet of my customers, so i think there is some on my network blocking, otherwise it would be  a problem just to a single customer

  • Hello Emanuele,

    the Connected indicator is sometimes misleading. RMS is designed to either work "half-duplex" or (ideally) duplex. Communication is always initiated by the endpoint logging on the the management server (port 8194). The server then tries to establish a downstream connection to the endpoint's 8194. If it succeeds then SEC can send policies and commands immediately. Otherwise the management server supplies its messages only in response to a message from the endpoint.
    It's the upstream connection that determines the Dis/Connected status. The status is changed to Disconnected when the endpoint's Message Router logs off, it does so when it's stopped. If the computer crashes, the network cable is unplugged, or the route is down the management server doesn't receive the logoff and the status remains connected. It is rumoured that there's a reaper thread but I can't confirm this. A failure to send a command downstream does not result in Disconnect. My impression is that only a Protect attempt changes the status.

    Please check the Last message time of these SUMs in the Endpoints view, tab Computer Details - I'm pretty sure it is in the last hour of 10/4/2018. This would suggest that there were changes in the network that prevent communication since then. BTW - for some reason the first SUM on the list hasn't updated like the others, furthermore it's still on 1.5.8 - is this perhaps a 2003?

    Christian

  • Christian, 

    It's a windows xp sp3 computer :)

    The only thing i can suppose, as i said, that's something on my firewall, but no connectivity or rules has changed on those days.

     

    Thanks for your support

  • Hello Emanuele,

    2003? - It's a windows xp sp3
    same thing essentially [:D]

    something on my firewall
    naturally I can't say what's common to all customers' connections and on or between the perimeter and the server. The date is certain and it seems the change happened around midnight so someone should remember.

    Christian

Reply
  • Hello Emanuele,

    2003? - It's a windows xp sp3
    same thing essentially [:D]

    something on my firewall
    naturally I can't say what's common to all customers' connections and on or between the perimeter and the server. The date is certain and it seems the change happened around midnight so someone should remember.

    Christian

Children
No Data