SSH connenction using a VPN results in "No route to host"

Hi,

I am currently running into the following issue. I am a student at a university which provides a VPN. Due to my master thesis I need to work on a computer with much GPU power and the university therefore provides one which I can use via ssh. However this is just possible if I am inside the network of the university. Therefore when working form home I am using the university’s VPN.

This VPN is a using OpenConnect as protocol and it is working for me so far (I can access sites which can only be accesed via the internal network for example).

However, when I now try to connect to the remote desktop via ssh (which also works when I am inside the university network and not the VPN). I get the error

ssh: connect to host … port 209: No route to host

I tried to find a solution, however nothing suited my problem so far and I have no guess what I should try.

Thank you for your time and the help!

VPNs are subnetworks, Therefore you need to enable the port by iptables (firewall rules) on the server.

It’s anyone’s guess without knowing network topology. As error suggests there is a route missing.

On what subnet are reachable sites located? It’s not the same subnet as your “gpu-PC” I guess.
Why did you replace “gpu-PC” IP with 3 dots, is it not a private IP (ie. 192.168.x.x, 10.x.x.x, 172.16-31.x.x)?

Can you provide outputs of ìp a and ip r?

We had something similar here, were the “student role” was still not allowed to connect to internal devices when connected with VPN.

Could you talk to your IT first and ask if something like this is in place with your institution?

I just drove to the university and now it does not even work when I am not using the VPN. It seems that something broke over the weekend, it worked with no problems before I tried to connect from home.

The remote desktop is used by several people and students via ssh and also from home via VPN so I guess if there is a problem it must be on my side. I can ping the server so it is not shut down I guess.

The ip does not start with 192.168.x.x, 10.x.x.x, 172.16-31.x.x, so I do not know about posting it here or not. My guess was it is not relevant for resolving the topic?

The output of

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp8s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 7c:d3:0a:82:b5:df brd ff:ff:ff:ff:ff:ff
3: wlp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 50:e0:85:b9:f7:99 brd ff:ff:ff:ff:ff:ff
    inet 172.18.75.139/18 brd 172.18.127.255 scope global dynamic noprefixroute wlp9s0
       valid_lft 2812sec preferred_lft 2812sec
    inet6 2001:41b8:83c:fa01:17b3:faac:372e:edb8/64 scope global dynamic noprefixroute 
       valid_lft 86386sec preferred_lft 43186sec
    inet6 fe80::b3e9:c78e:fa02:5385/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: vpn0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1356 qdisc fq_codel state DOWN group default qlen 500
    link/none 
    inet6 fe80::2e08:826:d6cd:e736/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

and

ip r

default via 172.18.127.254 dev wlp9s0 proto dhcp metric 600 
172.18.64.0/18 dev wlp9s0 proto kernel scope link src 172.18.75.139 metric 600

Well, it seems that it is really an internal problem of the university… I just called some people and and it seems that everybody else also has issues. I was told that I can ping since the router is available but the connection to the actual PCs is not working.

Still thanks for all the help, I will wait until the issues are resolved and see if the problem is gone!

Sorry for wasting your time guys!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.