Windows 8 Network Sandboxing, and why SSH Tunneling will not work.

After about an hour of testing SSH Tunneling/Port Forwarding to no avail, I’ve discovered that loopback, or localhost to localhost, connections are “sandboxed” in Windows Store apps. Meaning that an app listening on localhost can only connect to its own services. Desktop apps cannot communicate to Metro apps through TCP/IP or UDP through localhost. In fact, the rule is so strict that you have to use a tool to temporarily and locally enable loopback exemptions for testing:
How to enable loopback and troubleshoot network isolation

So what does this have to do with SSH Tunneling/Port Forwarding? It means that the idea that you’d be able to connect to localhost:23 to tunnel telnet traffic, or localhost:8081 to proxy HTTP connections, is really not feasible in Windows Store apps at this time. Developers are able to tunnel internal components, such as an in-app browser, but Desktop apps and other Metro apps would not be able to.

If Microsoft reneges on this policy in some way that allows a Windows Store app to run as, or register, a local service then SSH Terminal Emulator will have the feature ready; however, until that time comes, I have to put the feature to rest.

I’m sorry for anyone who I may have unintentionally misled about this feature being available in a matter of time. I’m learning this framework along the way, as are many developers. I hope that this does not dissuade anyone from purchasing or using the app. In fact, I hope my honesty and frankness show you how dedicated I am to this project. I use this app just like you. This was a feature I wanted in the app, but it is not possible with the current framework Microsoft has given developers.

On a side note, check back soon for a Release 9 Preview post.

Thanks again for all your support!

4 Responses to “Windows 8 Network Sandboxing, and why SSH Tunneling will not work.”

  1. Dav

    If I understand correctly what you are saying, an owner of a Windows RT device (e.g., Surface RT) :

    1) could use CheckNetIsolation.exe on his/her tablet to exempt your terminal app from the network isolation restriction
    2) exempt other applications from that.
    3) Use your app to tunnel traffic through SSH port forwarding once it has been exempt.
    4) (I am not sure about this) Instead of # 2) above, simply configure Windows to tunnel all WiFi connections through localhost:port, and set your app (once exempted) up to listen on port.

    What of the above points is not the case?

    If this is feasible, why don’t you:

    a) Add the capability of tunneling connections through your app?

    An owner can do the exemptions manually and it would not be in breach of any rule since an owner is not the developer of such application. The feature will be dormant and inoperative unless the user explicitly does the exemption.

    OR

    b) If MS would threaten to ban your app from the Store, would you create a second version of your app that people can privately buy from you and then sideload (I know this can be expensive, but it’s not a cost you will bear) in their Windows RT devices?

    At this time, my employer only allows me to connect to our Intranet using the local WiFi NW through SSH port forwarding. With Android this is trivial, but not with Windows RT

    I am pretty sure many people would be willing to pay for such a feature.

    Reply
    • admin

      I know people would be willing to pay for a feature. You’re not the only one willing to pay for it. Unfortunately, it’s just not in the cards right now.

      First, this restriction of loopbacks is not just for Windows RT devices. It applies to Windows 8 installations as well. Secondly, if you could even get CheckNetIsolation.exe to allow a Windows Store App to access the loopback, it’s a temporary solution, since I am fairly certain the exemptions are stored in memory, and on reboot you would have to redo the exemption.

      On top of that, I really can’t except the average user to do all of that just to get port forwarding to work. It’s unintuitive, messy, and dangerous for my app in the store, as you pointed out.

      I could potentially create a second version of my app for side-loading just for people who want to try and configure the loopback exemptions. This big problem with this is that it’s a lot of work (that’s only half done) for a feature I can’t offer everyone, on a $2 app, that still needs other features and fixes. I’d prefer it if everyone who wanted this feature would contact Microsoft about how their OS policy of preventing apps from talking to each other is hurting innovation on their store. Microsoft expects WinRT to replace WPF and Winforms applications eventually, but their framework is incomplete and young, and they need feedback from people like us to get that framework to where it needs to be.

      If Microsoft makes it so that I can do port forwarding without having to break rules in the store or provide a side-load version of my app I’ll have it in very quickly. Until then, I have to keep pushing forward with the other things I have planned.

      Reply
  2. Aussie

    So, an SSH tunnel within an app (e.g., for VNC/RDP) would be OK? Have you considered teaming up with a VNC/RDP app developer to build an app that can connect over an SSH tunnel? I know that’s a different direction to your plans for Terminal RT, but frankly, even as separate apps I would pay for both!

    Clearly, general-purpose SSH tunneling on RT isn’t going to be feasible until Microsoft adds a network isolation setting for loopback that developers can choose for their app’s permissions and customers can accept on download (like the client-outbound app permission).

    In the meantime, special-purpose apps incorporating their own SSH tunneling would still be well worth up to $tens each to me! I remember paying something like that for an RDP over SSH app on iPad.

    Reply
    • admin

      If an app developer wants to incorporate SSH tunneling into their app, the code that TerminalRT uses is available through GranadosRT on github. It’s been awhile since I checked to see if the permissions/restrictions have changed for tunneling, but the last that I heard it was still not possible for two apps to talk to each other. So, tunneling functionality needs to be implemented by each app that wants connect to servers through SSH.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

     

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>