A Forum reader recently asked:
"I'm trying to set up Designer (version 2.1.1) to access my identity vault over a tunnel. I've setup my laptop to listen on localhost:524... i.e. laptop:524 ---> 9524:shell host ---> 524:vault
The tunnel works great. I can access ndsd using iManager workstation with no problems. I can create a new project using the import functionality and everything gets imported as I expect.
However... comparing and deploying do not work as I expected. For example if I import my project and perform a comparison Designer tells me everything is unequal. Everything on the eDirectory side appears blank.
Has anyone used Designer over a tunnel before?"
And here is the response from Aaron Burgemeister ...
Most protocols work beautifully w/SSH tunnels and they are a great way to reach places prohibited by firewalls, policies, etc. The problem with some protocols (NCP is the one that comes to mind) is that when you do some operations the client is "smart" enough to know exactly
what the IP address of the destination box is. For example, when connecting initially you give it your local IP address, which then forwards through to the eDirectory box, which makes the connection and sends data back.
That data, though, includes referrals to boxes in eDirectory. When you want to update/compare a driver that is server-specific, it is very likely that your Designer box is trying to make a connection directly to that server. A quick way I check this (on Linux) is with the following command:
netstat -anp | grep 'SYN_SENT'
This shows all of my attempted connections which have not been responded-to at all from the destination (server).
If you are on a 10.x.x.x network connecting to a 192.168.x.x network across the Internet, you will see a line trying to connect (from your workstation) to
192.168.x.x which should not be happening (the connection from Designer is being made to localhost, after all).
There are some options here:
1. Assign an aliased IP address for your eDirectory servers
to your local machine.
2. Forward those specific sockets to the destination. For example assign 192.168.1.100 (your server) to your box:
ip addr add 192.168.1.100 lo:1
ifconfig lo:1 192.168.1.100
This creates an alias ('1') to the localhost adapter. You can add a lot more ('2', '3', etc.) to expand on this.
3. Once this is done, set up another tunnel from your own 192.168.1.100 to 192.168.1.100 on the remote side.
You'll probably need to be root at this point unless you
have capabilities working on your box so that you don't need to be root to bind port 524. In theory you could probably do some nasty hacking w/NetFilter/iptables as well, but that's uglier.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.