[Verizon Samsung Galaxy S III] crabapples:
Your environment seems optimal for making this work. And, maybe I need to reevaluate my remote end environment.

Currently the ssh daemon operates on a server machine that also includes a socks5 proxy for allowing unrestricted and encrypted access from any location. The service interfaces I wish to access remotely, however, reside on a separate machine on the same network. This means that the IP:Port has to pass unmolested through the tunnel. The socks5 proxy on the sshd machine is irrelevant to this process, it should be noted. However, as I understand it, the port being forwarded through the tunnel does have to be a dynamic port in order to appropriately reach the second PC. Dynamically forwarded ports are handled with a socks protocol in ConnectBot.

So my environment is as follows

192.168.1.101 serves sshd on port 22.

192.168.1.100 serves interfaces on ports 2100, 8080, 80801 and 8082.

From the android device (S3) I expect to enter the address 192.168.1.100:8080 into a browser and have the related service interface be accessed remotely. This is exactly what occurs with the appropriate ports forwarded from ConnectBot and using proxydroid as a global proxy or even as a proxy tied directly to the app similar to your iptables string that matches the owner application. It should be noted that since the port is dynamic it really only requires ConnectBot to have a single port forwarded and for the redirection to jump to that port regardless of the originating port (say, 8080 or 8081 or 2100) because the originating port passes the tunnel unmolested in this configuration.

It sounds like I could relocate the sshd to the PC hosting the service interfaces and alleviate this issue (maybe, possibly) of having to use dynamic ports and use a more traditional explicit local to remote port forwarding scheme. However, knowing that it can be achieved otherwise leads me to seek a solution that doesn't require reconfiguration of the remote PCs and all of the various machines I have configured to access this configuration remotely for other purposes.

I did try your iptables string exactly and also without the owner application matching making it a more global redirect if I parse it correctly. I also tried these configurations with ConnectBot configured with traditional instead of dynamic port forwards but neither way works.

I still believe that the proxydroid method is succeeding because it includes the socks5 proxy layer via redsocks. I believe but cannot prove that this is what enables the dynamic port forwarding to work through the tunnel. While the method you are outlining makes good theoretical sense it is failing in practice.

All that said, I decided to run a test wherein I redirected all traffic on port 80 to port 6543 and then configured connectbot to forward from port 6543 to port 8118 which should engage my remote socks5 proxy and use my remote internet connection. It appeared to work and to double check I disconnected ConnectBot yet somehow my android browser still had no issues accessing internet sites on the 4g connection. So, apparently iptables is being ignored entirely or I am completely missing the boat, here.

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to 127.0.0.1:6543

iptables -t nat -L =

OUPUT

DNAT tcp -- anywhere anywhere tcp dpt:www to 127.0.0.6543

Explain how that successfully fetches http requests despite having a service listening on 6543 to facilitate it.

Not sure if it was required to use that -m match switch to tie the iptables rule to an application so I tried:

ps | grep lan =

Application is 23094

therefore

iptables -t nat -A OUTPUT -m owner --uid-owner app_23094 -p tcp --dport 80 -j DNAT --to 127.0.0.1:6543

iptables -t nat -L =

OUPUT

DNAT tcp -- anywhere anywhere owner UID match app_23094 tcp dpt:www to 127.0.0.6543

Same result; not tunnel or service listening on 6543 but successful fetch of http requests.:eek: