Agent reconnect issue when switching networks

[Felix Andorfer]

Hey Wazuh Team ,

I always get those error logs in wazuh-remoted and i think i narowed it down when it happens

My theory:

Laptop starts up in the morning while docked, gets a DHCP IP (e.g., 192.168.40.50).
Agent connects fine as Client01 with that IP.
Later, the laptop is undocked, switches to Wi-Fi, and gets a new DHCP IP in the Wi-Fi VLAN (e.g., 192.168.111.60).
Now the agent tries to reconnect as Client01 but with the new IP. The server might still think Client01 is on the old IP (192.168.40.50), so the connection gets denied.

Could that be what’s going on?

And how can I fix this issue? Any guidance would be greatly appreciated.

The specs i am running:

Wazuh v4.12.0
Agents on v4.11.1 and v4.12.0 (both show the problem)
All agents are Windows laptops

here are the logs :

Aug 27, 2025 @ 09:43:15.000 wazuh-authd INFO  New connection from 192.168.40.154
Aug 27, 2025 @ 09:43:15.000 wazuh-authd INFO  Received request for a new agent (client01) from: 192.168.40.154
Aug 27, 2025 @ 09:43:15.000 wazuh-authd WARNING  Duplicate name 'client01', rejecting enrollment. Agent '032' can't be replaced since it is not disconnected.
Aug 27, 2025 @ 09:43:15.000 wazuh-remoted WARNING  Agent key already in use: agent ID '185'
Aug 27, 2025 @ 09:43:17.000 wazuh-remoted WARNING  Agent key already in use: agent ID '134'
Aug 27, 2025 @ 09:43:21.000 wazuh-remoted WARNING  Agent key already in use: agent ID '133'
Aug 27, 2025 @ 09:43:25.000 wazuh-remoted WARNING  Agent key already in use: agent ID '032'
Aug 27, 2025 @ 09:43:25.000 wazuh-remoted WARNING  Agent key already in use: agent ID '185'
Aug 27, 2025 @ 09:43:28.000 wazuh-remoted WARNING  Agent key already in use: agent ID '134'
Aug 27, 2025 @ 09:43:28.000 wazuh-authd INFO  New connection from 192.168.111.174
Aug 27, 2025 @ 09:43:28.000 wazuh-authd INFO  Received request for a new agent (client02) from: 192.168.111.174
Aug 27, 2025 @ 09:43:28.000 wazuh-authd WARNING  Duplicate name 'client02', rejecting enrollment. Agent '134' can't be replaced since it is not disconnected.
Aug 27, 2025 @ 09:43:31.000 wazuh-remoted WARNING  Agent key already in use: agent ID '133'
Aug 27, 2025 @ 09:43:38.000 wazuh-remoted WARNING  Agent key already in use: agent ID '134'
Aug 27, 2025 @ 09:45:04.000 wazuh-remoted WARNING  Agent key already in use: agent ID '063'
Aug 27, 2025 @ 09:45:15.000 wazuh-remoted WARNING  Agent key already in use: agent ID '063'
Aug 27, 2025 @ 09:45:25.000 wazuh-remoted WARNING  Agent key already in use: agent ID '063'
Aug 27, 2025 @ 09:45:35.000 wazuh-remoted WARNING  Agent key already in use: agent ID '063'
Aug 27, 2025 @ 09:45:35.000 wazuh-authd INFO  New connection from 192.168.111.161
Aug 27, 2025 @ 09:45:35.000 wazuh-authd INFO  Received request for a new agent (client03) from: 192.168.111.161
Aug 27, 2025 @ 09:45:35.000 wazuh-authd WARNING  Duplicate name 'client03', rejecting enrollment. Agent '063' can't be replaced since it is not disconnected.
Aug 27, 2025 @ 09:45:45.000 wazuh-remoted WARNING  Agent key already in use: agent ID '063'
Aug 27, 2025 @ 09:45:59.000 wazuh-remoted WARNING  Agent key already in use: agent ID '185'
Aug 27, 2025 @ 09:48:38.000 wazuh-remoted WARNING  Agent key already in use: agent ID '185'
Aug 27, 2025 @ 09:48:48.000 wazuh-remoted WARNING  Agent key already in use: agent ID '185'

[Olamilekan Abdullateef Ajani]

Hello Felix,

As you have rightly suggested, this happened because it seem you roamed by jumping off different network, and because the interval is almost immediate, the wazuh authd still assumes connection from the previous ID and sees this as a new connection.

You can take a look at the conversation here regarding this https://github.com/wazuh/wazuh/issues/13580. As mentioned, the new registration will not go through if its name is identical to another already registered.

What you can do is add the enrollment force option to the manager, reference here https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/auth.html#force

This would allow you set parameters on how to handle agent configuration when enrolling. If the agent hasn't been disconnected for longer than 1h, it won't replace it but reject the new registration (if names are identical).

OR If the agent was enrolled less than 1h from the new enrollment attempt, it will be rejected (duplicate names).

After applying this, you can use the below command to remove the agent node which are reported as duplicate.
/var/ossec/bin/manage_agents
Once removed, restart the agent and it should work fine.

Please let me know what you find.

Ref:
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/auth.html

[Felix Andorfer]

Hello  Olamilekan,

I have added the configuration as suggested:

  <auth>
    <disabled>no</disabled>
    <port>1515</port>
    <use_source_ip>no</use_source_ip>
    <force>
      <enabled>yes</enabled>
      <disconnected_time enabled="no">0s</disconnected_time>
      <after_registration_time>0s</after_registration_time>
      <key_mismatch>no</key_mismatch>
    </force>
    <purge>yes</purge>
    <use_password>yes</use_password>
    <ciphers>HIGH:!ADH:!EXP:!MD5:!RC4:!3DES:!CAMELLIA:@STRENGTH</ciphers>
    <!-- <ssl_agent_ca></ssl_agent_ca> -->
    <ssl_verify_host>no</ssl_verify_host>
    <ssl_manager_cert>etc/sslmanager.cert</ssl_manager_cert>
    <ssl_manager_key>etc/sslmanager.key</ssl_manager_key>
    <ssl_auto_negotiate>no</ssl_auto_negotiate>
  </auth>

However, I am still receiving the log :

"2025/09/03 12:47:19 wazuh-remoted: WARNING: Agent key already in use: agent ID '148'"

I have tested with <key_mismatch>yes</key_mismatch> and <key_mismatch>no</key_mismatch>, but in both cases the issue persists.

Could you clarify what needs to be changed so that agents can always reconnect when their IP address changes? 

Additionally, when an agent is removed, What exactly is deleted?

Or is there ah way where the agnet doesnt have to be deleted

Best regards,  Felix

[Olamilekan Abdullateef Ajani]

Hello Felix,

I recreated this issue, and I can assure you that the agent reconnected after the IP address changed. Please see attached screenshot for reference.

When an agent is removed (i.e uninstalled, you may stills ee the node present on the dashboard, which means the key is still present on the wazuh server), you may now need to manually remove the agent node from the wazuh server which deletes the agent keys and any other porperties of the agent present. If you do not delete, the agent information is still retained.

I also tested this on version 4.12

Could we do a test with a single agent. Ensure connectivity, track the ossec.log file and change the IP address and see what happens. I also got the agent key already in use, but I am sure this is because of the interruption, but agent remains connected and I am able to send logs.

Please let me know what you find.

[Felix Andorfer]

Hello  Olamilekan,

I did a quick test with my laptop, and it seems to be working. In between the IP changes, I still get the warnings, but that’s fine with me  

What I don’t like so much is that I have to delete the agent. Is there a workaround for this? From what I understand, when I delete an agent, I lose all the inventory data and history associated with it.

If there’s no alternative, thats ok but I’d prefer to avoid deleting agents if possible.

Best regards,  Felix

[Olamilekan Abdullateef Ajani]

Hello Felix,

Based on my test, you should not get so many warnings and so much information from the change. Let me get a second opinion on this and revert with my findings.

Thank you

[Felix Andorfer]

Hello Olamilekan,

Did you find anyting out 

Best regards,  Felix

[Olamilekan Abdullateef Ajani]

Hello Felix,

I apologize for not sharing feedback earlier, and I appreciate your patience. Please note that this has been escalated upward to the team and it is getting traction. Feedback will be provided shortly.

Thank you

[Olamilekan Abdullateef Ajani]

Hello Felix,

One thing I did not ask you about is how you enrolled the agent. Perhaps you did so using the IP address you had at the time, so that means when the IP address changes, it fails. Which rightly explains the current situation.

We need to check how the agent is registered in the client keys file. You can find more information about this below:

https://documentation.wazuh.com/current/development/client-keys.html
https://documentation.wazuh.com/current/user-manual/agent/agent-enrollment/enrollment-methods/index.html

A quick example is if you see something like this.

002 dbserver 10.0.1.2 363a99a6e9c9a8b6bb766d676453538e0cb20162f84b36472d99cfbef4928440

It is recommended to conduct the test without specifying an IP address, as outlined below:

002 dbserver any 363a99a6e9c9a8b6bb766d676453538e0cb20162f84b36472d99cfbef4928440

Please let me know what you find.

[Felix Andorfer]

Hello Olamilekan,

I registered all agents via GPO, which deploys an MSI with a custom .mst file.

 

The client.keys entry is:

"635 Client196 any  bb8a28997c6c3964eacb3d32308072f6661f567a41105b2b0b09f1a82331b937"

Since all clients use DHCP, I did not specify an IP address. Both the ADDRESS value and the AUTHD_SERVER value are set to the Wazuh server.

If you need any further information, please let me know.

Best regards,
Felix

[Olamilekan Abdullateef Ajani]

Dear Felix,

Thank you for the feedback, I will review this and share it with the team. I will give you an update as soon as possible.

Best regards

[Olamilekan Abdullateef Ajani]

Hello Once again Felix,

I received feedback from the team and one of the things mentioned is that, this is an expected behavior if a new connection is received, the IP changes, the original connection is interrupted.

That being said, I believe your worry is about agent removal/replacement, It would be best to make use of the default force configuration as against tweaking it just as you have done before so as to not force any replacement. Then you may configure the overtake time to avoid connection time management error between the agent and the wazuh manager.

During that "undocked" period from the manager, the agent will be "disconnected" from the manager perspective because it won't be receiving events and officially "disconnected" after 10 minutes.

Please make these changes and let me know.