Do you have a nsh proxy setup? is the client side secure file setup to use it?
Yes my NSH proxy on the BLApp server is working fine.
I can 'NSH Here' to any of my servers on this side of the Socks Proxy, but any I try to get to behind the Proxy fail.
It not a Firewall issue as their are no drops on any of them.
I should note that I have no problem using the Live browse function in the GUI.
Can you resolve the target hostname from your client?
I thought it resolved the IP based on the OM Name?
From my NSH client session
wlgl-05760% cd //tst.intdev.clear.net.nz
cd: connection timed out: //tst.intdev.clear.net.nz
wlgl-05760% cd //tst.intdev
cd: remote host is unknown: //tst.intdev
So this would mean my NSH client is using my PC's DNS to resolve hostname...however 'NSH Here' should be using the IP or the OMNAME shouldn't it?
I also can't get to the proxy using NSH from my PC client (which might be the source of all my problems)?
However I can from an NSH session on the BLApp server.
i believe it should go:
nsh client -> nsh proxy -> socks proxy.
no matter how you launch nsh, it's still using the nsh binary on your client, and i believe resolving using your client's dns. there's an env variable you can set to force name resolution on the appserver i think - it's BL_SRP_INFO=true (i think) - i can check that one later tonite if it doesn't work.
Hmm, if thats an env for my client then no joy :-(
I seem to recall that release 265 mentioned a fix relating to servers behind the proxy not functioning correctly...I'll go have a read.
If you could check it later tonight I'd appreciate it.
I have a note stating:
NSH w/ or w/o the proxy relies on name resolution to occur on the client. Therefore, if your client system cannot resolve the IP of the target NSH will fail to connect, regardless of whether the application server can resolve the hostname.
This can be overcome by setting the environment variable/setting BL_SRP_INFO=true on the NSH client. This can be done in /etc/profile or .profile on *nix, or in the System | Environment Variables in Windows.
I do remember an issue like what you are talking about for 7.5 or 7.6.. so a hotfix might be worth it..
I'm thinking that maybe my Client --> NSHProxy setup is incorrect.
my setup is:
CLIENT --> NSHProxyServer --> TargetServer
The following are test results:
NSH from CLIENT-->NSHProxyServer - Works (I'm thinking this isn't using the NSHProxy.)
NSH from NSHProxyServer --> TargetServer - Works
NSH from CLIENT-->TargetServer - FAILS
Could you provide an example of a working secure file?
I think maybe I'm missing something in mine.
I discovered that this problem was an incorrectly onfigured NSH Client.
I was missing the "appserver_protocol=ssoproxy" property in my C:/WINDOWS/rsc/secure file.
You can configure the SOCKS proxy to do the name resolution. This is working fine at a number of customer sites and doesn't require any DNS set up on the client side (or even on the App Server). The client passes the "name" to the NSH proxy and the NSH passes the name to the SOCKS proxy. The SOCKS proxy attempts to resolve the name to an IP Address.You will actually see the "name" being passed in the sockd.log file if using dante.
This is especially useful if you have a number of networks with overlapping IP addresses. As long as the names are unique and the routing rule points to the right SOCKS they will correctly route and resolve.