Support custom remote ports

[umdstu]

TLDR; When connecting to vscode-server, the incoming port from the server's perspective is random, so a new firewall exception for port XYZ ingress needs to be added for each session.

The ssh connection is established, and the vscode-server service is started/running on a randomly generated port, the client cannot connect back to the vscode-service if iptables is running.

iptables on my system works as a whitelist, so everything is blocked by default (not uncommon), and only the IP's/ports you want enabled in or out are then added. In the default scenario, adding a rule for 45144 (the incoming port used the first time vscode connected to the remote service) would have allowed local vscode to connect to the remote service (port 22). However, the next time it started up, the local port vscode used to connect to port 22 was different, and not in the exceptions list, so vscode client will fail to make the connection after the ssh tunnel occurs.

[jhugery]

I totally agree that this is something that needs to be added. We regularly lock down our hosts in a similar fashion. We would really love to use this extension but cannot for the same reason.

[gyzerok]

It looks like my issue is a duplicate of this one. I will close it in favor of this issue.

[roblourens]

Thanks for the request. This is something we should support, but it adds some complications since in that case you can only have one instance of the server running. So if you upgrade, we have to forcibly shut down the previous server, disconnecting any other windows that are connected. Or then only one user can ever connect to a host. So it would take some careful thought to handle these cases in a reasonable way.

[umdstu]

Thanks for acknowledging this need! You do make a great point. Currently i have to open up a port range of like 40k ports in order to capture All potential ports. Maybe allowing a setting to specify the port range could be the solution, or part of the solution? You only get as many instances/connections as you allow in your range. Just a thought!

…

On Fri, Jul 10, 2020 at 1:38 PM Rob Lourens ***@***.***> wrote: Thanks for the request. This is something we should support, but it adds some complications since in that case you can only have one instance of the server running. So if you upgrade, we have to forcibly shut down the previous server, disconnecting any other windows that are connected. Or then only one user can ever connect to a host. So it would take some careful thought to handle these cases in a reasonable way. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1386 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ445E4B5LLG4PJZABI3OTR25GZ5ANCNFSM4IU2F5OQ> .

[gyzerok]

Thank you for coming back to the issue!

Would it be possible in the meantime to provide some temporary setting in nightly? It won’t lock you into any particular design/decision, but will help those of us who are struggling currently.

Or maybe you can somehow allow starting the server manually? If I understand your license correctly, currently this is prohibited.

[marius311]

Would be great if this simple thing could be added, I have a similar system behind a firewall where I can reverse tunnel ports effectively whitelisting them in the firewall, but I can't use Remote SSH because I don't know the ports ahead of time.

Btw, for others here you might check out https://github.com/cdr/code-server if you didn't know about it, which lets you launch a VS Code server (the open source version) by hand on the server and manually select the port.

[Sefton419]

There are too many other services trying to run on port 3000 - create-react-app among them. Can we have the option to change port for forwarding?

[atzin-em]

Is there any update on when this might be implemented? Or any stopgaps in the meanwhile?

[leighmcculloch]

@bamurtaugh redirected me here from #5340. The temporary port forwarding feature is very useful, however it only supports port forwarding to the localhost interface on the host. It would be very useful if it was possible to configure which interface or address to bind to.

So not just custom port but custom interface/address, or the ability to change the default address/interface.

One example use case is port forwarding to the host for sharing across a VPN when working with colleagues.

A work around to this limitation is to use socat on Mac/Linux systems to listen on the other interface and port forward to localhost for port forwarding into the container. Example:

socat TCP-L:8001,bind=100.11.11.12,fork,reuseaddr TCP:127.0.0.1:8001

It works, but it is inconvenient.

[jabbera]

Another vote for this feature! In a zero trust world this bites:-)

[jabbera]

Can I suggest a different approach? Is there a reason we can't have the server just listen on localhost and tunnel the traffic over ssh? I think you have all the building blocks for this already no?

[roblourens]

I guess I'm not sure exactly which port is needed to be customized

1. We use ssh -D to do dynamic port forwarding with some random port on the client
2. We ssh to your host, and start our server, which picks a random port to listen on locally
3. We open a connection via SOCKS from some random local port to the port the server is listening on

Is it just the port that the server is listening to that you want to customize? Or when you talk about the "incoming port" on the server, is there something else?

And do you need to customize the ports on the client (1 and 3)?

[umdstu]

When I originally created this issue, it was to address the fact that our virtual machines where code was hosted defaults to DENY ALL ports. Being unable to specify the random port that it used for communicating back out to the vscode app on the desktop meant that I had to blanket open ports ~20000 to 65535, which was a security issue. I'm having a brain fart and can't figure out which of your 3 options was responsible for this issue.

Edit: I believe it's the random port in 2 that was the issue; 3 didn't succeed because that random port from 2 was being blocked by iptables;

[gyzerok]

When I was creating similar issue before closing it in favor of this one, I meant 2.

In our env only selective ports on the remote are open, so port forwarding won't work with just random port.

[tanhakabir]

Just merged in a PR to add this feature. It'll be out on Remote-SSH Nightly tomorrow! You can try it out with the setting remote.SSH.serverPickPortsFromRange. Please let me know if there's anything unexpected!

[gyzerok]

@tanhakabir you are amazing! I have been waiting for this feature for about 1.5 years now. Finally it's here! 🎉

Do I understand correctly that one would need to specify at least 2 ports for the feature to work?

[KalianneRosa]

Just merged in a PR to add this feature. It'll be out on Remote-SSH Nightly tomorrow! You can try it out with the setting remote.SSH.serverPickPortsFromRange. Please let me know if there's anything unexpected!

Hi @tanhakabir, I have installed both VS Code Insiders and Remote-SSH Nightly. I tried to use remote.SSH.serverPickPortsFromRange, but it is still using random ports. Should I enable/disable other extension settings? Thanks.

[tanhakabir]

You need to pass in a range the port selected to be used should be within that range. Example I want Remote SSH to only bind to ports between 5000-5500.

[tanhakabir]

Oh sorry I also forgot to mention you will also need to try on VS Code Insiders. This required some changes on VS Code as well.

@KalianneRosa would you mind creating another issue and posting your logs so I can see?

[gyzerok]

Would it work to specify single port as 5000-5000? Or at least 2 are required?

[tanhakabir]

It's start and end inclusive so it would work but if 5000 isn't available it'll throw an error and not connect