This isn't Mac specific but same rules apply if I was connecting with Mac or PC.
I've got a linux server set up at a static IP and the IT department at the University I'm working with said the only way to SSH into the server from off campus was to connect the static IP to a VPN account.
Launched the VPN client, then tried to ssh into the server. The connection timed out. I tested the setup 100 different ways and could SSH into it without an issue but couldn't test it over VPN (for reasons beyond my control).
This is the first time I've ever done this when I don't have physical access to the server so I'm trying to cover all my bases here and figure out what is going wrong. If I'm connecting to the server using SSH from from a remote computer using their VPN client, is there something that needs to be changed on the server config? I'm having a lot of trouble finding information that isn't just about how to create an SSH tunnel as a substitute for VPN which is not at all what I'm trying to do.
Okay so this is where I feel like I'm missing something. Maybe it's just the way I'm interpreting what you've written but unless I'm mistaken that setting would make it so that be default something like ssh to an IP goes over the VPN connection. But you've said that the Linux server needs to know where the request is coming from. Obviously the two machines need to be on the same network but then is there something I haven't changed in the sshd_config file on the Linux server that isn't active by default? I was under the impression that, for example, AllowTunneling was only for tunneling through SSH tunnels to another machine. Thought there'd be some documentation on it that would be similar to what i'm trying but googling it has proven elusive.
This should be working by default, and it's something I do several times every day.
The biggest issue I've encountered is when your local IP subnet is the same as the VPN server's - or when the server you're connecting to via SSH is on a different subnet from the VPN server, but still on the same network. If that's the case, then the VPN server needs to be configured to treat that subnet as local. Otherwise, your computer will try to connect via non-VPN WAN/LAN connection.
This should be working by default, and it's something I do several times every day.
The biggest issue I've encountered is when your local IP subnet is the same as the VPN server's - or when the server you're connecting to via SSH is on a different subnet from the VPN server, but still on the same network. If that's the case, then the VPN server needs to be configured to treat that subnet as local. Otherwise, your computer will try to connect via non-VPN WAN/LAN connection.
Thanks for the replies everyone.
It's starting to seem clearer to me that it should work already and something's gone wrong with the installation or that IT has either not added the device correctly or that they've failed to convey the proper setup information to me (wrong IP, port, etc...).
I guess I'll just have to wait and hear back from them...
You might also want to check the ACLs (access control lists) on both the Linux box as well as any firewalls on the university side. You would need to make sure the Linux server is going to allow connections from the IP subnet of the VPN.
Also check that the VPN group your account is in is going to allow SSH. I know some of our VPN groups only allow RDP (port 3389) to a dozen servers, nothing else.
BReligion
__________________
"Hell hath no fury, like a woman scorned for Sega. " - Brodie Bruce :: Mallrats ::
:: Macbook Pro 13.3" 2.66 Core 2 Duo
:: Macbook 13.3" 2.0 Core 2 Duo (the wife's)
:: iMac 17" 1.83 Core Duo
:: iBook 12" 1.33ghz (retired)
:: iPhone 4 & iPhone 2G (8GB retired); iPod 5th Gen (80GB)
:: Apple TV - 160GB, Apple TV2, Airport Exteme & Airport Express
So, here's a good one. The IT department, of the university which shall remain nameless, reported back on the issue. The support ticket said, "machine is now plugged in and turned on."
So, here's a good one. The IT department, of the university which shall remain nameless, reported back on the issue. The support ticket said, "machine is now plugged in and turned on."