1

I recently installed OpenBSD 5.9 and I'm trying to get it functional enough to use as a replacement for Debian. One thing where I hit a brick wall is connecting to my VPN. I use a commercial VPN which I'm happily using under several Linux distros.

The openvpn config file looks like this:

client
dev tun
proto udp
remote germany.vpnprovider.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass
comp-lzo
verb 1
reneg-sec 0
crl-verify crl.pem

This is what I do...

# openvpn /etc/openvpn/Germany.ovpn

output:

Mon Apr 25 00:20:35 2016 OpenVPN 2.3.10 x86_64-unknown-openbsd5.9 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 25 2016
Mon Apr 25 00:20:35 2016 library versions: LibreSSL 2.3.2, LZO 2.09
Enter Auth Username:
Enter Auth Password:
Mon Apr 25 00:21:02 2016 UDPv4 link local: [undef]
Mon Apr 25 00:21:02 2016 UDPv4 link remote: [AF_INET]46.166.190.202:1194
Mon Apr 25 00:21:02 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Apr 25 00:21:02 2016 [VPN PROVIDER] Peer Connection Initiated with [AF_INET]46.166.190.202:1194
Mon Apr 25 00:21:05 2016 TUN/TAP device tun0 exists previously, keep at program end
Mon Apr 25 00:21:05 2016 TUN/TAP device /dev/tun0 opened
Mon Apr 25 00:21:05 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Apr 25 00:21:05 2016 /sbin/ifconfig tun0 10.199.1.6 10.199.1.5 mtu 1500 netmask 255.255.255.255 up
add net 46.166.190.202: gateway 192.168.0.1
add net 0.0.0.0: gateway 10.199.1.5
add net 128.0.0.0: gateway 10.199.1.5
add net 10.199.1.1: gateway 10.199.1.5
Mon Apr 25 00:21:05 2016 Initialization Sequence Completed

The last line seems to indicate that something went right... However, when I want to connect to the internet, I don't get anything. Opening a website in Firefox doesn't work and neither does pinging it.

$ ping -c 3 www.google.com

This just hangs (I don't get any output) However, pinging a nameserver does work.

$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=40.946 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=38.382 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=39.153 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 38.382/39.494/40.946/1.074 ms

I've been hunting the internet for answers and found nothing that works. There is very little information on the subject of using commercial VPNs on OpenBSD. It seems to me that there is a problem with getting an IP for my tun0 or something. I have enabled ip.forwarding and ip6.forwarding in /etc/sysctl.conf and tried other things, but to no avail. Linux uses openresolv to update /etc/resolv.conf, but I have no idea how to implement this in OpenBSD...

UPDATE

As per request, my /etc/resolv.conf after boot (trunk0 ups iwn0 if not connected to ethernet cable):

# Generated by trunk0 dhclient
search home
nameserver 195.130.131.5
nameserver 195.130.130.5
lookup file bind

My resolv.conf doesn't change after connecting to the VPN... So I checked what resolv.conf looks like in Debian when connected to the VPN and I manually changed /etc/resolv.conf on OpenBSD after connecting to the VPN and lo, addresses get resolved and my IP seems to be in Germany (whatismyipaddress.com). Except for adding two nameservers I got throught the Debian .conf, I didn't change anything in the file.

I suppose the problem now is that this doesn't happen automatically. Should I write some script for this or are there better/standardized ways to do this? Am I completely doing it wrong? Where do I go from here?

Thanks for the help so far... My networking knowledge is very limited.

UPDATE 2 (Solved?)

The solution I came up with is the following: As I explained above, I could access the internet once I specified the desired nameservers in /etc/resolv.conf. The problem with this is that dhclient overwrites the contents of this file each time it is run. Putting the nameservers in /etc/resolv.conf.tail doesn't work as this file is sourced after /etc/resolv.conf and the added nameservers aren't chosen first.

My solution was to put them in /etc/dhclient.conf e.g.:

prepend domain-name-servers 210.232.10.246;
prepend ...;

This way, these nameservers are tried first and connecting to the VPN works (semi)automatically, as desired.

What still bothers me a bit is the fact that I had to specify these nameservers. With NetworkManager on Debian, these nameservers are somehow found and dynamically added when connecting to the VPN. If anyone knows more, please enlighten me. Is there a less hackish solution?

Lastly, if no other/better answer comes along, I guess I will add my solution as an "Answer"...

4
  • 1
    What is your /etc/resolv.conf once inside the VPN? Commented Apr 24, 2016 at 23:53
  • Pinging works because you specified the IP, not the hostname, not because it's a nameserver. When the VPN comes up it becomes your default route (add net 0.0.0.0: gateway 10.199.1.5), so all your DNS requests take that route. If your namseserver (see /etc/resolv.conf) can't be found there, or your VPN provider doesn't forward it, you won't be able to resolve hostnames.
    – Zé Loff
    Commented Apr 25, 2016 at 0:01
  • No doubt about it, @ZéLoff; the question is often VPN software overwrite /etc/resolv.confand without the OP providing it, we can only make an educated guess. Commented Apr 25, 2016 at 8:44
  • I updated my question... If I manually change my nameserver(s) in /etc/resolv.conf everything works as expected. I guess the remaining question is: "How do I make this change happen automatically when I connect to the VPN?". Or am I missing something else here?
    – voyager
    Commented Apr 25, 2016 at 16:45

1 Answer 1

0

My solution was to put them in /etc/dhclient.conf e.g.:

prepend domain-name-servers 210.232.10.246;
prepend ...;

This way, these nameservers are tried first, as opposed to when they are put in the /etc/resolv.conf.tail, and connecting to the VPN works (semi)automatically, as desired.

To read more about how arrived to this solution and why I'm not a 100% satisfied with it, see my updated question.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .