cancel
Showing results for 
Search instead for 
Did you mean: 

Upgrade of Client from 8.0 to 8.2 - status 26 - Client Server handshaking failed

SYM-AJ
Level 5

I have upgraded the Ops Center, Master Server and a number of clients in a fairly small NBU environment from 8.0 to 8.2 - all is well.

I am attempting to upgrade the remaining clients (DMZ based) but am having an issue when attempting the upgrade to 8.2.  As these are at 8.0 there are currently no certs installed - obviously 8.2 requires certs.  The clients are currently functioning perfectly with the 8.2 master.

I have confirmed that ports 1556, 13782 and 13724 are open in the firewall between master and client, and also HTTPS traffic is allowed.

When I start the client install/upgrade I am selectig CUSTOM, checking all the values and after system names screen I get an error "Could Not Determine Master Server Certificate Mode".  This details command status 26, The external CA usage information could not be retrieved.  Exit status 26:  client/server handshaking failed.

Is there something else I am missing here in terms of firewall requirements ?

Security level on Master is set to MEDIUM.

Any NBCERTCMD options I try from the client fail - thinking this must be firewall......

BPTESTBPCD is good, BPCLNTCMD is good.

Thoughts ??

AJ.

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

OK - I got confirmation from the network team as to what they did to get this working.....

The correct ports were allowed, as was https - but comms could ONLY be initiated by the Master Server.  They changed the rule to allow bi-directional initiation of comms on these ports and all upgrades went perfectly.

So it looks like during the upgrade process, when it is requesting certs, the client is initiating comms (not sure on which port(s)) - and therefore the firewall must allow both the master and the client to initiate communications.

The ports we have allowed are 1556, 13782, 13724 and https (443).

If someone wants to mark this as the soluton I would appreciate it - as I was 'shot' last time I marked one of my own answers as the solution......

Thanks for all the input.

AJ

View solution in original post

11 REPLIES 11

davidmoline
Level 6
Employee

From what you are saying, you have all the required ports open (1556 & 443). Trying a nbcertcmd on a lab system I have indicates it uses port 1556 for the connection (I actually thought iit used https

Is any NAT involved - this could be causing problems.

Can you enable firewall logging to if the packets are received or blocked?

Other thing to check would be the install logs - there should be one called ExternalCertificateOp.<timestamp> on the client.

Agreed the problem appears to be firewall related.

 

Another thought - does the CA certificate for the master use a short name? And are you specifying a FQDN from the client - this might cause problems also (you may need to add a host mapping to the master server or use the short name on the client) - see example output below

The target server master.lab.ad could not be authenticated.
The server name does not match any of the host names listed in the server's certificate.
Names listed in the server's certificate are:
DNS:MASTER
The external CA usage information could not be retrieved.
EXIT STATUS 8509: The specified server name was not found in the web service certificate

 

See attached the logs as noted.  I looked through these already but can only really see the following of interest:

NBClientCURL::performCurlOperation: Failed to perform operation: SSL connect error

I did see that we appear to be connecting on 1556 as did you, although I did expect https (443).  Not being a firewall expert I am at a bit of a loss now.....

Thanks,

AJ

I'm unable to determine the problem with the current information. 

Can you provide the output from "nbcertcmd -getCACertificate" from the master server (feel free to obsfucate the fingerprint, but please leave the server name intact). And the entire contents of  the  C:\ProgramData\Veritas\NetBackup\InstallLogs filder from the client.  Also, what is the exact message you are seeing in the installation dialog.

Another option may be to continue the installation of a client without obtaining the CA or client certificate, and then once NBU is installed manually try to get the CA and client certificate (obviously this risks loss of ability to backup the client while you resolve certificate issues). This way may provide a better environment to debug the problems you are having during the installation.

As for firewall connections, these seem to be okay, I can see multiple connections to the master (s00bkp001.amber.local) on port 1556. I suspect that the tool is using the PBX port to redirect https traffic (similarly to how other NetBackup traffic is now tunnlled via PBX).

Attached are ALL the logs from an install attempt and also a document with screenshots showing output from the nbcertcmd on the master server and a few other details also.

It should be noted that I have updated a number of other clients to 8.2 successfully - however these don't reside behind a firewall hence my thoughts pointing to firewall related issues (although you say all communications looks good from the logs seen to date).

I do not want to continue without certs due to the reason you mention - I will lose the ability to backup the client until the certs issue is resolved.

I have requested the network team to inspect the firewall logs during the time of the installation attempt and advise what activity they are seeing and if any packets are being dropped.

Appreciate your input,

AJ

Please ignore the above.

I just got word back from the network team who advised me they only just updated the firewall rules to ensure the required ports and HTTPS were allowed.  I was advised this was all in place a number of days ago......

I re-tried the upgrade and all worked just fine !!

So - firewall it was.......

Thanks for the input,

AJ

Hamza_H
Moderator
Moderator
   VIP   
Hi, thanks for the update this could help other persons experiencing the same issue
I have a question about the https port, so as @davidmoline said, We all thought the certificate f
was through 1556, so you are saying if you block 1556, it doesnt work?
And before this, did you try a telnet between the client and the master? What was the result ?

Thanks

Based on what I've seen in my lab (within a subnet) all that is required to install the client (and deploy the certificate) is port 1556. Without that port available NetBackup wont work anyway. 

If 1556 is blocked, then I think the install will try other ports including 13720 & 443 (https), although I'm not sure how useful this will be. I'm also not sure if https is required in addition to 1556 during norml operations.

Just to be clear - 1556 wasn't blocked.  The backup (using the old 8.0 client) continued to work after the 8.2 upgrade of the master/media.

I will double check with the network guy this morning what ports he is allowing in the new rule - I am guessing he simply added the https to the exisitng ports (1556/137xx).

I did telnet previously from the client to the master on the 1556 and 137xx ports - all good.  However I could not telnet on 443.

I'll update when I hear back from the network team.

Thanks for the input,

AJ

OK - I got confirmation from the network team as to what they did to get this working.....

The correct ports were allowed, as was https - but comms could ONLY be initiated by the Master Server.  They changed the rule to allow bi-directional initiation of comms on these ports and all upgrades went perfectly.

So it looks like during the upgrade process, when it is requesting certs, the client is initiating comms (not sure on which port(s)) - and therefore the firewall must allow both the master and the client to initiate communications.

The ports we have allowed are 1556, 13782, 13724 and https (443).

If someone wants to mark this as the soluton I would appreciate it - as I was 'shot' last time I marked one of my own answers as the solution......

Thanks for all the input.

AJ

jnardello
Moderator
Moderator
   VIP    Certified

I would generally recommend the firewall rules be set for bi-directional anyway just because you never know what users are actually going to throw onto these clients. If they happen to install something with a database agent, those are all client-initiated connections which will fail if the firewalls are blocking those connections.

Plus if the client cannot initiate, that means no customer-triggered restores of their own files. 

Food for thought.