How to route SSH over OpenVPN

rolling

Hi all. I have successfully installed the openvpn client and server, and with my configuration, browser traffic (ports 80 and 443) is being correctly routed over the VPN as desired. Unfortunately, actually my application, my reason for installing openvpn, is so that I can present a static IP (the IP of my openvpn server) to a linux box that only allows SSH access to whitelisted IP addresses.

If I launch the openvpn client and server and go to whatismyip in my browser, I get the IP, which is static, of my openvpn server, as desired. But if I try to SSH to my server and then do 'last' from the command line, the IP address shown is the one that my ISP dynamically assigns to me. In fact what I need is for my SSH traffic to be routed via the VPN so that it will appear to the server I want to SSH to that I am coming from the IP of my openvpn server.

Here is my server config:

proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 60
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn.log
verb 4

And here is my client config:

client
dev tun
proto udp
remote [REDACTED -- the IP of my openvpn server] 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
redirect-gateway def1 bypass-dhcp
verb 4

From my research on this, I had expected the line 'redirect-gateway def1 bypass-dhcp' in the client config to do the trick. Alas, no.

I understand that (as far as I can tell) the issue is with my client, i.e. I need to amend the client config so that all traffic locally is routed over utun0. Here is my local ifconfig once I have launched the openvpn client (Tunnelblick) --

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:1f:5b:d5:54:ca
inet6 fe80::21f:5bff:fed5:54ca%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.245 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff

Finally, here is the client-side connection log:

2014-12-31 19:13:10 *Tunnelblick: openvpnstart starting OpenVPN
2014-12-31 19:13:11 OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Dec 1 2014
2014-12-31 19:13:11 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
2014-12-31 19:13:11 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2014-12-31 19:13:11 Need hold release from management interface, waiting...
2014-12-31 19:13:11 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2014-12-31 19:13:11 MANAGEMENT: CMD 'pid'
2014-12-31 19:13:11 MANAGEMENT: CMD 'state on'
2014-12-31 19:13:11 MANAGEMENT: CMD 'state'
2014-12-31 19:13:11 MANAGEMENT: CMD 'bytecount 1'
2014-12-31 19:13:11 MANAGEMENT: CMD 'hold release'
2014-12-31 19:13:11 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2014-12-31 19:13:11 *Tunnelblick: Established communication with OpenVPN
2014-12-31 19:13:11 Socket Buffers: R=[42080->65536] S=[9216->65536]
2014-12-31 19:13:11 UDPv4 link local: [undef]
2014-12-31 19:13:11 UDPv4 link remote: [AF_INET][REDACTED IP OF OPENVPN SERVER]:1194
2014-12-31 19:13:11 MANAGEMENT: >STATE:1420053191,WAIT,,,
2014-12-31 19:13:11 MANAGEMENT: >STATE:1420053191,AUTH,,,
2014-12-31 19:13:11 TLS: Initial packet from [AF_INET][REDACTED IP OF OPENVPN SERVER]:1194, sid=37af2123 a788e246
2014-12-31 19:13:15 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
2014-12-31 19:13:15 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2014-12-31 19:13:15 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
2014-12-31 19:13:15 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2014-12-31 19:13:15 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2014-12-31 19:13:15 [astra] Peer Connection Initiated with [AF_INET][REDACTED IP OF OPENVPN SERVER]:1194
2014-12-31 19:13:16 MANAGEMENT: >STATE:1420053196,GET_CONFIG,,,
2014-12-31 19:13:18 SENT CONTROL [astra]: 'PUSH_REQUEST' (status=1)
2014-12-31 19:13:18 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
2014-12-31 19:13:18 OPTIONS IMPORT: timers and/or timeouts modified
2014-12-31 19:13:18 OPTIONS IMPORT: --ifconfig/up options modified
2014-12-31 19:13:18 OPTIONS IMPORT: route options modified
2014-12-31 19:13:18 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2014-12-31 19:13:18 Opened utun device utun0
2014-12-31 19:13:18 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2014-12-31 19:13:18 MANAGEMENT: >STATE:1420053198,ASSIGN_IP,,10.8.0.6,
2014-12-31 19:13:18 /sbin/ifconfig utun0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2014-12-31 19:13:18 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2014-12-31 19:13:18 /sbin/ifconfig utun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
2014-12-31 19:13:18 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -ptADGNWradsgnw utun0 1500 1542 10.8.0.6 10.8.0.5 init
**********************************************
Start of output from client.up.tunnelblick.sh
Retrieved from OpenVPN: name server(s) [ 8.8.8.8 8.8.4.4 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
Not aggregating ServerAddresses because running on OS X 10.6 or higher
Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected
Saved the DNS and SMB configurations so they can be restored
Set ServerAddresses to 8.8.8.8 8.8.4.4
Set SearchDomains to openvpn
Set DomainName to openvpn
Flushed the DNS cache via dscacheutil
Notified mDNSResponder that the DNS cache was flushed
Setting up to monitor system configuration with process-network-changes
End of output from client.up.tunnelblick.sh
**********************************************
2014-12-31 19:13:21 *Tunnelblick: No 'connected.sh' script to execute
2014-12-31 19:13:21 /sbin/route add -net [REDACTED -- the IP of my openvpn server] 192.168.1.254 255.255.255.255
add net [REDACTED -- the IP of my openvpn server]: gateway 192.168.1.254
2014-12-31 19:13:21 /sbin/route add -net 0.0.0.0 10.8.0.5 128.0.0.0
add net 0.0.0.0: gateway 10.8.0.5
2014-12-31 19:13:21 /sbin/route add -net 128.0.0.0 10.8.0.5 128.0.0.0
add net 128.0.0.0: gateway 10.8.0.5
2014-12-31 19:13:21 MANAGEMENT: >STATE:1420053201,ADD_ROUTES,,,
2014-12-31 19:13:21 /sbin/route add -net 10.8.0.1 10.8.0.5 255.255.255.255
add net 10.8.0.1: gateway 10.8.0.5
2014-12-31 19:13:21 Initialization Sequence Completed
2014-12-31 19:13:21 MANAGEMENT: >STATE:1420053201,CONNECTED,SUCCESS,10.8.0.6,[REDACTED -- the IP of my openvpn server]
2014-12-31 19:13:26 *Tunnelblick process-network-changes: A system configuration change was ignored
2014-12-31 19:13:27 *Tunnelblick: This computer's apparent public IP address changed from [REDACTED DYNAMICALLY ASSIGNED IP FROM ISP] before connection to [REDACTED IP OF OPENVPN SERVER] after connection

===

I can see that I am making a rookie mistake here, given how close this is to working, but I can't see it.

Specifically, I am guessing that I need to add or change a setting on the client side configuration so that all traffic locally is routed through via the VPN client to the VPN server. But I am at a loss to understand why, if traffic on ports 80 and 443 are being routed over the VPN (despite those ports not being explicitly referenced in the client.conf or server.conf), why port 22 should be any different. I have read a lot of posts here but I can't seem to apply them to my own situation.

Any assistance appreciated,

Mark

maikcat

is the ssh server you are trying to reach the openvpn server itself?

Michael.

rolling

I was trying to ssh to the openvpn server, yes. But also trying to connect to the IP of my hosting account's shell account. It turns out that the hosting company erred (now corrected) in failing to whitelist the IP. You have to e-mail them and ask them to do it, its not automated. They said they did it but did not. I assumed that I was at fault because when I would SSH to the openvpn server while also connected to it as a client, the IP would be the one assigned to my dynamically locally by my ISP. But no... with the openvpn IP whitelisted by the hosting company, I can now connect to their server via SSH.

So I think I am sorted, with thanks. One other question I did have: I have port 22 (ssh) on my openvpn server open to the world presently. How would I set the config such that port 22 is open for clients connected to the openvpn server via openvpn, but blocked for anybody else? I also have 2-factor authentication running for ssh access to the server so if it stays open to the world that's not terrible, but it would be better to only allow port 22 access from inside the VPN.

Thank you in any case. A very helpful question on your part.

maikcat

How would I set the config such that port 22 is open for clients connected to the openvpn server via openvpn

you mean the config of openvpn itself?
or iptables?

you can use openvpns server virtual ip (tun) for your openvpn clients to connect
instead of servers public one.

AFAIK sshd has tcpwrapper support which you can use...

Michael.

rolling

I guess this is an iptables question, unless there is a way to do this via the openvpn server.

Right now I have this as an iptables rule:

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

It allows everyone, from everywhere, to SSH to my openvpn server. I want to comment it out and replace it.

When the openvpn client connects, the openvpn server is available to the client with the IP 10.8.0.1 as well as available via the public IP of the openvpn server. I'd like to add an iptables rule which allows successful ssh to the private IP (10.8.0.1) while keeping the SSH port on the public IP closed.

I *think* this is an openvpn question, insofar as it is the openvpn client connection to the server which provides acces to the private IP. But if not, I get that.

Thanks in any case,

maikcat

you can always add an input rule which allows traffic from tun+ interfaces to your ssh server.

Michael.

rolling

I simplified my iptables rules and that seems to have done it. I can ssh to my server via its 10.x.x.x IP when I am connected to the vpn server. The public IP of the VPN server has only ports 80 and 443 open, port 22 is blocked. Below is the rule set in case it is useful to somebody else. With this config I am running ports 80 and 443 open to the world, and ssh is available to clients connected to the openvpn server.

If you see anything obviously wrong with the below (i.e. glaring security hole) please let me know.

Thanks again!
Mark

# clear everything, table names {'mangle', 'nat', 'filter'} are from /proc/net/ip_tables_names:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t filter -F
iptables -t filter -X

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# set some rules now that everything has been cleared:

# pre openvpn rules:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -m comment --comment "Allow loopback connections" -j ACCEPT
iptables -A INPUT -p tcp -m multiport --destination-ports 80,443 -j ACCEPT

# openvpn rules:

iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

# drop everything else:

iptables -P INPUT DROP
iptables -P FORWARD DROP

maikcat

just a couple of things to take into consideration...

1)iptable rules are read Sequentialy and the first match is applied

2)if no match found then the default action is applied (in your case allow)

its good practice to set your default rules to deny and allow the
traffic you want to pass through...

Regards,
Michael.

rolling

Hi again,

Another issue has come up. Things are working well so far for a single user, but when I try to add a second client to the vpn, it appears that the second client is allocated the same IP address as the first client.

The first client is me running an openvpn client (tunnelblick) on my desktop machine. The second client is also me, running the OpenVPN client on iOS.

The client configuration is identical on both machines and they are both accessing the same openvpn server. The first client to connect is being allocated the IP 10.8.0.6 and it works well. But then when the second client connects it also has IP address 10.8.0.6.

The client-side configuration and server configuration are as described earlier in this thread. I guess my questions are:

1) why is each client not being allocated a new IP address by the DHCP server?

2) what is the difference between, in the client configuration, 'redirect-gateway def1 bypass-dhcp' vs 'redirect-gateway def1' alone?

Thanks in any event,
Mark

maikcat

1) why is each client not being allocated a new IP address by the DHCP server?

if you are using the SAME client certificate then what you expirience is the correct behavior,
to override it use duplicate-cn directive on your server config.

2) what is the difference between, in the client configuration, 'redirect-gateway def1 bypass-dhcp' vs 'redirect-gateway def1' alone?

its a good practice to always "push" routes to your clients

from the man page:

--redirect-gateway flags...
Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option.

This option performs three steps:

(1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

(2) Delete the default gateway route.

(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

Option flags:

local -- Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

autolocal -- Try to automatically determine whether to enable local flag above.

def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

bypass-dhcp -- Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).

bypass-dns -- Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).

block-local -- Block access to local LAN when the tunnel is active, except for the LAN gateway itself. This is accomplished by routing the local LAN (except for the LAN gateway address) into the tunnel.

Michael.