UKC

Let's see if UKClimbing is able to sort out IPTables/NAT issues!

I have a VPN (tun) which we route traffic through to allow access to SSH other servers. The VPN works fine, outgoing traffic collects the eth0 address etc (all traffic is routed through the VPN). All our servers, including the VPN server, are restricted to accept SSH traffic only from the VPN external address (and a couple of other failsafe IPs).

The issue we're facing is that when you're connected through the VPN, we cannot SSH into the same VPN server because for this specific traffic it appears to be sourced from the address of the primary internet connection, rather than the VPN address and is therefore blocked.

I'm a relative novice when it comes to more complex routing tasks. Any ideas?

Feel free to email if easier

Thanks in advance.

In reply to John Roberts (JR):
Are you saying you have a setup something like this?

(Home PC)
bob 8.1.1.1
||
\/
(vpn server)
john 8.2.1.1
||
\/
(server only on vpn)
dave 192.168.1.1

And you can SSH from bob->dave (ssh 192.168.1.1) OK but not bob->john (ssh 8.2.1.1)?

(excuse the shonky ASCII art)

In reply to gav:
Yes can SSH to dave but not SSH to john ie this is impossible curently:

(Home PC)
bob 8.1.1.1
||
/
(vpn server)
john 8.2.1.1
||
/
(server only on vpn)
john 8.2.1.1 (via SSH)

In reply to John Roberts (JR):


Can you not go -

(Home PC)
bob 8.1.1.1
||
/
(vpn server)
john 8.2.1.1
||
/
(server only on vpn)
dave 192.168.1.1

Then SSH from dave to john? How do you access john when you are physically on the internal network (and not via the VPN)?

In reply to John Roberts (JR):
You can't really route all traffic from bob to 8.2.1.1 via the VPN as that would break the VPN connection itself. You could try and just change the routing table metric with something like

route add -net 8.2.1.0 netmask 255.255.255.0 metric 0 dev vpn0

This will make it preferable to go through vpn0 for 8.2.1.X addresses, so it should try that first. You might already have a similar route in the table anyway configured by the VPN though - check with "route" (no arguments).

This assumes that bob is a linux PC - is it linux, mac or windows?

Other options include tunnelling SSH via "dave", or configuring a second IP address for "john" that's only accessible via the VPN. You could use iptables on bob to drop all packets going to 8.2.1.1 on port 23 via eth0 and see if that forces it to go over vpn0.

In reply to MeMeMe:













We could in principle yes do that with a bit of setup to allow the SSH in from the other servers though it's not an internal network as such. The VPN is in the cloud itself as are all the other servers in clusters across different data centres, they're not on an internal network, they're all connected via external network.


We can access it via one of the "failsafe" IPs ie office IP address.

There's two reasons really, its easier to be able to get onto all the network from the VPN without having a different setup (ie SSH through somewhere else though granted it would work) just for accessing that VPN server and simply inquisitiveness as to how to get it to work!

In reply to gav:



Did try that, but might have made a mistake so will re-visit.



Linux servers, openvpn on macs generally at end user.


Port 23 is dropping already so that doesn't work unfortunately.

Thanks for your help!

In reply to John Roberts (JR):


What does your routing table look like?

In reply to John Roberts (JR):

Is this something that can be solved by a simple ProxyCommand entry in your

/etc/ssh/ssh_config

file?

ie to get to B you have to jump through A

so

Host HostA
Hostname 192.168.1.1

Host HostB
ProxyCommand ssh HostA nc -w 1 10.0.0.1 22


nc = netcat which is often installed by default in most distros


So you do

ssh HostB

and it would then log in to HostA, and forward you to HostB

You need to have an account / keyless login on HostA to do this

I may have mis-read this thread. given the time, and how tired I am, but the fact that it is a VPN should not make any real difference to what I'm suggesting.

In reply to Dominion:

Yes that would probably work (with stored public keys), essentially as an automated version MeMeMe's solution. Cheers.