--experimental-remote-ip=local in Blink's mosh still performs an IP lookup remotely, resulting in an unexpected LAN address

[ahrex]

Checklist

• Using latest version on the App Store
• Read the docs
• Searched for existing GitHub issues

Configuration

Blink v16.1.10.772

Describe the bug

I find it difficult to mosh to a target host that's in a LAN behind a bastion host. See the following diagram and legend:

                                   +------------------------+
                                   |         firewalled area|
                              +------------+                |
    +--------- #1: ssh ------>|bastion host|                |
    |                         +------------+                |
+-------------+                    |     |                  |
|external host|                    |     | #1: ssh          |
+-------------+                    |     v                  |
         |                         |  +-----------+         |
         +-------- #2: mosh --------->|target host|         |
                                   |  +-----------+         |
                                   |                        |
                                   +------------------------+

host	internal IP address	external IP address
bastion	192.168.0.5	203.0.113.15
target	192.168.0.10	203.0.113.20

In the above diagram, this is how I would connect to target host on a laptop:

mosh \
  --ssh='ssh -o ProxyCommand="ssh -W 192.168.0.10:%p %r@203.0.113.15"' \
  --experimental-remote-ip=local \
  -- \
  user@203.0.113.20

• the --ssh argument allows me to take path #1: ssh to target host to start mosh-server, and
• the --experimental-repote-ip=local + 203.0.113.20 allows mosh to take path #2: mosh past the UDP firewall exception

With the removal of --ssh in commit b38391c, I find it difficult to direct a different control plane path for starting mosh-server.

May I ask that you re-enable the ability to use --ssh in the mosh command, or support the ProxyCommand or ProxyJump ssh options via another method?

Thanks!

[carloscabanero]

Thanks for the heads up! I will take a deep look at this next week. By any chance, did you try to configure a SSH host for this? That way it would be ssh itself dealing with all that configuration.

[ahrex]

Thanks for the heads up! I will take a deep look at this next week.

You're welcome, and thank you!

By any chance, did you try to configure a SSH host for this? That way it would be ssh itself dealing with all that configuration.

Yup; here are the relevant configs.

The following work in Blink:

• ssh bastion
• ssh target
• mosh bastion

While this case fails:

• mosh target

I believe this fails because when the initial control plane ssh connection is established, searching for the IP address of target results in 192.168.0.10, which is not accessible from the Internet.

Thanks again!

---

Edit: I've also tried the following `target` config to more closely match the initial problem description.

The results were the same successes/failure.

[ahrex]

Looking at both mosh's source and blink's source, I think the issue boils down differences in implementation of --experimental-remote-ip=local:

• local in vanilla mosh instructs the external host to look up the IP address entered on the command-line, as seen by the Internet
  • this results in a lookup of target's HostName, returning 203.0.113.20 ✅, while
• local in blink connects to target via the ssh control path, and asks target what its local IP address is
  • this results in the LAN IP of target, returning 192.168.0.10 ❌

Updating my original request, I do not think I need a re-introduction of the --ssh argument into Blink's mosh, but rather I would like that --experimental-remote-ip=local in Blink perform an IP lookup on the client device.

[carloscabanero]

Hey, thanks for the thorough explanation, you nailed it. We need to change the way we call our default option as it is not really "local". Our "local" is basically using our ssh API and command so we connect to the same host (a more straightforward approach than what mosh does with "proxy" to pass a ProxyCommand to ssh and read the IP back). "Local" as you noticed should just take the manually resolved from user@host.

I will fix it this week. Are you on TestFlight by any chance?

[ahrex]

Thanks for the eyes! I'll DM you my TestFlight email.

[yury]

Closing as implemented and released. Feel free to reopen if needed.