Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support in mosh-server for opening ports via UPnP #537

Closed
jscinoz opened this issue Jul 17, 2014 · 8 comments
Closed

Implement support in mosh-server for opening ports via UPnP #537

jscinoz opened this issue Jul 17, 2014 · 8 comments
Labels

Comments

@jscinoz
Copy link

jscinoz commented Jul 17, 2014

In some situations, the remote machine may be behind NAT/firewall. While the user can manually preconfigure the requisite port-forwarding rules, it would be beneficial if mosh-server could request port allocations via UPnP.

It seems wrapper scripts[1] have previously been written to accomplish this, but this requires additional setup on each destination machine. Integrating this functionality into mosh-server itself would allow for a more streamlined usage.

[1] https://www.mail-archive.com/[email protected]/msg00103/mosh-server-upnp

@funkyboris
Copy link

bump

It truly would be nice to not have to manually forward ports on behalf of mosh to make it work.
It has a SSH connection already running. Giving either mosh-server or mosh-client a flag to tell it to use UPnP would indeed be a nicer and more versatile solution than having to rely on statically forwarded ports.

@ironiridis
Copy link

This would be a substantial usability improvement. In particular, if mosh is running on a server with other UDP services, having the ability to selectively open just mosh's UDP port on the external interface automatically is a huge win.

I don't know if UPnP is really the most elegant solution. qemu, for example, permits an ifup/ifdown pair of scripts for dealing with ip configuration and firewalling dynamically when a vm changes state. Executing a user-defined script with environment variables set for the parameters would accomplish this just as well as UPnP, without the scary security concerns that go with UPnP and SSDP.

@gcochard
Copy link

gcochard commented Apr 8, 2016

What about using something like MiniUPnP to attempt hole-punching if the router supports it? I wrote a proof of concept to glue it all together here.

@ghost
Copy link

ghost commented Dec 29, 2017

@jscinoz wrote on 17 Jul 2014:

In some situations, the remote machine may be behind NAT/firewall. While the user can manually preconfigure the requisite port-forwarding rules, it would be beneficial if mosh-server could request port allocations via UPnP.

Agreed. This could also potentially mitigate - at least partly - users' concerns about needing to leave 60000-61000 open on mosh servers. Instead of having to leave all those ports open, it would be better to have the Mosh server automatically open one UDP port at the firewall, after being invoked via SSH, in order to enable the Mosh client to finish connecting.

@ironiridis
Copy link

In particular it would be ideal for mosh to open that port only after binding to it, since an app may be able to use an idle mosh UDP port for data exfiltration otherwise.

@tlhonmey
Copy link

The simplest way to do this would probably be to add a way to have mosh run some arbitrary command via the ssh link prior to starting mosh-server. That command could then open a firewall port, or create a UPnP forwarding, or start a VPN client/server or whatever else is necessary to make connection possible.

@DCNick3
Copy link

DCNick3 commented May 30, 2019

Well, there is https://github.com/arcnmx/mosh-server-upnp

@achernya
Copy link
Collaborator

As part of a mosh issues triage, we've concluded that the mosh project has no current plans to work on this issue. To accurately reflect that work on this issue is not planned, we're marking this issue as "closed". We still welcome contributions from community members who want to work on this issue. Please feel free to file pull requests re-opening this issue in the future.

@achernya achernya closed this as not planned Won't fix, can't repro, duplicate, stale Jan 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants