Network issue : Not sure if it is a bug or I am looking for a feature

[stauffenberg2020]

Hi @nirui ,

I have hosted your sshwifty client in my Synology NAS's docker. The NAS (in Home network - Network 1) is always connected to (tailscale) VPN. I also have assigned reverse proxy to my hosted sshwifty client, So that I can easily acces it from outside my home network.

I have another device in a seperate network (Network 2) which is also connected to the same (tailscale) VPN.

I am able to access sshwifty using the reverse proxy from outside network without (tailscale) VPN, But not able to ssh to Network 2. I was hoping that sshwifty operates from NAS/Network 1 and it should be able to see Network 2 via the (tailscale) VPN.

Can you please let me know if I am missing something here

[nirui]

Hi,

I'm not familiar with Tailscale, but I feel this is more of a networking problem than Sshwifty, since currently Sshwifty don't actually mess around with the OS networking facility (say, it uses whatever egress network interface the OS provides).

You can do a test to see if the container can reach the Network 2 by running ping inside the container context:

1. While the container is running, obtain it's PID via command docker inspect <ContainerID> -f '{{ .State.Pid }}' (replace <ContainerID> such as 6cf827e93dcd with the actual container ID), this should give you the PID needed for step 2.
2. Then run sudo nsenter -t <ThePIDObtainedInPreviousStep> -n. This will drop you into a shell under the container's network context.
3. In the shell obtained from step 2, run ping <TargetHostIP> or ssh -v <TargetSSH>, and see the output.

If the commands from the step 3 indicates no packet or no connection, then maybe it's a routing problem.

Unfortunately, I lack the knowledge on the Linux networking side of things. I usually bribe people to setup routing for me, so if it is network issue, then I don't have enough knows how to help you out further :(

But of course, you can always run the container in host network mode (docker run ...--network host...), which should resolve this problem (while bring others). You should only try this when everything else has failed.