2

I am trying to establish a VPN connection on a Raspberry Pi 3 with Raspbian. But I cannot make this work.

I am using VPNBook and I downloaded the .ovpn file in order to use OpenVPN.

Here is the content of the .ovpn file:

client
dev tun3
proto tcp
remote 176.126.237.217 80
remote euro217.vpnbook.com 80
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass pass.txt
comp-lzo
verb 3
cipher AES-128-CBC
fast-io
pull
redirect-gateway
script-security 2

Here is the output I get:

pi@raspberrypi:/etc/openvpn/vpnbook $ sudo openvpn --config vpnbook-euro1-tcp80.ovpn
Wed Feb  8 00:07:45 2017 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Wed Feb  8 00:07:45 2017 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.08
Wed Feb  8 00:07:45 2017 WARNING: file 'pass.txt' is group or others accessible
Wed Feb  8 00:07:45 2017 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Feb  8 00:07:45 2017 NOTE: --fast-io is disabled since we are not using UDP
Wed Feb  8 00:07:45 2017 Socket Buffers: R=[87380->131072] S=[16384->131072]
Wed Feb  8 00:07:45 2017 Attempting to establish TCP connection with [AF_INET]176.126.237.217:80 [nonblock]
Wed Feb  8 00:07:46 2017 TCP connection established with [AF_INET]176.126.237.217:80
Wed Feb  8 00:07:46 2017 TCPv4_CLIENT link local: [undef]
Wed Feb  8 00:07:46 2017 TCPv4_CLIENT link remote: [AF_INET]176.126.237.217:80
Wed Feb  8 00:07:46 2017 TLS: Initial packet from [AF_INET]176.126.237.217:80, sid=f8773375 a8e3c418
Wed Feb  8 00:07:46 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Feb  8 00:07:47 2017 VERIFY OK: depth=1, C=CH, ST=Zurich, L=Zurich, O=vpnbook.com, OU=IT, CN=vpnbook.com, name=vpnbook.com, emailAddress=admin@vpnbook.com
Wed Feb  8 00:07:47 2017 VERIFY OK: depth=0, C=CH, ST=Zurich, L=Zurich, O=vpnbook.com, OU=IT, CN=vpnbook.com, name=vpnbook.com, emailAddress=admin@vpnbook.com
Wed Feb  8 00:07:48 2017 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Feb  8 00:07:48 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb  8 00:07:48 2017 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Feb  8 00:07:48 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb  8 00:07:48 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Feb  8 00:07:48 2017 [vpnbook.com] Peer Connection Initiated with [AF_INET]176.126.237.217:80
Wed Feb  8 00:07:50 2017 SENT CONTROL [vpnbook.com]: 'PUSH_REQUEST' (status=1)
Wed Feb  8 00:07:50 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS  89.233.43.71,dhcp-option DNS  91.239.100.100,route 10.12.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.12.0.6 10.12.0.5'
Wed Feb  8 00:07:50 2017 OPTIONS IMPORT: timers and/or timeouts modified
Wed Feb  8 00:07:50 2017 OPTIONS IMPORT: --ifconfig/up options modified
Wed Feb  8 00:07:50 2017 OPTIONS IMPORT: route options modified
Wed Feb  8 00:07:50 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Feb  8 00:07:50 2017 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=wlan0 HWADDR=b8:27:eb:e3:f8:56
Wed Feb  8 00:07:50 2017 TUN/TAP device tun3 opened
Wed Feb  8 00:07:50 2017 TUN/TAP TX queue length set to 100
Wed Feb  8 00:07:50 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Feb  8 00:07:50 2017 /sbin/ip link set dev tun3 up mtu 1500
Wed Feb  8 00:07:50 2017 /sbin/ip addr add dev tun3 local 10.12.0.6 peer 10.12.0.5
Wed Feb  8 00:07:50 2017 /sbin/ip route add 176.126.237.217/32 via 192.168.0.1
Wed Feb  8 00:07:50 2017 /sbin/ip route add 0.0.0.0/1 via 10.12.0.5
Wed Feb  8 00:07:50 2017 /sbin/ip route add 128.0.0.0/1 via 10.12.0.5
Wed Feb  8 00:07:50 2017 /sbin/ip route add 10.12.0.1/32 via 10.12.0.5
Wed Feb  8 00:07:50 2017 Initialization Sequence Completed

At this point, I cannot access any website (by putting name or IP address). However, I can ping some IP addresses like 216.58.212.99 but not hostnames like www.google.fr.

I thought it was a DNS issue, I tried to search for it and updated my .ovpn file with the following lines:

up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

This didn't change anything.

[EDIT] As I can't ping hostnames, I think I still have a DNS issue. I tried different forum things I saw on internet but none of them worked. Is there a first thing to look at in order to understand why my DNS is not working? Actually, why DNS requests are not going through the tunnel and sent by the VPN server? [/EDIT]

I also tried with another VPN (VPNGate) but I have the same behaviour.

Everything about the network is painfully slow once openvpn is launch. And I don't even know if the tunnel is working.

[EDIT] I actually think that the tunnel is working, but how to be sure without being able to load a single website? Everything is just really slow and I don't know why. It probably comes from my configuration because I guess I'm not the only one using VPNBook, and also tried with another VPN provider with the same result. [/EDIT]

[2nd EDIT]

Still being stuck with this problem, I am reading a tutorial to fully understand how a network is working. For what I can say at the moment, I see 2 strange things in my configuration when the VPN is activated.

First, on the "tun3" interface created for the connection with the VPN, the MAC address is full of 0. Shouldn't it be the same as my other interface?

tun3      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.12.0.170  P-t-P:10.12.0.169  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:126 errors:0 dropped:0 overruns:0 frame:0
          TX packets:358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:16864 (16.4 KiB)  TX bytes:35559 (34.7 KiB)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:e3:f8:56
          inet addr:192.168.0.17  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::6dfb:5d45:2ae7:fe43/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24791 errors:0 dropped:7790 overruns:0 frame:0
          TX packets:19963 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:4974169 (4.7 MiB)  TX bytes:2843776 (2.7 MiB)

Second, the route table (which is displayed very slowly when the VPN is on):

Without VPN:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    303    0        0 wlan0
192.168.0.0     *               255.255.255.0   U     303    0        0 wlan0

With VPN:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.12.0.169     128.0.0.0       UG    0      0        0 tun3
default         192.168.0.1     0.0.0.0         UG    303    0        0 wlan0
10.12.0.1       10.12.0.169     255.255.255.255 UGH   0      0        0 tun3
10.12.0.169     *               255.255.255.255 UH    0      0        0 tun3
128.0.0.0       10.12.0.169     128.0.0.0       UG    0      0        0 tun3
176.126.237.217 192.168.0.1     255.255.255.255 UGH   0      0        0 wlan0
192.168.0.0     *               255.255.255.0   U     303    0        0 wlan0

Here there is 1 gateaway that I can't even ping: 10.12.0.169. Actually I don't even understand why I have this new IP address completely different from the rest of my network. Shouldn't "tun3" also have an IP address like 192.168.0.xxx? Where does this IP address 10.12.0.170 come from? Also, except for the route toward my own local network, shouldn't the gateway be 192.168.0.1 (my internet provider) for all the destinations?

These are the things I find strange at the moment, but I'm still reading the network tutorial and I'll come back with answers if I have some.

[/2nd EDIT]

2

I managed to make it work by installing the resolvconf package and doing an update and upgrade. The strange thing is that I didn't have any message saying that resolvconf was missing. At resolvconf installation, it says it needed to uninstall openresolv, so it was probably using this one instead of resolvconf.

Anyway, this worked at that time and worked after a reboot. After that, I shut my device down, and now, without having done any change, it can't resolve host names. It looks like the resolvconf doesn't do anything.

EDIT: I also removed 'dnsmasq package' and added the following lines in the following files and it's now working.

/etc/host.conf

order hosts,bind # was missing
multi off # was on

/etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns
networks:       files dns # dns was missing

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

However, it can now resolve some names, but not all of them. I can resolve www.google.com, but not torrent.ubuntu.com for example. Even if I use the command dig to specify the DNS I want to use, I can't resolve torrent.ubuntu.com while connected to the VPN. When I'm not connected to the VPN, I can resolve it, and I can also resolve it by using the DNS of my VPN server.

  • You should accept your own answer if it is a solution to your problem. If it's not, delete your answer and update your question. – xhienne Mar 24 '17 at 1:33
  • It was actually a part of the answer, as it wasn't working anymore. I edited my answer to add the missing elements. However, I still have an issue but it seems a bit different, and this post is already too long, so I created another one for it. – artouf06 Mar 29 '17 at 0:02
0

This looks like it's working correctly.

Here is the output I get:

pi@raspberrypi:/etc/openvpn/vpnbook $ sudo openvpn --config vpnbook-euro1-tcp80.ovpn

And then everything stops and I cannot write to the console anymore.

What's happening here is that you've started the OpenVPN client in your terminal session rather than as a service. (This is great for debugging but not so useful otherwise.) The reason you can't write to that terminal window (or console) anymore is that the OpenVPN program hasn't yet finished.

Or if you started it from a remote ssh connection there are more complications also resulting in you unable to enter any more input. (See below.)

One of the apparently intended side-effects of the VPN configuration you've shown is that the network default route is changed to go via VPNBook (the redirect-gateway configuration item). This means that any inbound network connections will be unable to continue. It also means that if your DNS servers are those provided by your ISP you won't be able to use them for resolving addresses because you no longer appear to be on the ISP's managed network so they won't allow the requests.

If you care to update your question to explain in more detail what you're trying to achieve it may be possible for me to update this question with some recommendations.

  • Thanks, I edited the post to give more details. The thing is that I can't use the internet connection once the tunnel is open. And I can connect directly to the device, or in ssh using a local network (192.168.0...). This is still working. – artouf06 Feb 15 '17 at 23:29
  • Please help me! I've been trying to make it work for more than a month now, and I still have no idea of what's going on. Isn't there something wrong on the route table or something? – artouf06 Feb 23 '17 at 23:28
  • My god, what can I do step by step to understand my problem? I've tried thousand of things I found on the internet, without any success. I definitely can't tell all the things I've tried. I actually manage to connect to a single website, cisco, but only with its IP address 72.163.4.161. The "same" configuration (but obviously not the same) on my Windows PC on the same local network works perfectly fine. – artouf06 Mar 16 '17 at 22:10
-3

Something I noticed in one of your edits is that your tun3 adapter is set up for noARP. (UP POINTOPOINT RUNNING NOARP MULTICAST). With ARP not running it won't resolve domain names to IP addresses. Perhaps check the config file for an option to change this.

  • 2
    ARP is needed to associate an IP address to a MAC address. So it concerns only the local network and has nothing to do with the DNS. Moreover, the tun interface created by OpenVPN doesn't have a MAC address. – artouf06 Mar 28 '17 at 23:50
  • Your default gateway is on your local network and it's MAC address is required for destinations outside of your LAN! – Jason Pastorius Mar 29 '17 at 0:09
  • My default gateway is on the IP address given by the VPN server, since the mask is more specific in the route table. This address is associated with the tun interface which doesn't really communicate with other machines, so doesn't need ARP. Once the messages are crypted in the tun interface, they exit from it with the IP of the VPN server as destination. So, on the route table, it has to go to 192.168.0.1, on interface wlan0, which has a MAC address and uses ARP to know the MAC address of 192.168.0.1. – artouf06 Mar 29 '17 at 0:31
  • Layer 2 of the network stack doesn't use IP addresses. It only uses MAC addresses, period. If it doesn't have the MAC address for the default gateway then the frame will not be forwarded. – Jason Pastorius Mar 29 '17 at 0:38
  • But it has a MAC address for the default gateway, it's the MAC address of 192.168.0.1. In the end, everything is still going there. tun3 interface here doesn't physically exist, it's a virtual interface, so how could it send physical data on the network? It doesn't need ARP. Moreover, it is now working and the tun3 interface is still in NOARP, so it's definitely not the issue. – artouf06 Mar 29 '17 at 0:47

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.