Problems after hibernating/standby

[rscott101]

Having a lot of issues with Windows Client 16.3.0.220, connecting to a V16 server.

Users hibernate or suspend at the end of each day and when they start up the next day, they show as connected in other 3cx clients, but can't receive incoming calls. They need to force a re-register, either by quitting the app or using the re-register option.

Is there any way of forcing the client to automatically reregister at regular intervals?

 

[ChrisC_3CX]

First off, just so that we get a better picture of your current setup, could you provide the relevant information mentioned here: https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

Regarding Re-registration intervals, do note that it is set to 120 seconds, so it should re-register automatically after 2 minutes tops. Is this not the case? Also, you mention having issues with Incoming calls, is that to say that outgoing calls work without having to re-register or re-launch the app?

 

[rscott101]

Sorry - missing details:-

• 3CX Version, Standard Enterprise 16.0.9
• Server OS, Debian 9
• Is the 3CX Server Hosted and where? Own VMware server.
• IP Phone Make/Model/Firmware, 3cx windows app, 16.3.0.220
• Provisioning Method: Local / VPN / STUN / SBC n/a
• Trunk Provider or Gateway Make/Model orbtalk, but happens on internal calls.
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

PCs are resumed from standby or hibernate by 9am but incoming calls still aren't working by 11am to some, even though they appear as online in other users apps.
Believe it also affects outgoing calls but 99% of our calls are inbound, so very little evidence to test.

 

[ChrisC_3CX]

Do you happen to be running VPN clients on the affected PCs? If yes, it might be that the 3CX Windows App connects before the VPN client establishes the VPN connection. If not, are there any specific commonalities in regards to configuration of the affected PCs, such as, network config, same antivirus/security software, group policies, logon scripts, or anything else that might be contributing to the issue?

 

[rscott101]

All machines are running Crowdstrike Falcon security software, Cisco Anyconnect VPN client and the same GPOs, login scripts, etc. They're all < 3 month old identical laptops.

The public address of the 3cx server isn't routed via the VPN, so traffic shouldn't be affected by the establishment of the VPN. I believe 3cx is connecting first, then the VPN shortly afterwards, for every user, but not every single user has the registration issue.

Are there any client side logs I can check for this?

 

[ChrisC_3CX]

Before investigating further, could you please try the following:

1. Completely uninstall the VPN Client from a PC that is affected by the issue. (Maybe after the user is done for the day)

2. Make sure the 3CX Windows App still receives and makes calls and then Hibernate the PC.

3. Turn the PC back on the next day and wait for at least 2-3 minutes. Try the 3CX Windows App again to check if the issue persists. Once you have the results, you can of course re-install the VPN client.

Note: Changes in network interfaces while the 3CX Windows App is running is known to cause issues especially with registration and that is why when using a VPN client, you will have to ensure that the VPN connection has been established before launching the 3CX windows App.

Please try the above and let us know what happens.

 

[rscott101]

I can try that. I have a spare PC I can use for this. But surely if it registers every 120 seconds, it should only be a very brief interruption after the VPN connects?

Given that the 3cx app is already running when the machine resumes so auto-connects but the VPN connection is a manual task, the VPN is always going to connect after the app, so expecting users to remember to restart 3cx may be a challlenge...

 

[ChrisC_3CX]

But surely if it registers every 120 seconds, it should only be a very brief interruption after the VPN connects?

Registration expiration is indeed set to 120 seconds, however, simply having the client attempt a SIP re-registration after changes in the Host's network interfaces have occurred is not enough. You will have to re-launch the client completely or use manual re-registration. The reason the manual "re-register" action works is because it does not only refresh registration, rather, it tears down the connection completely, including the 3CX tunnel connection, and re-establishes it.

Having the VPN connect first will most definitely cause problems so I think you will have to figure out a way to have it connect the other way around.

 

[rscott101]

Registration expiration is indeed set to 120 seconds, however, simply having the client attempt a SIP re-registration after changes in the Host's network interfaces have occurred is not enough. You will have to re-launch the client completely or use manual re-registration. The reason the manual "re-register" action works is because it does not only refresh registration, rather, it tears down the connection completely, including the 3CX tunnel connection, and re-establishes it.

Having the VPN connect first will most definitely cause problems so I think you will have to figure out a way to have it connect the other way around.

The only way of forcing them to start in the other order is to stop the 3cx client auto starting with Windows and have the users manually launch it after they start the VPN.

Not sure that'll work, given our typical user unfortunately.

Presumably the same registration issue happens if someone switches from a wired to wireless network connection, or even between wireless ones?

 

[ChrisC_3CX]

Presumably the same registration issue happens if someone switches from a wired to wireless network connection, or even between wireless ones?

You might think that but it's actually quite different as all involved network interfaces would have already existed when the 3CX Windows App was launched. Connecting an SSL VPN client will have a new virtual interface seemingly appear out of nowhere so the equivalent would be something like physically replacing the old network adapter with the new one while the 3CX Windows App is running.

Pressing "Re-register" will also try to rebind to the network adapters and this is one of the reasons why it actually manages to reconnect when such a situation occurs.

 

[rscott101]

You might think that but it's actually quite different as all involved network interfaces would have already existed when the 3CX Windows App was launched. Connecting an SSL VPN client will have a new virtual interface seemingly appear out of nowhere so the equivalent would be something like physically replacing the old network adapter with the new one while the 3CX Windows App is running.

Pressing "Re-register" will also try to rebind to the network adapters and this is one of the reasons why it actually manages to reconnect when such a situation occurs.

The Anyconnect client configuration we're using doesn't use SSL. It's IKEv2 and doesn't add/remove any network adapters when it connects.

There's a "Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64" network adapter added when the client is installed and that is always present in the system. It's no different from a Wireless adapter in that respect.
Establishing a VPN connection allocates that interface an IP address, adds routing to selected private subnets and changes the DNS servers used. It doesn't affect the routing of traffic to the 3cx server.

Seems odd that the client thinks it's connected to the server though. If the tunnel has been disrupted by the connecting of the VPN, then surely the client should be checking for that and either reregistering or displaying an error?

 

[NickD_3CX]

Seems odd that the client thinks it's connected to the server though. If the tunnel has been disrupted by the connecting of the VPN, then surely the client should be checking for that and either reregistering or displaying an error?

Yes, but it doesn't.

Our suggestion on what you should check still stands as is: uninstall any VPN client before the PC hibernates and make sure 3CX can make calls, then wake it up next morning and check if you can make/receive calls, within 2-3 minutes of waking it up.
This should at least be an indication if there is something with the VPN clients that may be causing this.