Thank you for explaining the philosophy of the HTTP tunnel. The requirement of a client and server scheme makes some sense, but really only adds one layer to the attempt.
That said, I think we are in agreement that the SSH tunnel is the way to go. It will be possible to plumb all of the services through that conduit. My only concerns are your previous mention that your home ADSL line is somewhat bandwidth constrained and the potential for latency issues due to routing the DAAP and mDNS packets through an SSH pipe, which is, in turn, itself crammed through an HTTP tunnel. However, it should be feasible with the only issue being degree of reliability.
I failed to mention that I did try with port 3689 too. When it first failed, I tried 4000, thinking that ssh may short circuit port forwards of “3689:localhost:3689” since there are situations where that would be meaningless.
I can provide some assurance that no short circuit will result from forwarding a standard local port to a standard remote port will occur. This is the technique of which I make use on an almost daily basis.
I do have a concern regarding the formula you are utilizing. Perhaps I am misreading your intent, but where is the “localhost” machine? Is it truly local to your work subnet or is it local to the network on the remote end? The machine name/number in that parameter should be the address of the remote server. IOW, the -L switch is telling SSH to reroute the local port 3689 to port 3689 on the remote machine with the address provided in the parameter.
Finally, your original SSH commnd contained the -p switch. I am not sure that is correct as implemented. The -p switch is for connecting to non-standard ports on the remote end. I think you are wanting to bind (-b switch) SSH to port 12345 on the local machine. Once the HTTP tunnel is established between the networks, you will want to use the standard SSH port (22) on the remote end. The trick is rerouting local SSH traffic through the tunnel. This, I think, requires the bind switch.
Herman