Split tunnel to OpenVPN server only

Hutch

This may be an odd use case for OpenVPN, but we are looking to use it to secure communication between an OpenVPN client and OpenVPN server only. i.e., all other network traffic not destined to the OpenVPN server should be sent out of the client's default gateway.

Is this a viable use case of OpenVPN?

Everything works fine using 'push "redirect-gateway def1"' on the server, but that of course routes all traffic over the VPN which we'd like to avoid.

If I omit that option, and don't specify a route in the client configuration, I don't think traffic to the OpenVPN server is using the tunnel after looking at the routing table and monitoring the "tun" interface.

If I specify a /32 route in the client configuration, such as "route $SERVER_IP 255.255.255.255 vpn_gateway", I can connect, but once the client route is added, I can no longer communicate with the OpenVPN server.

Is this something that we should be able to get working, or is it not possible with OpenVPN and we should be looking at alternatives (e.g., placing the OpenVPN server on a different system, using IPsec, etc.)?

Thanks!

Hutch

Hutch

Written another way, assume the OpenVPN server is running a bunch of "insecure"/plaintext services such as FTP, telnet, SMB, etc. We want the client to securely access all of those using the tunnel, and we only want traffic to the OpenVPN server to use the tunnel (not replace the client's default gateway).

Is this possible?

Thanks!

Hutch

Hutch

Thanks for the reply. I must still be doing something wrong.

As a test, I installed OpenVPN 2.3.2 on an Amazon Linux AMI in AWS (via distro package). I also installed and enabled telnet server and vsftpd.

I run OpenVPN GUI as Administrator on my Windows 7 client (OpenVPN 2.3.4-I603) , connect, and am assigned IP 192.168.200.6 on my TAP interface.

If I then communicate with my OpenVPN server on TCP 21/23, I can see the plaintext traffic on eth0. Ideally I'd like it to go over the tunnel/tun0.

Do I need to add any routes in client.ovpn? Here are the 192.168.200/24 routes in the Windows routing table:

    192.168.200.1  255.255.255.255    192.168.200.5    192.168.200.6     20
    192.168.200.4  255.255.255.252         On-link     192.168.200.6    276
    192.168.200.6  255.255.255.255         On-link     192.168.200.6    276
    192.168.200.7  255.255.255.255         On-link     192.168.200.6    276
        224.0.0.0        240.0.0.0         On-link     192.168.200.6    276
  255.255.255.255  255.255.255.255         On-link     192.168.200.6    276

Here's server.ovpn:

port 1194
proto udp
dev tun
server 192.168.200.0 255.255.255.0

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret
dh /etc/openvpn/dh.pem
ifconfig-pool-persist ipp.txt

keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4

And client.ovpn:

client
proto udp
remote $MY_AWS_PUBLIC_IP
port 1194
dev tun
nobind
comp-lzo

verb 4

ca "c:/program files/openvpn/config/ca.crt"
cert "c:/program files/openvpn/config/client.crt"
key "c:/program files/openvpn/config/client.key"

Thanks!

Hutch

Thanks for your help so far.

server.log:
https://dl.dropboxusercontent.com/u/557196/server.log

clientlog:
https://dl.dropboxusercontent.com/u/557196/client.log

Connected, telnetted to the telnet server on the AWS IP--didn't see anything on tun0, saw it plaintext on eth0--and disconnected.

Changed my public IP in server.log to "1.2.3.4" but everything else is intact, no need to obfuscate my AWS IP as that's temporary.

Thanks!

Hutch

Thanks for responding.

Uninstalled TAP-Windows 9.21.0 and installed TAP-Windows 9.9.2 from the link. Same behavior. Connected, got IP 192.168.200.6, did a telnet to the AWS instance (OpenVPN server).

New client log:
https://dl.dropboxusercontent.com/u/557196/client_tap_9_9_2.log

Plain-text ngrep output from Linux AWS instance on eth0 (no tun0 traffic):

[root@ip-172-30-2-27 ~]# ngrep -d eth0 port 23
interface: eth0 (172.30.2.0/255.255.255.0)
filter: ( port 23 ) and (ip or ip6)
####
T 172.30.2.27:23 -> 1.2.3.4:53185 [AP]
  ..... ..#..'
#
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ......
##
T 172.30.2.27:23 -> 1.2.3.4:53185 [AP]
  ...
#
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  .. ..#..'
##
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ....P....
#
T 172.30.2.27:23 -> 1.2.3.4:53185 [AP]
  ..'.........
#
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ..'...
##
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ....ANSI..
##
T 172.30.2.27:23 -> 1.2.3.4:53185 [AP]
  ...........!
#
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ...
##
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ........!
##
T 172.30.2.27:23 -> 1.2.3.4:53185 [AP]
  ......Amazon Linux AMI release 2014.03..Kernel 3.10.42-52.145.amzn1.x86_64
  on an x86_64..
#
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ...
#
T 172.30.2.27:23 -> 1.2.3.4:53185 [AP]
  ip-172-30-2-27 login:
#
T 1.2.3.4:53185 -> 172.30.2.27:23 [AP]
  ...

Later on I'll try a Linux OpenVPN client to see if it behaves differently.

Thanks!

Hutch

I think what I'm asking for may not be possible with a userspace application like OpenVPN. I was asking if traffic to other services on the OpenVPN server itself would traverse the tunnel, but I don't think this is possible. Toward the end is a possible workaround.

e.g.,

My (temporary) OpenVPN server is an AWS instance with IP 54.165.206.148. OpenVPN is running on UDP 1194. As a test, I installed a telnet service on this AWS instance.

Even if I use 'push "redirect-gateway def1"' to route all traffic over the VPN, traffic to other services on the OpenVPN server itself (54.165.206.148) will not use the tunnel. Traffic to the OpenVPN server will use eth0--it would have to in order for the UDP 1194 to "get there"; traffic to any other IP will use tun0.

mint openvpn # ip route get 8.8.8.8
8.8.8.8 via 192.168.200.5 dev tun0  src 192.168.200.6 
    cache 
mint openvpn # ip route get 54.165.206.148
54.165.206.148 via 10.0.2.2 dev eth0  src 10.0.2.15 
    cache

Therefore any telnet traffic to 54.165.206.148:23 is in cleartext (eth0) even though I have an OpenVPN tunnel established. Traffic to any other IP will traverse the tunnel (tun0) as it's my default route. This intuitively makes sense and I don't think it is a limitation of OpenVPN, just a consequence of a userspace application and how routing works.

As a workaround on a Windows 2008 R2 test VM (OS of eventual production instance), I believe I can accomplish what I want with the following:

1. Assign another IP address (on the same subnet) to the OpenVPN server network interface. Assume OpenVPN server has IP 192.168.1.100/24. Assign additional IP 192.168.1.101/24 to this interface.
2. Run OpenVPN on this interface (listen 192.168.1.101)
3. Configure the OpenVPN client to use this interface and only route 192.168.1.100/32 traffic over it).

remote 192.168.1.101
route-nopull
route 192.168.1.100 255.255.255.255 vpn_gateway

This seems to work. If I establish the tunnel and telnet to 192.168.1.100, the traffic is on the tunnel interface, not the physical interface.

If I've been setting this up wrong and OpenVPN is really supposed to protect other services on the OpenVPN server itself, please let me know. But it doesn't seem possible to me.

Thanks!