OpenVPN client on OpenBSD

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenVPN client on OpenBSD

Emile Sanders
Has anyone ever gotten OpenVPN to run as a client successfully with a VPN
subscription? OpenBSD seems to be the only OS I can't get OpenVPN up
successfully on for some reason, and I'd like to make it work. So I've
confirmed it's not a server-side issue as I've tested it on other operating
systems as well as other people who are currently using the VPN service
without a problem (except none of them are on OpenBSD).

The issue is that when I connect with OpenVPN, it's apparently "connected",
but I can't seem to ping the gateway, any websites such as Google, nor use
any internet-relying services such as browsing to a website or going on IRC.

I am running OpenBSD 4.8 release, with almost a default install. I've just
got openvpn, scrotwm, firefox, and p7zip pkg_added on top of the
barebones/fresh install.

Here are some logs/configs:

/etc/hostname.tun0
$ cat /etc/hostname.tun0
up
!/usr/local/sbin/openvpn --daemon --config /etc/openvpn/client.ovpn

/* I'd like to mention here that even after rebooting, the tun0 interface
does NOT come up. An ifconfig shows that it is still down, and OpenVPN is
not started up at boottime. I have no idea why /etc/hostname.tun0 isn't
being read. */

OpenVPN client config:
$ cat /etc/client.ovpn
# VPN config
ns-cert-type server
tls-client
pull
verb 3
tls-timeout 6
cipher BF-CBC
keysize 256
pkcs12 cert.dat
keepalive 30 120
hand-window 120
route-delay 2
persist-tun
persist-key
redirect-gateway def1
remote-random
route-metric 2
route-method exe
dev tun0
topology subnet
<connection>
proto tcp-client
remote [vpn url] 11000
remote [vpn ip] 11000
connect-retry 10
</connection>
<connection>
proto udp
remote [vpn url] 11000
remote [vpn ip] 11000
</connection>

/* The square brackets contain the URL and IP address of the VPN service I
connect to. I filtered them out as to not spam/advertise their service. */

OpenVPN connection log:

$ sudo openvpn --config /etc/openvpn/client.ovpn
Wed Feb  2 10:19:53 2011 OpenVPN 2.1.0 i386-unknown-openbsd4.8 [SSL] [LZO2]
built on Aug 10 2010
Wed Feb  2 10:19:53 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or
higher to call user-defined scripts or executables
Wed Feb  2 10:19:53 2011 WARNING: file 'cert.dat' is group or others
accessible
Wed Feb  2 10:19:53 2011 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0
ET:0 EL:0 ]
Wed Feb  2 10:19:53 2011 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4
ET:0 EL:0 ]
Wed Feb  2 10:19:53 2011 Local Options hash (VER=V4): '91138c76'
Wed Feb  2 10:19:53 2011 Expected Remote Options hash (VER=V4): 'f5a300ca'
Wed Feb  2 10:19:53 2011 Socket Buffers: R=[41600->65536] S=[9216->65536]
Wed Feb  2 10:19:53 2011 UDPv4 link local (bound): [undef]:1194
Wed Feb  2 10:19:53 2011 UDPv4 link remote: [vpn ip]:11000
Wed Feb  2 10:19:53 2011 TLS: Initial packet from [vpn ip]:11000,
sid=a16fdfdd b22d9c39
Wed Feb  2 10:19:54 2011 VERIFY OK: depth=1, /C=US/ST=NY/L=New_York/O=
example.com/CN=example.com_CA/emailAddress=[hidden email]
Wed Feb  2 10:19:54 2011 VERIFY OK: nsCertType=SERVER
Wed Feb  2 10:19:54 2011 VERIFY OK: depth=0, /C=US/ST=NY/L=New_York/O=
example.com/CN=server/emailAddress=[hidden email]
Wed Feb  2 10:20:02 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 256 bit key
Wed Feb  2 10:20:02 2011 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
Wed Feb  2 10:20:02 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 256 bit key
Wed Feb  2 10:20:02 2011 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
Wed Feb  2 10:20:02 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3
DHE-RSA-AES256-SHA, 2048 bit RSA
Wed Feb  2 10:20:02 2011 [server] Peer Connection Initiated with [vpn
ip]:11000
Wed Feb  2 10:20:04 2011 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Feb  2 10:20:04 2011 PUSH: Received control message: 'PUSH_REPLY,route
10.100.2.0 255.255.255.0,redirect-gateway,dhcp-option DNS
10.100.2.1,route-gateway 10.100.2.1,topology subnet,ping 30,ping-restart
120,ifconfig 10.100.2.106 255.255.255.0'
Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: timers and/or timeouts modified
Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: --ifconfig/up options modified
Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: route options modified
Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: route-related options modified
Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
Wed Feb  2 10:20:04 2011 ROUTE default_gateway=192.168.1.1
Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 destroy
Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 create
Wed Feb  2 10:20:04 2011 NOTE: Tried to delete pre-existing tun/tap instance
-- No Problem if failure
Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 10.100.2.106 netmask
255.255.255.0 mtu 1500 broadcast 10.100.2.255 link0
Wed Feb  2 10:20:04 2011 TUN/TAP device /dev/tun0 opened
Wed Feb  2 10:20:07 2011 /sbin/route add -net [vpn ip] 192.168.1.1 -netmask
255.255.255.255
add net [vpn ip]: gateway 192.168.1.1
Wed Feb  2 10:20:07 2011 /sbin/route add -net 0.0.0.0 10.100.2.1 -netmask
128.0.0.0
add net 0.0.0.0: gateway 10.100.2.1
Wed Feb  2 10:20:07 2011 /sbin/route add -net 128.0.0.0 10.100.2.1 -netmask
128.0.0.0
add net 128.0.0.0: gateway 10.100.2.1
Wed Feb  2 10:20:07 2011 /sbin/route add -net 10.100.2.0 10.100.2.1 -netmask
255.255.255.0
add net 10.100.2.0: gateway 10.100.2.1
Wed Feb  2 10:20:07 2011 Initialization Sequence Completed

Now while OpenVPN is still running, here is the ifconfig:

$ sudo ifconfig -A
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
        priority: 0
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:26:b0:da:a3:86
        priority: 0
        groups: egress
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::226:b0ff:feda:a386%nfe0 prefixlen 64 scopeid 0x1
        inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
        priority: 0
        groups: pflog
tun0: flags=9843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST> mtu 1500
        lladdr fe:e1:ba:d4:20:7e
        priority: 0
        groups: tun
        status: active
        inet 10.100.1.112 netmask 0xffffff00 broadcast 10.100.1.255
        inet6 fe80::fce1:baff:fed4:207e%tun0 prefixlen 64 scopeid 0x6

And the routing table while the OpenVPN is still running:

$ route -n show
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio
Iface
0/1                10.100.1.1         UGS        0        0     -     8 tun0

default            192.168.1.1        UGS        3     1313     -     8 nfe0

10.100.1/24        link#6             UC         1        0     -     4 tun0

10.100.1/24        10.100.1.1         UGS        0        0     -     8 tun0

10.100.1.1         link#6             UHLc       3        0     -     4 tun0

[vpn ip]/32   192.168.1.1        UGS        0        0     -     8 nfe0
127/8              127.0.0.1          UGRS       0        0 33200     8 lo0

127.0.0.1          127.0.0.1          UH         2        0 33200     4 lo0

128/1              10.100.1.1         UGS        0        1     -     8 tun0

192.168.1/24       link#1             UC         1        0     -     4 nfe0

192.168.1.1        00:1f:90:0f:88:8c  UHLc       2       38     -     4 nfe0

192.168.1.4        127.0.0.1          UGHS       0        0 33200     8 lo0

224/4              127.0.0.1          URS        0        0 33200     8 lo0


/* Left out IPv6 */

Just to avoid any misunderstanding, I'd like to add that everything (the
internet) works fine without OpenVPN running, I just run into this issue
with OpenVPN.

Is this some sort of routing issue? I'm not sure what the networking of
other operating systems do with a VPN that makes them just work out of the
box.
I cannot ping 10.100.1.1, 10.100.2.1 and 8.8.8.8 while on the VPN, so isn't
it like I'm almost not even on the VPN at all even though I am supposedly
"connected" as the OpenVPN log shows?

I just get this when I try to ping any website while the OpenVPN is running:

$ ping google.com
PING google.com (74.125.226.145): 56 data bytes
ping: sendto: No route to host
ping: wrote google.com 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote google.com 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote google.com 64 chars, ret=-1
--- google.com ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss

Here I am trying to ping the gateway whilst OpenVPN is running:

$ ping 10.100.1.1
PING 10.100.1.1 (10.100.1.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 10.100.1.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 10.100.1.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 10.100.1.1 64 chars, ret=-1
ping: sendto: No route to host

$ ping 10.100.2.1
PING 10.100.2.1 (10.100.2.1): 56 data bytes
ping: sendto: Host is down
ping: wrote 10.100.2.1 64 chars, ret=-1
ping: sendto: Host is down
ping: wrote 10.100.2.1 64 chars, ret=-1
ping: sendto: Host is down

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: wrote 8.8.8.8 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 8.8.8.8 64 chars, ret=-1
ping: sendto: No route to host

Does anyone know how to successfully run OpenVPN on OpenBSD as a client with
a VPN subscription? Or run into similar problems?

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPN client on OpenBSD

Emile Sanders
Errr...sorry for the double-post...it's my first time using a mailing list
and I thought my first e-mail wasn't going through so I sent another
one...please ignore the first post...

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPN client on OpenBSD

Ivan Nudzik
In reply to this post by Emile Sanders
Hi,
Remove folloving line from OpenVPN config:
redirect-gateway def1

It redirects your default gateway to tunnel you have just opened.
Btw you have copied /etc/hostname.tun0 from install suggestion, but this
is not the only right way to start it. I found that it is better to
setup tunnel device, assign IP, routes and PF settings usual way as any
other interface, then start OpenVPN in /etc/rc.local. Of course then no
IP, route settings in OpenVPN config. Start/Stop of OpenVPN then behaves
the same way as plug/unplug cable to net device. Best setup for
permanent VPNs, also LAN bridges over VPN works well this way.
For 'roadwarrior' VPNs it is better to write own simple up/down scripts
to create tun device and setup IPs/routes, than mixing it with OpenBSD
netstart script and semi universal ifconfig abilities of OpenVPN.

I.

On Wed, 2011-02-02 at 11:17 -0500, Emile Sanders wrote:

> Has anyone ever gotten OpenVPN to run as a client successfully with a VPN
> subscription? OpenBSD seems to be the only OS I can't get OpenVPN up
> successfully on for some reason, and I'd like to make it work. So I've
> confirmed it's not a server-side issue as I've tested it on other operating
> systems as well as other people who are currently using the VPN service
> without a problem (except none of them are on OpenBSD).
>
> The issue is that when I connect with OpenVPN, it's apparently "connected",
> but I can't seem to ping the gateway, any websites such as Google, nor use
> any internet-relying services such as browsing to a website or going on IRC.
>
> I am running OpenBSD 4.8 release, with almost a default install. I've just
> got openvpn, scrotwm, firefox, and p7zip pkg_added on top of the
> barebones/fresh install.
>
> Here are some logs/configs:
>
> /etc/hostname.tun0
> $ cat /etc/hostname.tun0
> up
> !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/client.ovpn
>
> /* I'd like to mention here that even after rebooting, the tun0 interface
> does NOT come up. An ifconfig shows that it is still down, and OpenVPN is
> not started up at boottime. I have no idea why /etc/hostname.tun0 isn't
> being read. */
>
> OpenVPN client config:
> $ cat /etc/client.ovpn
> # VPN config
> ns-cert-type server
> tls-client
> pull
> verb 3
> tls-timeout 6
> cipher BF-CBC
> keysize 256
> pkcs12 cert.dat
> keepalive 30 120
> hand-window 120
> route-delay 2
> persist-tun
> persist-key
> redirect-gateway def1
> remote-random
> route-metric 2
> route-method exe
> dev tun0
> topology subnet
> <connection>
> proto tcp-client
> remote [vpn url] 11000
> remote [vpn ip] 11000
> connect-retry 10
> </connection>
> <connection>
> proto udp
> remote [vpn url] 11000
> remote [vpn ip] 11000
> </connection>
>
> /* The square brackets contain the URL and IP address of the VPN service I
> connect to. I filtered them out as to not spam/advertise their service. */
>
> OpenVPN connection log:
>
> $ sudo openvpn --config /etc/openvpn/client.ovpn
> Wed Feb  2 10:19:53 2011 OpenVPN 2.1.0 i386-unknown-openbsd4.8 [SSL] [LZO2]
> built on Aug 10 2010
> Wed Feb  2 10:19:53 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or
> higher to call user-defined scripts or executables
> Wed Feb  2 10:19:53 2011 WARNING: file 'cert.dat' is group or others
> accessible
> Wed Feb  2 10:19:53 2011 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0
> ET:0 EL:0 ]
> Wed Feb  2 10:19:53 2011 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4
> ET:0 EL:0 ]
> Wed Feb  2 10:19:53 2011 Local Options hash (VER=V4): '91138c76'
> Wed Feb  2 10:19:53 2011 Expected Remote Options hash (VER=V4): 'f5a300ca'
> Wed Feb  2 10:19:53 2011 Socket Buffers: R=[41600->65536] S=[9216->65536]
> Wed Feb  2 10:19:53 2011 UDPv4 link local (bound): [undef]:1194
> Wed Feb  2 10:19:53 2011 UDPv4 link remote: [vpn ip]:11000
> Wed Feb  2 10:19:53 2011 TLS: Initial packet from [vpn ip]:11000,
> sid=a16fdfdd b22d9c39
> Wed Feb  2 10:19:54 2011 VERIFY OK: depth=1, /C=US/ST=NY/L=New_York/O=
> example.com/CN=example.com_CA/emailAddress=[hidden email]
> Wed Feb  2 10:19:54 2011 VERIFY OK: nsCertType=SERVER
> Wed Feb  2 10:19:54 2011 VERIFY OK: depth=0, /C=US/ST=NY/L=New_York/O=
> example.com/CN=server/emailAddress=[hidden email]
> Wed Feb  2 10:20:02 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized
> with 256 bit key
> Wed Feb  2 10:20:02 2011 Data Channel Encrypt: Using 160 bit message hash
> 'SHA1' for HMAC authentication
> Wed Feb  2 10:20:02 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized
> with 256 bit key
> Wed Feb  2 10:20:02 2011 Data Channel Decrypt: Using 160 bit message hash
> 'SHA1' for HMAC authentication
> Wed Feb  2 10:20:02 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3
> DHE-RSA-AES256-SHA, 2048 bit RSA
> Wed Feb  2 10:20:02 2011 [server] Peer Connection Initiated with [vpn
> ip]:11000
> Wed Feb  2 10:20:04 2011 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
> Wed Feb  2 10:20:04 2011 PUSH: Received control message: 'PUSH_REPLY,route
> 10.100.2.0 255.255.255.0,redirect-gateway,dhcp-option DNS
> 10.100.2.1,route-gateway 10.100.2.1,topology subnet,ping 30,ping-restart
> 120,ifconfig 10.100.2.106 255.255.255.0'
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: timers and/or timeouts modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: --ifconfig/up options modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: route options modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: route-related options modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
> options modified
> Wed Feb  2 10:20:04 2011 ROUTE default_gateway=192.168.1.1
> Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 destroy
> Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 create
> Wed Feb  2 10:20:04 2011 NOTE: Tried to delete pre-existing tun/tap instance
> -- No Problem if failure
> Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 10.100.2.106 netmask
> 255.255.255.0 mtu 1500 broadcast 10.100.2.255 link0
> Wed Feb  2 10:20:04 2011 TUN/TAP device /dev/tun0 opened
> Wed Feb  2 10:20:07 2011 /sbin/route add -net [vpn ip] 192.168.1.1 -netmask
> 255.255.255.255
> add net [vpn ip]: gateway 192.168.1.1
> Wed Feb  2 10:20:07 2011 /sbin/route add -net 0.0.0.0 10.100.2.1 -netmask
> 128.0.0.0
> add net 0.0.0.0: gateway 10.100.2.1
> Wed Feb  2 10:20:07 2011 /sbin/route add -net 128.0.0.0 10.100.2.1 -netmask
> 128.0.0.0
> add net 128.0.0.0: gateway 10.100.2.1
> Wed Feb  2 10:20:07 2011 /sbin/route add -net 10.100.2.0 10.100.2.1 -netmask
> 255.255.255.0
> add net 10.100.2.0: gateway 10.100.2.1
> Wed Feb  2 10:20:07 2011 Initialization Sequence Completed
>
> Now while OpenVPN is still running, here is the ifconfig:
>
> $ sudo ifconfig -A
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
>         priority: 0
>         groups: lo
>         inet 127.0.0.1 netmask 0xff000000
>         inet6 ::1 prefixlen 128
>         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         lladdr 00:26:b0:da:a3:86
>         priority: 0
>         groups: egress
>         media: Ethernet autoselect (100baseTX full-duplex)
>         status: active
>         inet6 fe80::226:b0ff:feda:a386%nfe0 prefixlen 64 scopeid 0x1
>         inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255
> enc0: flags=0<>
>         priority: 0
>         groups: enc
>         status: active
> pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
>         priority: 0
>         groups: pflog
> tun0: flags=9843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST> mtu 1500
>         lladdr fe:e1:ba:d4:20:7e
>         priority: 0
>         groups: tun
>         status: active
>         inet 10.100.1.112 netmask 0xffffff00 broadcast 10.100.1.255
>         inet6 fe80::fce1:baff:fed4:207e%tun0 prefixlen 64 scopeid 0x6
>
> And the routing table while the OpenVPN is still running:
>
> $ route -n show
> Routing tables
>
> Internet:
> Destination        Gateway            Flags   Refs      Use   Mtu  Prio
> Iface
> 0/1                10.100.1.1         UGS        0        0     -     8 tun0
>
> default            192.168.1.1        UGS        3     1313     -     8 nfe0
>
> 10.100.1/24        link#6             UC         1        0     -     4 tun0
>
> 10.100.1/24        10.100.1.1         UGS        0        0     -     8 tun0
>
> 10.100.1.1         link#6             UHLc       3        0     -     4 tun0
>
> [vpn ip]/32   192.168.1.1        UGS        0        0     -     8 nfe0
> 127/8              127.0.0.1          UGRS       0        0 33200     8 lo0
>
> 127.0.0.1          127.0.0.1          UH         2        0 33200     4 lo0
>
> 128/1              10.100.1.1         UGS        0        1     -     8 tun0
>
> 192.168.1/24       link#1             UC         1        0     -     4 nfe0
>
> 192.168.1.1        00:1f:90:0f:88:8c  UHLc       2       38     -     4 nfe0
>
> 192.168.1.4        127.0.0.1          UGHS       0        0 33200     8 lo0
>
> 224/4              127.0.0.1          URS        0        0 33200     8 lo0
>
>
> /* Left out IPv6 */
>
> Just to avoid any misunderstanding, I'd like to add that everything (the
> internet) works fine without OpenVPN running, I just run into this issue
> with OpenVPN.
>
> Is this some sort of routing issue? I'm not sure what the networking of
> other operating systems do with a VPN that makes them just work out of the
> box.
> I cannot ping 10.100.1.1, 10.100.2.1 and 8.8.8.8 while on the VPN, so isn't
> it like I'm almost not even on the VPN at all even though I am supposedly
> "connected" as the OpenVPN log shows?
>
> I just get this when I try to ping any website while the OpenVPN is running:
>
> $ ping google.com
> PING google.com (74.125.226.145): 56 data bytes
> ping: sendto: No route to host
> ping: wrote google.com 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote google.com 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote google.com 64 chars, ret=-1
> --- google.com ping statistics ---
> 9 packets transmitted, 0 packets received, 100.0% packet loss
>
> Here I am trying to ping the gateway whilst OpenVPN is running:
>
> $ ping 10.100.1.1
> PING 10.100.1.1 (10.100.1.1): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 10.100.1.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 10.100.1.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 10.100.1.1 64 chars, ret=-1
> ping: sendto: No route to host
>
> $ ping 10.100.2.1
> PING 10.100.2.1 (10.100.2.1): 56 data bytes
> ping: sendto: Host is down
> ping: wrote 10.100.2.1 64 chars, ret=-1
> ping: sendto: Host is down
> ping: wrote 10.100.2.1 64 chars, ret=-1
> ping: sendto: Host is down
>
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 8.8.8.8 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 8.8.8.8 64 chars, ret=-1
> ping: sendto: No route to host
>
> Does anyone know how to successfully run OpenVPN on OpenBSD as a client with
> a VPN subscription? Or run into similar problems?

Reply | Threaded
Open this post in threaded view
|

OpenVPN client on OpenBSD

Paolo Aglialoro
In reply to this post by Emile Sanders
A passionate piece of advice:

use OpenVPN in bridge mode (tap and tcp) to allow machines easily see one
other and have fun with pinging galore :))))



On Wed, Feb 2, 2011 at 5:17 PM, Emile Sanders <[hidden email]>wrote:

> Has anyone ever gotten OpenVPN to run as a client successfully with a VPN
> subscription? OpenBSD seems to be the only OS I can't get OpenVPN up
> successfully on for some reason, and I'd like to make it work. So I've
> confirmed it's not a server-side issue as I've tested it on other operating
> systems as well as other people who are currently using the VPN service
> without a problem (except none of them are on OpenBSD).
>
> The issue is that when I connect with OpenVPN, it's apparently "connected",
> but I can't seem to ping the gateway, any websites such as Google, nor use
> any internet-relying services such as browsing to a website or going on
> IRC.
>
> I am running OpenBSD 4.8 release, with almost a default install. I've just
> got openvpn, scrotwm, firefox, and p7zip pkg_added on top of the
> barebones/fresh install.
>
> Here are some logs/configs:
>
> /etc/hostname.tun0
> $ cat /etc/hostname.tun0
> up
> !/usr/local/sbin/openvpn --daemon --config /etc/openvpn/client.ovpn
>
> /* I'd like to mention here that even after rebooting, the tun0 interface
> does NOT come up. An ifconfig shows that it is still down, and OpenVPN is
> not started up at boottime. I have no idea why /etc/hostname.tun0 isn't
> being read. */
>
> OpenVPN client config:
> $ cat /etc/client.ovpn
> # VPN config
> ns-cert-type server
> tls-client
> pull
> verb 3
> tls-timeout 6
> cipher BF-CBC
> keysize 256
> pkcs12 cert.dat
> keepalive 30 120
> hand-window 120
> route-delay 2
> persist-tun
> persist-key
> redirect-gateway def1
> remote-random
> route-metric 2
> route-method exe
> dev tun0
> topology subnet
> <connection>
> proto tcp-client
> remote [vpn url] 11000
> remote [vpn ip] 11000
> connect-retry 10
> </connection>
> <connection>
> proto udp
> remote [vpn url] 11000
> remote [vpn ip] 11000
> </connection>
>
> /* The square brackets contain the URL and IP address of the VPN service I
> connect to. I filtered them out as to not spam/advertise their service. */
>
> OpenVPN connection log:
>
> $ sudo openvpn --config /etc/openvpn/client.ovpn
> Wed Feb  2 10:19:53 2011 OpenVPN 2.1.0 i386-unknown-openbsd4.8 [SSL] [LZO2]
> built on Aug 10 2010
> Wed Feb  2 10:19:53 2011 NOTE: OpenVPN 2.1 requires '--script-security 2'
> or
> higher to call user-defined scripts or executables
> Wed Feb  2 10:19:53 2011 WARNING: file 'cert.dat' is group or others
> accessible
> Wed Feb  2 10:19:53 2011 Control Channel MTU parms [ L:1541 D:138 EF:38
> EB:0
> ET:0 EL:0 ]
> Wed Feb  2 10:19:53 2011 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4
> ET:0 EL:0 ]
> Wed Feb  2 10:19:53 2011 Local Options hash (VER=V4): '91138c76'
> Wed Feb  2 10:19:53 2011 Expected Remote Options hash (VER=V4): 'f5a300ca'
> Wed Feb  2 10:19:53 2011 Socket Buffers: R=[41600->65536] S=[9216->65536]
> Wed Feb  2 10:19:53 2011 UDPv4 link local (bound): [undef]:1194
> Wed Feb  2 10:19:53 2011 UDPv4 link remote: [vpn ip]:11000
> Wed Feb  2 10:19:53 2011 TLS: Initial packet from [vpn ip]:11000,
> sid=a16fdfdd b22d9c39
> Wed Feb  2 10:19:54 2011 VERIFY OK: depth=1, /C=US/ST=NY/L=New_York/O=
> example.com/CN=example.com_CA/emailAddress=[hidden email]
> Wed Feb  2 10:19:54 2011 VERIFY OK: nsCertType=SERVER
> Wed Feb  2 10:19:54 2011 VERIFY OK: depth=0, /C=US/ST=NY/L=New_York/O=
> example.com/CN=server/emailAddress=[hidden email]
> Wed Feb  2 10:20:02 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized
> with 256 bit key
> Wed Feb  2 10:20:02 2011 Data Channel Encrypt: Using 160 bit message hash
> 'SHA1' for HMAC authentication
> Wed Feb  2 10:20:02 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized
> with 256 bit key
> Wed Feb  2 10:20:02 2011 Data Channel Decrypt: Using 160 bit message hash
> 'SHA1' for HMAC authentication
> Wed Feb  2 10:20:02 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3
> DHE-RSA-AES256-SHA, 2048 bit RSA
> Wed Feb  2 10:20:02 2011 [server] Peer Connection Initiated with [vpn
> ip]:11000
> Wed Feb  2 10:20:04 2011 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
> Wed Feb  2 10:20:04 2011 PUSH: Received control message: 'PUSH_REPLY,route
> 10.100.2.0 255.255.255.0,redirect-gateway,dhcp-option DNS
> 10.100.2.1,route-gateway 10.100.2.1,topology subnet,ping 30,ping-restart
> 120,ifconfig 10.100.2.106 255.255.255.0'
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: timers and/or timeouts modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: --ifconfig/up options modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: route options modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: route-related options modified
> Wed Feb  2 10:20:04 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
> options modified
> Wed Feb  2 10:20:04 2011 ROUTE default_gateway=192.168.1.1
> Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 destroy
> Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 create
> Wed Feb  2 10:20:04 2011 NOTE: Tried to delete pre-existing tun/tap
> instance
> -- No Problem if failure
> Wed Feb  2 10:20:04 2011 /sbin/ifconfig tun0 10.100.2.106 netmask
> 255.255.255.0 mtu 1500 broadcast 10.100.2.255 link0
> Wed Feb  2 10:20:04 2011 TUN/TAP device /dev/tun0 opened
> Wed Feb  2 10:20:07 2011 /sbin/route add -net [vpn ip] 192.168.1.1 -netmask
> 255.255.255.255
> add net [vpn ip]: gateway 192.168.1.1
> Wed Feb  2 10:20:07 2011 /sbin/route add -net 0.0.0.0 10.100.2.1 -netmask
> 128.0.0.0
> add net 0.0.0.0: gateway 10.100.2.1
> Wed Feb  2 10:20:07 2011 /sbin/route add -net 128.0.0.0 10.100.2.1 -netmask
> 128.0.0.0
> add net 128.0.0.0: gateway 10.100.2.1
> Wed Feb  2 10:20:07 2011 /sbin/route add -net 10.100.2.0 10.100.2.1
> -netmask
> 255.255.255.0
> add net 10.100.2.0: gateway 10.100.2.1
> Wed Feb  2 10:20:07 2011 Initialization Sequence Completed
>
> Now while OpenVPN is still running, here is the ifconfig:
>
> $ sudo ifconfig -A
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
>        priority: 0
>        groups: lo
>        inet 127.0.0.1 netmask 0xff000000
>        inet6 ::1 prefixlen 128
>        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        lladdr 00:26:b0:da:a3:86
>        priority: 0
>        groups: egress
>        media: Ethernet autoselect (100baseTX full-duplex)
>        status: active
>        inet6 fe80::226:b0ff:feda:a386%nfe0 prefixlen 64 scopeid 0x1
>        inet 192.168.1.4 netmask 0xffffff00 broadcast 192.168.1.255
> enc0: flags=0<>
>        priority: 0
>        groups: enc
>        status: active
> pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
>        priority: 0
>        groups: pflog
> tun0: flags=9843<UP,BROADCAST,RUNNING,SIMPLEX,LINK0,MULTICAST> mtu 1500
>        lladdr fe:e1:ba:d4:20:7e
>        priority: 0
>        groups: tun
>        status: active
>        inet 10.100.1.112 netmask 0xffffff00 broadcast 10.100.1.255
>        inet6 fe80::fce1:baff:fed4:207e%tun0 prefixlen 64 scopeid 0x6
>
> And the routing table while the OpenVPN is still running:
>
> $ route -n show
> Routing tables
>
> Internet:
> Destination        Gateway            Flags   Refs      Use   Mtu  Prio
> Iface
> 0/1                10.100.1.1         UGS        0        0     -     8
> tun0
>
> default            192.168.1.1        UGS        3     1313     -     8
> nfe0
>
> 10.100.1/24        link#6             UC         1        0     -     4
> tun0
>
> 10.100.1/24        10.100.1.1         UGS        0        0     -     8
> tun0
>
> 10.100.1.1         link#6             UHLc       3        0     -     4
> tun0
>
> [vpn ip]/32   192.168.1.1        UGS        0        0     -     8 nfe0
> 127/8              127.0.0.1          UGRS       0        0 33200     8 lo0
>
> 127.0.0.1          127.0.0.1          UH         2        0 33200     4 lo0
>
> 128/1              10.100.1.1         UGS        0        1     -     8
> tun0
>
> 192.168.1/24       link#1             UC         1        0     -     4
> nfe0
>
> 192.168.1.1        00:1f:90:0f:88:8c  UHLc       2       38     -     4
> nfe0
>
> 192.168.1.4        127.0.0.1          UGHS       0        0 33200     8 lo0
>
> 224/4              127.0.0.1          URS        0        0 33200     8 lo0
>
>
> /* Left out IPv6 */
>
> Just to avoid any misunderstanding, I'd like to add that everything (the
> internet) works fine without OpenVPN running, I just run into this issue
> with OpenVPN.
>
> Is this some sort of routing issue? I'm not sure what the networking of
> other operating systems do with a VPN that makes them just work out of the
> box.
> I cannot ping 10.100.1.1, 10.100.2.1 and 8.8.8.8 while on the VPN, so isn't
> it like I'm almost not even on the VPN at all even though I am supposedly
> "connected" as the OpenVPN log shows?
>
> I just get this when I try to ping any website while the OpenVPN is
> running:
>
> $ ping google.com
> PING google.com (74.125.226.145): 56 data bytes
> ping: sendto: No route to host
> ping: wrote google.com 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote google.com 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote google.com 64 chars, ret=-1
> --- google.com ping statistics ---
> 9 packets transmitted, 0 packets received, 100.0% packet loss
>
> Here I am trying to ping the gateway whilst OpenVPN is running:
>
> $ ping 10.100.1.1
> PING 10.100.1.1 (10.100.1.1): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 10.100.1.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 10.100.1.1 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 10.100.1.1 64 chars, ret=-1
> ping: sendto: No route to host
>
> $ ping 10.100.2.1
> PING 10.100.2.1 (10.100.2.1): 56 data bytes
> ping: sendto: Host is down
> ping: wrote 10.100.2.1 64 chars, ret=-1
> ping: sendto: Host is down
> ping: wrote 10.100.2.1 64 chars, ret=-1
> ping: sendto: Host is down
>
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> ping: sendto: No route to host
> ping: wrote 8.8.8.8 64 chars, ret=-1
> ping: sendto: No route to host
> ping: wrote 8.8.8.8 64 chars, ret=-1
> ping: sendto: No route to host
>
> Does anyone know how to successfully run OpenVPN on OpenBSD as a client
> with
> a VPN subscription? Or run into similar problems?

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPN client on OpenBSD

crazy-7
In reply to this post by Emile Sanders
Okay, so I am almost positive that the issue lies within the
creation of tun0 at the time of OpenVPN startup:

/sbin/ifconfig tun0 10.100.1.112 netmask 255.255.255.0 mtu 1500
broadcast 10.100.1.255 link0

The 'link0' section that OpenVPN adds on is layer 2, while tun
devices are layer 3. For some reason OpenBSD is forcing OpenVPN to
do 'link0' and there is no way to stop it, no matter how many
options I specified in OpenVPN to use tun/tun0 as layer 3.

Does anyone know how to disable this behavior in OpenBSD for
OpenVPN? Even if I manually remove the link0 flag with ifconfig,
upon OpenVPN startup it destroys/re-creates the tun0 device with
link0 by default. This behavior is only consistent with OpenBSD. If
I remove the link0 flag from tun0 after I am connected to the VPN,
it promptly brings down the status tun0 entirely.

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPN client on OpenBSD

Tasmanian Devil
2011/2/6  <[hidden email]>:

> Okay, so I am almost positive that the issue lies within the
> creation of tun0 at the time of OpenVPN startup:
>
> /sbin/ifconfig tun0 10.100.1.112 netmask 255.255.255.0 mtu 1500
> broadcast 10.100.1.255 link0
>
> The 'link0' section that OpenVPN adds on is layer 2, while tun
> devices are layer 3. For some reason OpenBSD is forcing OpenVPN to
> do 'link0' and there is no way to stop it, no matter how many
> options I specified in OpenVPN to use tun/tun0 as layer 3.

I had the same problem once. Not sure why OpenVPN does it this way on
OpenBSD, but you can easily do whatever you want in startup script(s).
Something like this:

/usr/local/sbin/openvpn --dev tun0 --route-noexec --ifconfig-noexec \
         --up /etc/openvpn/updown --down /etc/openvpn/updown ...

and then in updown things like:

if [ ${script_type} = "up" -a ${script_context} = "init" ]; then
        ...
        /sbin/ifconfig $dev $ifconfig_local $trusted_ip \
                mtu $tun_mtu netmask ...
        /sbin/route ...
        /sbin/pfctl ...
        ...
fi
if [ ${script_context} = "restart" ]; then
        ...
fi
if [ ${script_type} = "down" -a ${script_context} = "init" ]; then
        ...
fi

You have a lot of variables available, already set to the values you
need for your commands. Just add an "env" to the script on a first run
to get all the variables logged.


> Does anyone know how to disable this behavior in OpenBSD for
> OpenVPN? Even if I manually remove the link0 flag with ifconfig,
> upon OpenVPN startup it destroys/re-creates the tun0 device with
> link0 by default. This behavior is only consistent with OpenBSD. If
> I remove the link0 flag from tun0 after I am connected to the VPN,
> it promptly brings down the status tun0 entirely.

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPN client on OpenBSD

Stuart Henderson
In reply to this post by crazy-7
On 2011-02-06, [hidden email] <[hidden email]> wrote:

> Okay, so I am almost positive that the issue lies within the
> creation of tun0 at the time of OpenVPN startup:
>
> /sbin/ifconfig tun0 10.100.1.112 netmask 255.255.255.0 mtu 1500
> broadcast 10.100.1.255 link0
>
> The 'link0' section that OpenVPN adds on is layer 2, while tun
> devices are layer 3. For some reason OpenBSD is forcing OpenVPN to
> do 'link0' and there is no way to stop it, no matter how many
> options I specified in OpenVPN to use tun/tun0 as layer 3.

Check that you have configured dev-type correctly.
(We should probably add dev-type to the sample config
files in the package sometime).

Reply | Threaded
Open this post in threaded view
|

Re: OpenVPN client on OpenBSD

Floor Terra
In reply to this post by Emile Sanders
On Wed, Feb 2, 2011 at 5:17 PM, Emile Sanders <[hidden email]> wrote:
> Has anyone ever gotten OpenVPN to run as a client successfully with a VPN
> subscription?

Yes.

> Does anyone know how to successfully run OpenVPN on OpenBSD as a client with
> a VPN subscription? Or run into similar problems?

Here is my config:
$ cat openvpn.conf
client
dev tun0
proto udp
remote $HOSTNAME 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca $CERT_PATH/ca.crt
cert $CERT_PATH/anonymous.crt
key $CERT_PATH/anonymous.key
ns-cert-type server
comp-lzo
verb 3

Replace $HOSTNAME and $CERT_PATH with your own values.

Floor


--
Floor Terra <[hidden email]>
www: http://brobding.mine.nu/