Add support for port-forwarding

[nealvs]

It'd be great if we could use IAP port-forwarding using this tool.

[jpassing]

Thanks for the suggestion. This feature has already been in our backlog and I hope to deliver it in one of the next releases.

My current understanding is that the primary use case would be using tools such as SSMS, MySQL Workbench, or fat-clients such as SAP GUI. Are there any other tools you have in mind?

[nealvs]

MySQL is a primary use-case, plus internal web management UIs on ports like 8080, 9090, 8060, etc. Also some of our VMs don't support standard GCP ssh features, so forwarding port 22 would also be useful.

[jpassing]

I see, thanks.

Can you elaborate a bit on the SSH use case? There's another open feature request for supporting username/password auth for SSH -- would that help, or are you referring to something else?

[nealvs]

Username/password authentication for ssh would help, but we also have older operating systems that don't work with iap ssh handling, so we port-forward port 22 and connect to the local port with cert auth.

[fabioformosa]

The same, here! It would be great to have the chance to map a local port with a remote port (tunnel port forward) opening a connection to a VM through IAP Desktop. At the moment we are able to that only via CLI: gcloud compute ssh --zone "europe-west8-a" "my-vm" --project=my-project --tunnel-through-iap --ssh-flag="-L 5432:REMOTE_IP:5432" Correct me if I'm wrong, it looks like there's no way to specify ssh-flag option in IAP Desktop.

[jpassing]

Correct me if I'm wrong, it looks like there's no way to specify ssh-flag option in IAP Desktop.

Right, IAP Desktop currently doesn't let you pass such flags and also doesn't let you access its tunnels from other processes.

The idea is to change that and add a feature to IAP Desktop that lets you ...

• create tunnels to any VMs/ports, such as remote-vm:5432
• access that tunnel from other (local) apps such as pgAdmin by connecting it to localhost:<someport>

That would be similar to what you can do currently by running gcloud compute start-iap-tunnel remote-vm 5432, but hopefully more convenient.

Note that this is a bit different from what your command does: You're creating an SSH connection to my-vm through an IAP tunnel and then use SSH port forwarding to connect to REMOTE_IP. So you're currently nesting 2 tunnels:

Would the suggested approach above work for you? Or is there a reason why you have to use the "nested tunnels" approach?

[fabioformosa]

Hi @jpassing , thanks for your quick answer. I add more context: what I mentioned as my-vm is actually a bastion VM where I started a google cloud_sql_proxy to access to a private Google Cloud SQL and what I mentioned as remote_IP is actually a localhost to reach that cloud proxy running locally to the bastion. I guess the solution you've proposed should work. In the first diagram, regarding my scenario, the IAP Target is the baston VM. The nested tunnel with postgres would be out of scope of IAP Desktop.

[jpassing]

I see, thanks for clarifying.

[jpassing]

If you have the opportunity, it would be great if you cloud give this latest build of master branch a try. With this pre-release version, you can now:

• Connect to SQL Server using SQL Server Management Studio (using either Windows authentication and SQL Server authentication)
• Register additional client applications so that you can connect to other services like MySQL, HTTP, etc.

IAP Desktop creates an IAP tunnel, launches the application, and keeps the tunnel open until the application closes. It also protects the tunnel so that other applications can't access it.

To register a client application, you add a .iapc file to the %appdata%\Google\IAP Desktop\Config folder. You can find two example files (for MySQL and Chrome, as shown in the screenshot) in this folder. The .iapc files are JSON files that define the port to connect to, the type of VMs the client applies to, the command line to launch, etc. The format will eventually be documented in the Wiki, and I plan to include a collection of commonly used clients in the distribution.

Note that this feature currently only works for client applications that allow connection info (hostname, port) to be passed on the command line. Unfortunately, there are some clients (like MySQL workbench) that don't support that -- that's a topic for the release after.

[nealvs]

I was hoping to be able to open and close ports for any vm on demand for any application to connect to and not need to configure anything with iapc files. I tried configuring Chrome with port 8080, but it is disabled on every vm I try to use it with. How can I figure out why it isn't working?

[jpassing]

Yes, I also noticed that the Chrome configuration file doesn't work in all cases (for ex, it fails to find chrome.exe when you're using the 32-bit version of Chrome). I already started working on a fix to make that more reliable.

In the meantime, you can probably fix the issue by editing the .iapc file and fixing the path to chrome.exe.

I'm still planning to also add the option to open a port without launching any client, but I'm not sure yet if that'll be part of the next release or the one after.

[jpassing]

I published release 2.37 today and this now supports the following options by default:

In addition, it'll load any .iapc files that it finds in your local config folder. The file format is now documented here.

Neal, I realize that this isn't quite what you're looking for yet, so I'll keep this issue open until we also have the option to create arbitrary port forwardings. I hope that I can share a "preview" for that soon.

[jpassing]

With release 2.38, you can now forward any port:

After the tunnel has been created, there's a notification that tells you the local port number. The number is deterministic and will be the same when you connect to the same VM/port the next time.

You can see additional details in the "Active IAP tunnels" window.

Access to the forwarded port is limited to the current Terminal Server session -- so when you're on a multi-user system, other users can't access your tunnels.

I'm closing this issue, but if you have more feedback please feel free to open a new one.

I'm sorry it took a bit longer than anticipated, and thanks again for this feature suggestion!