3

I use openVPN to connect to a server at work. However, I only want to use the VPN for work-related stuff and not for my regular browsing. I don't really know much about VPNs, so it's entirely possible this is already the case, but I'm not sure.

My current client configuration is:

$ cat CRSSLconfig.tblk/client.ovpn
client
dev tun
port 8440
connect-retry 0
proto tcp-client
remote 123.456.78.9
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass login.conf
comp-lzo
auth-retry interact
verb 3
reneg-sec 0
status crssl_client_status.log
ca ca.pem
cert cert.pem
key userkey.key

And I connect by running

sudo openvpn client.ovpn

In case it's relevant, I am running OpenVPN 2.3.8 on 64 bit Arch.

A reverse DNS lookup on my IP shows that it points to my local ISP:

$ host $(wget -qO - http://wtfismyip.com/text)
252.224.246.46.in-addr.arpa domain name pointer 1.2.3.4.my.isp.com

The output of ip a (22.33.44 IPs are on the VPN):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    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: enp3s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:1f:c6:cb:2f:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global enp3s5
       valid_lft forever preferred_lft forever
    inet6 fe80::1cfa:c27c:6982:369a/64 scope link 
       valid_lft forever preferred_lft forever
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 22.33.44.2/24 brd 22.33.44.255 scope global tun0
       valid_lft forever preferred_lft forever

My routing table as reported by ip route show is:

$ ip route show
default via 192.168.1.1 dev enp3s5  metric 202 
22.33.44.0/24 via 22.33.44.1 dev tun0 
22.33.45.0/24 dev tun0  proto kernel  scope link  src 22.33.45.2 
192.168.1.0/24 dev enp3s5  proto kernel  scope link  src 192.168.1.103  metric 202 

The 22.33.44.NN addresses all correspond to IPs on the VPN network. I have changed the first three digit groups but not the last (so the 22.33.44.1 is actually the gateway, for example).

Is that enough to conclude that normal internet traffic isn't going through the VPN? How can I i) check what connections are being routed through the VPN and ii) configure the VPN to only work for specific connections? I don't have access to the server config, is this something I can configure from the client?

4

You must check the routing table.

With the route command, you can see how you traffic is routed, if there is a line like default 123.456.78.x is likely that your traffic is redirected on the VPN, however if your public ip is your isp it is very likely that the VPN rotate only traffic headed to work.

These lines indicate that the traffic with a destination LAN 22:33:44 or 22:33:45 pass through the VPN:

22.33.44.0/24 via 22.33.44.1 dev tun0 
22.33.45.0/24 dev tun0 proto kernel scope link src 22.33.45.2 

Everything else (destination "default" passes through the card enp3s5 and is directed by the router 192.168.1.1 that is external to the VPN:default via 192.168.1.1 dev enp3s5 metric 202

4
  • Also, check the interface table (ip a or ifconfig -a) and look for a device called tunX (according to dev tun in the config. Then indeed, check the routing table (netstat -rn or ip route) to see what the default or 0.0.0.0 route is and what is pointing to the address configured on the tunX interface. – Lambert Dec 11 '15 at 15:34
  • Lillox and @Lambert please see update. I added the output of ip route show and ip a but I don't really know how to interpret them. Can I safely assume that only connections to the VPN's LAN are routed through it? – terdon Dec 11 '15 at 15:51
  • Yes, your route table show that the traffic to the lan 22.33.45.0/24 will be routed through the VPN(tun0), the remain traffic will be routed via 192.168.1.1, your home router I suppose... – LilloX Dec 11 '15 at 15:56
  • 1
    Another thing to look at is /etc/resolv.conf. Even if normal internet traffic doesn't go through the VPN, DNS lookups might be going there. – cjm Dec 11 '15 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.