[mosh-devel] Patch: UDP hole punching for firewalled servers

[Philipp Klenze]

Hello again,
Keith, I have just submitted a pull request containing my code.

Regarding hole-punching-servers, I here is my (somewhat lengthy) opinion:

One could try to replace the fifo from which the server reads hole
punching commands with the client side of some connection (tcp or udp)
to some public server, which would pass hole punching requests. While
this might speed up reconnects after IP changes a bit (no need for a
whole TCP handshake and SSH overhead) I think the extra hop (the public
server) would probably consume any savings.

As long as mosh relies on SSH (and thus a reachable sshd on the server)
for authentication and key transfer, one might as well use that server
to pass hole punching requests to mosh-server, in my opinion.

(If SSH is also firewalled, I would probably use socat to jury rig
 a crude one-connection-at-a-time forward of port 22 to some public
server, which should be plenty to start a number of mosh sessions and
handle any hole punching requests. If one had a shell account on the
public box, it would naturally be preferable to just run ssh -R
10022:localhost:22 on the mosh server. [1])

I think there are many boxes where people have user accounts and ssh
access but no practical way of changing firewall rules. (University
networks, for one thing.) Unless outgoing UDP is also disabled, users
can run mosh servers on these boxes with my patch.

regards,
   Philipp


[1] It should be possible to build a server where anyone can get an ssh
account which only allows port forwarding from a single port
(authorized_keys with PermitOpen), but I have yet to hear of someone
offering that service to the general public. It would probably need a
way to limit traffic, though.


On 06/11/2012 06:00 AM, Keith Winstein wrote:
> Hello Philipp,
> 
> Thanks, the idea of doing manual roaming with server-side
> hole-punching in this manner is an interesting one, especially if we
> can make the UI somewhat intuitive. Would you be able to submit this
> as a pull request on GitHub (https://github.com/keithw/mosh)? Then we
> can take a look at this properly and make sure it stays on our plates
> as further commits happen.
> 
> I'm starting to wonder if we should just set up our own hole-punching
> server to facilitate this exchange automatically ourselves, or if we
> can somehow leverage somebody else's. I do not know of a scheme to do
> server-side UDP hole punching that (a) supports roaming and (b)
> doesn't rely on the cooperation of a third party with a routable IP
> address.
> 
> -Keith
> 
> On Sun, Jun 10, 2012 at 10:17 AM, Philipp Klenze <hq.ks at web.de> wrote:
>> Hello everyone,
>> some time ago, I wrote a patch to handle hole punching which is useful
>> if the server is behind a stateful firewall.
>>
>> Usage case:
>> - the server is reachable via ssh
>> - other ports are firewalled
>> - outgoing UDP connections from the server are allowed
>>
>> This is not a special case, many network admins allow port 22 traffic
>> but block other ports.
>>
>> What my code does is the following:
>> - It gives the client the ability to control to which port it is bound
>> locally.
>> - It adds a control FIFO to the server. With this pipeline, the server
>> can be instructed to send empty UDP packets to arbitrary destinations.
>>
>> The connection mechanism changes to:
>> 1. the client starts the server via SSH
>> 2. the client greps the server output for both the key and the name of
>> the pipeline
>> 3. the client generates a forwarding script, which basically sshs to the
>> server and feeds the current IP (from ssh) and a predefined client port
>> to the servers control pipeline
>> 4. Said script is run
>> 5. the client is run both MOSH_KEY and MOSH_CLIENT_PORT are passed
>>
>> (Ideally, steps 4 and 5 should be in parallel, otherwise the client
>> might reply with some ICMP error to the packet sent from the server, and
>> that ICMP error might cause the firewall to stop passing packets through.)
>>
>> When the IP of the client box changes, it becomes necessary to punch a
>> new hole through the servers firewall. Currently, the user has to run
>> the script generated in step 3 manually to do this. However, the script
>> contents could easily be passed to the client to be run automatically on
>> timeouts or to be bound to a command key. (As I did not delve deeply
>> into the client yet, I did not add this yet.)
>>
>> When receiving the empty packet from the server after running the
>> script, mosh-client briefly complains about it but works on.
>>
>> I have included here
>> - a patch for the mosh source (written for the April git version, might
>> need some adaption)
>> - a sample shell script to run mosh in hole punching mode
>>
>> I tried to leave the default behavior unchanged.
>>
>> Maintainers, please tell me if you are generally interested in this
>> functionality and my implementation.
>>
>> Thanks for your time,
>>   Philipp
>>
>> _______________________________________________
>> mosh-devel mailing list
>> mosh-devel at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>>
>