Jump to content

Agent unable to connect when in remote site/subnet


antoineL
 Share

Go to solution Solved by MartinK,

Recommended Posts

I recently installed a permanent site-to-site connection for a remote place. Thus the workstation there is in a different subnet (192.168.170.0/24) than the rest of the computers, and the rest include the ERA server (192.168.100.249). As far as I can [now] tell, it worked (no irrelevant message in trace.log, and I did have informations for the workstation, regularly updated).

Then I migrated the EMSC server to PROTECT (8.0.1238, new database, new machine now with 2 NIC), and I upgraded security to advanced (SHA2), and renewed all certificates.
Now the ERA agent there is not connecting (all the "nearer" computers are OK). It happened with the old 7.0.577, and it continues to happen with up-to-date agent 8.0.1238.

Here is the relevant part from status.html (Last replication

ERROR: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details:

  • Replication details: [Task: CReplicationConsistencyTask, Scenario: Automatic replication (REGULAR), Connection: 192.168.100.249:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 65418658-44fc-4b84-8e61-cffdb9128a9b, Sent logs: 0, Cached static objects: 3, Cached static object groups: 1, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0]
  • All replication attempts: 52

Here are the lines from most recent trace.log:

2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: 
2020-12-16 15:48:03 Warning: CReplicationModule [Thread 1530]: InitializeConnection: Not possible to establish any connection (Attempts: 1)
2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: InitializeFailOverScenario: Skipping fail-over scenario (stored replication link is the same as current)
2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: CAgentReplicationManager: Replication finished unsuccessfully with message: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message:  Connect Failed, and error details: Replication details: [Task: CReplicationConsistencyTask, Scenario: Automatic replication (REGULAR), Connection: 192.168.100.249:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 65418658-44fc-4b84-8e61-cffdb9128a9b, Sent logs: 0, Cached static objects: 3, Cached static object groups: 1, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0]

I have tried (using reinstall) to set up the agent to connect with either a DNS name or an address (the server certificate have both alternate subject names), but both fail.

I checked DNS resolution and IP routes, seem clean; I do not believe there are any router performing NAT (or PAT) while routing; at both gateways, I see the agent sending something (260 bytes) but there is no answer. At the Windows firewall of the server (firewall.log), I do not see anything dropped.

I tried a telnet session from the remote place on port 2222, but it times out.

I read Marcos' post about a similar issue yesterday, and perhaps it could be an issue with certificate inspection. But since the site-to-site connection have not changed in the meanwhile (i.e., it worked with SHA1 certificates and fails with SHA2???), I am not sure how to troubleshoot it; of course there is a lot more traffic which goes through the same tunnel, part of it with certificates, and nothing seems dropped.

There is something which is definitively different with certificates however: earlier, the old server certificate was of "Server at *" kind (only SAN=DNS:*); while the new one is somehow more restrictive: it have just the DNS name (actually a CNAME) of the server and its IPv4 as SAN.
But if that is wrong, I would like to understand why...

Link to comment
Share on other sites

  • ESET Staff
  • Solution
4 hours ago, antoineL said:

I recently installed a permanent site-to-site connection for a remote place. Thus the workstation there is in a different subnet (192.168.170.0/24) than the rest of the computers, and the rest include the ERA server (192.168.100.249). As far as I can [now] tell, it worked (no irrelevant message in trace.log, and I did have informations for the workstation, regularly updated).

Then I migrated the EMSC server to PROTECT (8.0.1238, new database, new machine now with 2 NIC), and I upgraded security to advanced (SHA2), and renewed all certificates.
Now the ERA agent there is not connecting (all the "nearer" computers are OK). It happened with the old 7.0.577, and it continues to happen with up-to-date agent 8.0.1238.

Here is the relevant part from status.html (Last replication

ERROR: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details:

  • Replication details: [Task: CReplicationConsistencyTask, Scenario: Automatic replication (REGULAR), Connection: 192.168.100.249:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 65418658-44fc-4b84-8e61-cffdb9128a9b, Sent logs: 0, Cached static objects: 3, Cached static object groups: 1, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0]
  • All replication attempts: 52

Here are the lines from most recent trace.log:

2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: 
2020-12-16 15:48:03 Warning: CReplicationModule [Thread 1530]: InitializeConnection: Not possible to establish any connection (Attempts: 1)
2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: InitializeFailOverScenario: Skipping fail-over scenario (stored replication link is the same as current)
2020-12-16 15:48:03 Error: CReplicationModule [Thread 1530]: CAgentReplicationManager: Replication finished unsuccessfully with message: InitializeConnection: Initiating replication connection to 'host: "192.168.100.249" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "192.168.100.249" port: 2222 with proxy set as: Proxy: Connection: :3128, Credentials: Name: , Password: ******, Enabled:0, EnabledFallback:1, failed with error code: 14, error message:  Connect Failed, and error details: Replication details: [Task: CReplicationConsistencyTask, Scenario: Automatic replication (REGULAR), Connection: 192.168.100.249:2222, Connection established: false, Replication inconsistency detected: false, Server busy state detected: false, Realm change detected: false, Realm uuid: 65418658-44fc-4b84-8e61-cffdb9128a9b, Sent logs: 0, Cached static objects: 3, Cached static object groups: 1, Static objects to save: 0, Static objects to delete: 0, Modified static objects: 0]

I have tried (using reinstall) to set up the agent to connect with either a DNS name or an address (the server certificate have both alternate subject names), but both fail.

I checked DNS resolution and IP routes, seem clean; I do not believe there are any router performing NAT (or PAT) while routing; at both gateways, I see the agent sending something (260 bytes) but there is no answer. At the Windows firewall of the server (firewall.log), I do not see anything dropped.

I tried a telnet session from the remote place on port 2222, but it times out.

I read Marcos' post about a similar issue yesterday, and perhaps it could be an issue with certificate inspection. But since the site-to-site connection have not changed in the meanwhile (i.e., it worked with SHA1 certificates and fails with SHA2???), I am not sure how to troubleshoot it; of course there is a lot more traffic which goes through the same tunnel, part of it with certificates, and nothing seems dropped.

There is something which is definitively different with certificates however: earlier, the old server certificate was of "Server at *" kind (only SAN=DNS:*); while the new one is somehow more restrictive: it have just the DNS name (actually a CNAME) of the server and its IPv4 as SAN.
But if that is wrong, I would like to understand why...

Actually enabling advanced security has not impact on certificate validations - it just forces console to generate more secure certificates, but original ones would still work.

But what changes with enabling advanced security is that older TLS protocols (If I recall correctly, older than TLS 1.2) are disabled for AGENT connections, and also older and no-longer-safe cipher suites are disabled, which means that only devices with support for latest protocol versions would connection. Recent versions of AGENT do have this support, as they no longer rely on cryptographic primitives provided by operating system, but in case TLS introspection is used in between AGENT and SERVER, it might be blocked in case it does not support any of safe algorithm.

Regarding analysis, this seems to be network or TLS related, so I would recommend to analyze network communication using tools like wireshark. It is possible that problem is between TLS introspection component and SERVER, and not between AGENT and TLS component, so proper place for capturing of traffic will be required.

Link to comment
Share on other sites

Hi Martin,

Thanks for the hint. And as it came out, you were right on target: the problem was with the network (the server is multi-homed and was missing the route backward to the remote subnet). And a simple ping at the right place (or a good sleeping night) was enough to solve it.

Nothing related in any way to the ESET products, 🙂 Case solved.

Edited by antoineL
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...