05-26-2015 04:13 AM
Hello,
we have upgraded from 7.5.0.6 to 7.6.1, also the jnbSA on remote site. The old one was installed on a 32bit Citrix environment and was working properly. The new jnbSA is installed on a different host (64bit) which is on a different network segment. So we guess the root cause for this issue is a firewall problem. Unfortunately we are only man in the middle and the Citrix team as well as the security team is unable to determin the root cause of the problem. How can we help them to get the things right?
Some facts:
Old Citrix host:
C:\>nslookup i68448v1.sbb.ch
Server: vaizk160.dyc-adminlan.ch
Address: 53.250.16.141
Non-authoritative answer:
Name: i68448v1.sbb.ch
Address: 172.28.128.21
C:\>ping i68448v1.sbb.ch
Pinging i68448v1.sbb.ch [172.28.32.159] with 32 bytes of data:
Reply from 172.28.32.159: bytes=32 time=5ms TTL=249
Reply from 172.28.32.159: bytes=32 time=4ms TTL=249
Ping statistics for 172.28.32.159:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 5ms, Average = 4ms
Control-C
^C
C:\>tracert i68448v1.sbb.ch
Tracing route to i68448v1.sbb.ch [172.28.32.159]
over a maximum of 30 hops:
1 1 ms 3 ms 3 ms 53.250.16.132
2 1 ms 1 ms 1 ms 53.250.16.11
3 2 ms 2 ms 2 ms uaila30vl055.t-systems.ch [53.250.112.194]
4 3 ms 2 ms 3 ms sraizk1000vl30.t-systems.ch [53.250.18.6]
5 24 ms 4 ms 4 ms sraila1001vl0100.t-systems.ch [53.250.100.3]
6 5 ms 4 ms 4 ms fvbbrz0010vl0830.t-systems.ch [53.250.17.24]
7 9 ms 11 ms 11 ms i68448v1.sbb.ch [172.28.32.159]
Trace complete.
New Citrix host:
C:\Windows\System32>nslookup i68448v1.sbb.ch
Server: vaizk160.dyc-adminlan.ch
Address: 53.250.16.141
Non-authoritative answer:
Name: i68448v1.sbb.ch
Address: 172.28.128.21
C:\Windows\System32>ping i68448v1.sbb.ch
Pinging i68448v1.sbb.ch [172.28.32.159] with 32 bytes of data:
Reply from 172.28.32.159: bytes=32 time=1ms TTL=251
Reply from 172.28.32.159: bytes=32 time=1ms TTL=251
Ping statistics for 172.28.32.159:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
Control-C
^C
C:\Windows\System32>tracert i68448v1.sbb.ch
Tracing route to i68448v1.sbb.ch [172.28.32.159]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 53.250.16.169
2 1 ms 1 ms 1 ms sraizk1000vl30.t-systems.ch [53.250.18.6]
3 2 ms 2 ms 1 ms sraizk1001vl0100.t-systems.ch [53.250.100.5]
4 1 ms 1 ms 1 ms fvbbrz0010vl0830.t-systems.ch [53.250.17.24]
5 1 ms 1 ms 1 ms i68448v1.sbb.ch [172.28.32.159]
Trace complete.
PBX log:
12:41:54[0]root@i68448:log/VRTSpbx# /usr/openv/netbackup/bin/vxlogview -p 50936 -o 103 -t 00:00:05
05/26/15 12:43:04.625 [Info] PBX_Manager:: handle_input with fd = 8
05/26/15 12:43:04.625 [Info] PBX_Client_Proxy::handle_input read returned: EWOULDBLOCK
05/26/15 12:43:04.802 [Info] PBX_Client_Proxy::parse_line, line = ack=1 From 195.141.158.126
05/26/15 12:43:04.802 [Info] PBX_Client_Proxy::parse_line, line = extension=vnetd From 195.141.158.126
05/26/15 12:43:04.802 [Info] hand_off looking for proxy for = vnetd
05/26/15 12:43:04.802 [Info] is_accepting about to return true
05/26/15 12:43:04.802 [Info] Client Expects an ACK, sent one.
05/26/15 12:43:04.802 [Info] Proxy found.
05/26/15 12:43:04.802 [Info] PBX_Client_Proxy::handle_close
05/26/15 12:43:05.438 [Info] PBX_Manager:: handle_input with fd = 8
Telnet i68448v1.sbb.ch 1556 is going through on both systems. Locally started jnbSA is working fine.
We appreciate any ideas!
Thanks, Matthias
05-26-2015 04:44 AM
BTW: Is 1556 the only port which is involved? As far as I can read from docs it is.
05-27-2015 12:21 AM
jnbSA requires ports tcp/1556 and tcp/13724, both bi-directional.
05-27-2015 06:43 AM
The fact that you are allowed to perform traceroute all the way tell me that do don't have a firewall in-between.
I am however wondering of the following:
Non-authoritative answer: Name: i68448v1.sbb.ch Address: 172.28.128.21 Pinging i68448v1.sbb.ch [172.28.32.159] with 32 bytes of data: Reply from 172.28.32.159: bytes=32 time=1ms TTL=251
Seems there is somthing with the DNS record.
Port 1556 open bi-directional is enough for the GUI to work.
06-04-2015 12:54 AM
Thanks for your help but the problem has changed. We are some steps further and it looks like the newly installed NBU 7.6.1 Java GUI uses the wrong certificate to authenticate to the Master Server. In the log (/usr/openv/netbackup/logs/bpjava-msvc/root) I can see:
not_ok
15:19:10.863 [66715856] <16> session_dispatch: Request count = 0 tag = 510
15:19:10.864 [66715856] <2> populateCertificatePath: Certificate to be used for SSL [/usr/openv/var/vxss/credentials/i68448e1]
15:19:10.864 [66715856] <4> command_SECURE_CHANNEL_INIT: Using certificate [/usr/openv/var/vxss/credentials/i68448e1] and Responding SECURE_CHANNEL_PROCEED.
15:19:11.098 [66715856] <4> session_secure_lookup: Initiating SSL Accept
15:19:11.098 [66715856] <2> populateCertificatePath: Certificate to be used for SSL [/usr/openv/var/vxss/credentials/i68448e1]
15:19:11.151 [66715856] <16> VssAccept: (../../libVnbat/vss_auth.cpp,2226): vrtsAtSecConnAcceptEx returned FAILURE
15:19:11.152 [66715856] <16> tls_accept: io.c.3291: VssAccept( ) failed
15:19:11.152 [66715856] <16> session_secure_lookup: FAILED!! to accept SSL connection from client.Possibly this could be caused by a network blip, JavaGUI unable to authenticate X509 certificate that was presented OR user of JavaGUI interactively selected __NOT__ to trust X509 certificate presented.
15:19:11.152 [66715856] <16> session_dispatch: session_secure_lookup FAILED!!! fd = 0
15:19:12.153 [50725166] <16> poll_listen: can't find file descriptor in polling table
15:19:12.153 [50725166] <4> bpjava-msvc: NEW_LOG closing debugFD and seting NB_INVALID
Locally started the same Java GUI version looks like this:
ok
15:27:14.596 [50725328] <16> session_dispatch: Request count = 0 tag = 510
15:27:14.597 [50725328] <2> populateCertificatePath: Certificate to be used for SSL [/usr/openv/var/vxss/credentials/i68448v1.sbb.ch]
15:27:14.597 [50725328] <4> command_SECURE_CHANNEL_INIT: Using certificate [/usr/openv/var/vxss/credentials/i68448v1.sbb.ch] and Responding SECURE_CHANNEL_PROCEED.
15:27:14.871 [50725328] <4> session_secure_lookup: Initiating SSL Accept
15:27:14.871 [50725328] <2> populateCertificatePath: Certificate to be used for SSL [/usr/openv/var/vxss/credentials/i68448v1.sbb.ch]
15:27:14.889 [50725328] <4> tls_accept: io.c.3300: SSL Channel established for fd[0]
15:27:14.889 [50725328] <4> session_secure_lookup: SSL Connection Accepted!
15:27:14.948 [50725328] <16> session_dispatch: Request count = 1 tag = 118
15:27:15.383 [50725328] <16> session_dispatch: Request count = 2 tag = 101
15:27:15.435 [50725328] <16> command_LOGON_TO_MSERVER: putenv(BPJAVA_MASTER_IPC_STRING=) failed
15:27:15.459 [65142984] <16> isVxssActive: authentication determination failed, assume none required: (193) VxSS authentication is requested but not allowed
The name I used was i68448v1.sbb.ch in both cases. The error shown is 526 at the Java GUI. I tried different names and IP addresses in the "Host name" field but always the same result.
Question: Where is the (wrong) information stored? How does Java handle the name?
Thanks for a hint!
Matthias
06-04-2015 08:46 AM
When you attempt to connect you should get an error box the says something to the effect that the master server named i68448e1 does not match i68448e1.mydomain.com or some such. Can you post a snapshot of that error?
06-05-2015 01:02 AM
06-05-2015 03:22 AM
If the PBX is not running start it (/opt/VRTSpbx/bin/vxpbx_exchanged start). If it is running stop it and then restart it.
If UAC is enabled on the desktop make sure you right click and use "Run as administrator".
06-05-2015 04:25 AM
Thanks for your hints!
Telnet to the Master Server on port 1556/13724 is fine, same as traceroute. PBX is surely running which is shown in the log above. A restart of PBX was done many times. UAC is enabled but I have the appropriate rights.
A route from Citrix host where the Java GUI is installed to the Master Server Backup Interface does NOT exist. Therefore we have an entry in the local hosts file:
172.28.32.159 i68448v1.sbb.ch #Netbackup 7.5 SBB Cluster
This ensures that the Citrix Host is able to communicate with the Master Server BUT somewhere the name resolves to the correct interface which is called i68448e1 which is the first node of the cluster but the wrong host name. This is shown in the Java log above.
Where is the name translated/resolved?
Why the Java GUI 7.6.1 is not behaving like the old 32bit version of Java GUI 7.5.0.6 which was working before?
Thanks for all your precious hints
Matthias
06-05-2015 05:38 AM
Try flush DNS on Citrix host where the JAVA console is installed
and
/usr/opev/nebackup/bin/bpclntcmd -clear_host_cache at master server
and try to login again
06-05-2015 06:54 AM
Appropriate rights and "Run as administrator" do not equate in UAC. Right click the icon and select "Run as Administrator".
07-09-2015 01:51 AM
I have an open case 09093398 which is quite similar and related to this one. The case is still open and therefore I stopped responding on this one. I get back maybe with a solution to this one soon.
08-17-2015 01:32 AM
Hi Matthias
A few days ago I had the Problem that the Java GUI only opened the BAR GUI. The Problem was that on that Windows Host on the ./NetBackup/logs/admin folder the user "everyone" with "full access" was missing.
http://www.symantec.com/docs/TECH158208
Do you use NBAC?
How does your auth.conf file looks like?