Working from attempt #3, a question followed by a comment…
Let me see if I am following you on this. You are attempting to reroute SSH through HTTP on your remote/home/server end on port 50100. You are then initiating an HTTP tunnel from the client/work end from 12345, locally, to 50100 on the remote/home/server end. Finally, you are creating a tunnel from port 4000, locally, to port 3689 on the remote/home/server machine. Am I understanding this correctly?
This seems unduly complicated to me. Forgive my ignorance of the HTTP proxy, but why not simply create the HTTP tunnel directly between the client/work end and the ssh port on your remote/home/server? (e.g. htc -P myproxy -F 12345 my.ip:22. Then it simply becomes a matter of routing all of the other requests through the SSH tunnel.
Next, it is not necessary to create a bogus DAAP port locally. In fact, it may be counter productive. Unless you have other DAAP shares on the local subnet, simply reroute that port to the remote/home/server. (e.g. ssh -l [email protected] -N -f -L 3689:my.ip:3689 — assuming the machine at the remote/home/server is the same as that running mt-daapd. If using NAT, you will want to substitute the internal address for the server in port forwarding parameter (e.g. -L 3689:internal.address:3689).
Your recent post also neglected to mention your handling of the mDNS beacon. You will need to republish the remote/home/server beacon to the client/work subnet. This is accomplished by issuing a command such as mdns -R 127.0.0.1 squeal “shareName” _daap._tcp. 3689 & on the client/work local end (or using one of the GUI utilities mentioned in the document wiki. In fact, you should basically be able follow the directions in that document verbatim once the SSH connection is initiated through the HTTP tunnel.
Herman