Hi Kamil,

Can you check the cvfwd.log on the CS, MA and the Client for any related errors?
- Also check CVD.log on the Client.
 

It might be worth validating the FwConfig.txt in Base folder of the client has been updated with the FW rules correctly.
Run a “netstat -ano | findstr 840*” on the Client to see the status of the connections.

Also, is there any Firewall or AV Software on the Client that could interfere with a persistent tunnel?

Best Regards,

Michael

Hi @Kamil W,

I’d suggest checking the following on the client:

• Any errors in cvfwd.log or CVD.log
• Is the FwConfig.txt in the Base directory updated with the firewall rules
• Check the output of “netstat -ano | findstr 840*” for network connections status
• Any AV/Firewall on the Client that could interfere with a persistent tunnel? 

Checking the cvfwd.log on CS/MA may also be useful.

Best Regards,

Michael

Hi @Kamil W ,

I’d suggest checking the following on the client:

• Check the cvfwd.log and CVD.log for any errors
• Is the FwConfig.txt in /Base/ updated with the FW rules?
• Check the status of connections with: “netstat -ano | findstr 840*”
• Does the client have any AV/Firewall that could interfere with persistent connections?

It may also be worth checking cvfwd on the CS/MA too.

Best Regards,

Michael

Hi @Kamil W 

I’d suggest checking the following on the client:

Check the cvfwd.log and CVD.log for any errors
Is the FwConfig.txt in /Base/ updated with the FW rules?
Check the status of connections with: “netstat -ano | findstr 840*”
Does the client have any AV/Firewall that could interfere with persistent connections?
It may also be worth checking cvfwd on the CS/MA too.

Best Regards,

Michael

​

Is CVD reporting the request for ifind to launch on the client? Is the filescan log reporting anything in that timeframe? 

I’d suggest checking the following on the client:

• Check the cvfwd.log and CVD.log for any errors
• Is the FwConfig.txt in /Base/ updated with the FW rules?
• Check the status of connections with: “netstat -ano | findstr 840*”
• Does the client have any AV/Firewall that could interfere with persistent connections?

It may also be worth checking cvfwd on the CS/MA too.

Best Regards,

Michael

I’d suggest checking the following on the client:

Check the cvfwd.log and CVD.log for any errors
Is the FwConfig.txt in /Base/ updated with the FW rules?
Check the status of connections with: “netstat -ano | findstr 840*”
Does the client have any AV/Firewall that could interfere with persistent connections?

It may also be worth checking cvfwd on the CS/MA too.

Hi @Kamil W 

You have shown that comms between client and MA/CS are working using ports 8400 and 8403 to the IPs shown.

Does the MA/Client have multiple interfaces?

Have Data Interface Pairs been configured on the client/MA?

Are there network routes configured in the Commcell instructing the client to use some other route that isn’t correct?

Thanks,

Stuart

Hello Guys,

Thanks for your reply.

I’ll try to get back to you with answers ASAP.

Rgds,

Kamil

Hi Guys,

I just spoke to the Customer.

They uninstalled the client locally and the installed it again using the same client name.

Everything is working now.

Rgds,

Kamil

Hi guys,

It looks like problem reapeared but on different client machine.

CVping is connecting from MA and CS to client and vice versa on ports 8400 and 8403.

Reinstalling software, setting up DIP or setting one way firewall didnt help.

MA and CS have only one interface.

Any help much apriciated.

@Dawid , how does check readiness report back?  Run a check readiness and let me know if you see any errors.

https://documentation.commvault.com/11.23/essential/129992_checking_readiness.html

@Mike Struening didn’t realize check readiness img is missing. It meant to be there in the first place.

Perfect, @Dawid thank you!

The -5 error generally indicates there is an issue with the client certificate.  Can you revoke and renew the certificate to that client?

Also, would you mind uploading the logs for this client, MA, and CS?  I want to have someone review them on our side, though the above will get you working again.

Mike is correct on this. I was able to get passed this error by revoking cert then stopping starting local client with command line. and resuming on commcell console.

On a side note, we are working with dev to clean up the scenario for these issues.  No ETA, but our mentality is that you shouldn’t have to manually intervene.

Hello Folks,

I have been also facing same issue and restarted Network daemon service. Post restart this issue is resolved now.

I hope this will help you !!