RAK gateway OpenVPN configuration for Pritunl

jpmeijers · February 12, 2020, 9:15am

On the TTN Slack someone recommended using Pritunl (https://pritunl.com/) as a server for OpenVPN clients. This allows proper management via a web interface of VPN users.

I tried configuring the OpenVPN client on my RAK gateway to connect to the Pritunl server. I’ve tried both setting the configuration via LuCi, as well as via the terminal. At the moment it does not seem that the VPN connect. I also do not see any mentions of OpenVPN in the logfile.

It would be nice if a tutorial can be written to show how to configure the OpenVPN client to connect to a Pritunl server, as this sounds like a common use case.

jpmeijers · February 12, 2020, 9:46am


Wed Feb 12 09:42:34 2020 daemon.err openvpn(pritunl_ssh_gateway)[1675]: TLS Error: TLS key negotiation failed to occur within 70 seconds (check your network connectivity)
Wed Feb 12 09:42:34 2020 daemon.err openvpn(pritunl_ssh_gateway)[1675]: TLS Error: TLS handshake failed
Wed Feb 12 09:42:34 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1675]: SIGUSR1[soft,tls-error] received, process restarting
Wed Feb 12 09:42:36 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1675]: UDPv4 link local: [undef]
Wed Feb 12 09:42:36 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1675]: UDPv4 link remote: [AF_INET]35.206.188.178:16330

Wed Feb 12 09:42:43 2020 daemon.err openvpn(pritunl_ssh_gateway)[1675]: event_wait : Interrupted system call (code=4)
Wed Feb 12 09:42:43 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1675]: SIGTERM[hard,] received, process exiting

Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: OpenVPN 2.3.6 mipsel-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jan  8 2020
Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.08
Wed Feb 12 09:42:49 2020 daemon.warn openvpn(pritunl_ssh_gateway)[2986]: WARNING: file '/etc/openvpn/cbid.openvpn.pritunl_ssh_gateway.key' is group or others accessible
Wed Feb 12 09:42:49 2020 daemon.warn openvpn(pritunl_ssh_gateway)[2986]: WARNING: file '/etc/openvpn/cbid.openvpn.pritunl_ssh_gateway.tls_auth.key' is group or others accessible
Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: Control Channel Authentication: using '/etc/openvpn/cbid.openvpn.pritunl_ssh_gateway.tls_auth.key' as a OpenVPN static key file
Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: UDPv4 link local: [undef]
Wed Feb 12 09:42:49 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: UDPv4 link remote: [AF_INET]35.206.188.178:16330


Wed Feb 12 09:43:59 2020 daemon.err openvpn(pritunl_ssh_gateway)[2986]: TLS Error: TLS key negotiation failed to occur within 70 seconds (check your network connectivity)
Wed Feb 12 09:43:59 2020 daemon.err openvpn(pritunl_ssh_gateway)[2986]: TLS Error: TLS handshake failed
Wed Feb 12 09:43:59 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: SIGUSR1[soft,tls-error] received, process restarting
Wed Feb 12 09:44:01 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: UDPv4 link local: [undef]
Wed Feb 12 09:44:01 2020 daemon.notice openvpn(pritunl_ssh_gateway)[2986]: UDPv4 link remote: [AF_INET]35.206.188.178:16330

jpmeijers · February 12, 2020, 10:25am

I actually managed to solve this.

/etc/config/openvpn should contain an entry that looks like this:

config openvpn 'pritunl_ssh_gateway'
        option config '/etc/openvpn/UsersConfigDownloadedFromPritunl.ovpn'
        option enabled '1'

And then copy the contents of the config file you donwloaded into /etc/openvpn/UsersConfigDownloadedFromPritunl.ovpn

yutao · February 13, 2020, 9:48am

Hi:
There is a beta version that supports custom openvpn tunnel configuration via WEB Console.
You can input the configuration directly in web console. Also can upload files like cert/key.
You can send a e-mail to me if you want to try this. [email protected]

yutao · February 16, 2020, 12:44pm

You can get the last firmware there -
https://downloads.rakwireless.com/en/LoRa/DIY-Gateway-RAK7249/Firmware/RAK7249_Latest_Firmware.zip

cristianh · March 6, 2020, 4:58pm

Hello

I.ve try it with file generated by openvpn server and did not work.

When i try to upload file that is the result:

/usr/lib/lua/luci/dispatcher.lua:433: Failed to execute cbi dispatcher target for entry ‘/admin/services/openvpn/edit/custon_client’.
The called action terminated with an exception:
/usr/lib/lua/luci/model/cbi/openvpn_edit.lua:312: attempt to concatenate a nil value
stack traceback:
[C]: in function ‘assert’
/usr/lib/lua/luci/dispatcher.lua:433: in function ‘dispatch’
/usr/lib/lua/luci/dispatcher.lua:168: in function </usr/lib/lua/luci/dispatcher.lua:167>

Could you explain pls step by step how we supouse to setting vpn client?

I think one tutorial about setting vpn client with *.ovpn file will help a lot of people

Thx!

yutao · March 8, 2020, 12:31am

I think there is a bug with openvpn custom configuration. I will fix it

cristianh · March 8, 2020, 1:43am

Thx! Also i think you should consider to update openvpn package from 2.3.7 (is verry old) to a new version of openvpn…This version do not support tls-crypt
You can find more about it on:
https://forums.openvpn.net/viewtopic.php?f=5&t=29064

yutao · March 12, 2020, 8:56am

Hi
I have fixed that bug and upgraded the version of openvpn to 2.4.3. The firmware is undergoing final testing. If you wish to try the new version, please contact me using email and I will send you the firmware. [email protected]

jpmeijers · March 16, 2020, 1:21pm

I have mixed results with the latest firmware. I chose custom config and pasted the contents from the pritunl configuration file. Then I enabled the vpn, save&apply. The vpn automatically connected.

I then unplugged the gateway from PoE and unplugged the ethernet to force it to use LTE at the next startup. The LoRa part works fine via LTE but the openvpn does not want to connect. When I plug ethernet back in openvpn connects ok.

In the gateway’s log I see the following during the time the gateway is on LTE only:

Mon Mar 16 12:37:57 2020 daemon.warn openvpn(pritunl_ssh_gateway)[1633]: DEPRECATED OPTION: --max-routes option ignored.The number of routes is unlimited as of version 2.4. This option will be removed in a future version, please remove it from your configuration.
Mon Mar 16 12:37:57 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: OpenVPN 2.4.3 mipsel-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Mar 16 12:37:57 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.08
Mon Mar 16 12:37:58 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 16 12:37:58 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 16 12:37:59 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: TCP/UDP: Preserving recently used remote address: [AF_INET]<REDACTED>:16330
Mon Mar 16 12:37:59 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: UDP link local: (not bound)
Mon Mar 16 12:37:59 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: UDP link remote: [AF_INET]<REDACTED>:16330
Mon Mar 16 12:37:59 2020 user.notice ping-watchdog: loopback lo ifup
Mon Mar 16 12:37:59 2020 daemon.info procd: - init complete -
Mon Mar 16 12:38:01 2020 user.notice ping-watchdog: wwan wwan0 ifup
Mon Mar 16 12:38:02 2020 user.notice ping-watchdog: route keys  1 2
Mon Mar 16 12:38:02 2020 user.notice ping-watchdog: route : 192.143.160.157 32 0.0.0.0
Mon Mar 16 12:38:02 2020 user.notice ping-watchdog: route : 0.0.0.0 0 192.143.160.157
Mon Mar 16 12:38:02 2020 user.notice ping-watchdog: /sbin/ping-watchdog wwan wwan0 1 2 1 3 5 10 8.8.8.8 192.143.160.157  20  50 & 
Mon Mar 16 12:38:02 2020 user.notice firewall: Reloading firewall due to ifup of wwan (wwan0)
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Server poll timeout, restarting
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: SIGUSR1[soft,server_poll] received, process restarting
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: TCP/UDP: Preserving recently used remote address: [AF_INET]<REDACTED>:16330
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: UDP link local: (not bound)
Mon Mar 16 12:38:03 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: UDP link remote: [AF_INET]<REDACTED>:16330
Mon Mar 16 12:38:04 2020 user.notice lora_pkt_fwd[1556]: INFO: [main] concentrator started, packet can now be received
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Server poll timeout, restarting
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: SIGUSR1[soft,server_poll] received, process restarting
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: TCP/UDP: Preserving recently used remote address: [AF_INET]<REDACTED>:16330
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: UDP link local: (not bound)
Mon Mar 16 12:38:07 2020 daemon.notice openvpn(pritunl_ssh_gateway)[1633]: UDP link remote: [AF_INET]<REDACTED>:16330

yutao · March 17, 2020, 1:13am

Hi ：
Try to add “local 192.168.230.1” to you custom configuration. This option will bind the openvpn local ip to “LAN interface”. IP packets from the LAN Interface will automatically select available routes: LET or Ethernet.

jpmeijers · March 17, 2020, 8:19am

Thanks @yutao

I tried adding the local 192.168.230.1 to the openvpn config file, and commenting out nobind. I however still have the same issue. I performed a factory reset of the gateway yesterday to make sure the settings are all clean.

Server log:

[evening-fields-3890] Tue Mar 17 08:02:49 2020 User connected user_id=5e43a39d852e0f72a703e823

<ethernet unplugged>

[evening-fields-3890] Tue Mar 17 08:04:52 2020 5e43a39d852e0f72a703e823/169.0.122.219 Connection reset, restarting [0]
[evening-fields-3890] Tue Mar 17 08:04:52 2020 User disconnected user_id=5e43a39d852e0f72a703e823
[evening-fields-3890] Tue Mar 17 08:05:44 2020 TCP connection established with [AF_INET6]::ffff:169.0.122.219:1194
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_VER=2.4.3
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_PLAT=linux
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_PROTO=2
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_NCP=2
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_LZO=1
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_COMP_STUB=1
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_COMP_STUBv2=1
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_TCPNL=1
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_HWADDR=60:c5:a8:71:a9:64
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: IV_SSL=OpenSSL_1.0.2j__26_Sep_2016
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: UV_ID=52b5e73dc6c44eb6a5b222c10760f44f
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 peer info: UV_NAME=evening-dreams-8229
[evening-fields-3890] Tue Mar 17 08:05:47 2020 COM> SUCCESS: client-auth command succeeded
[evening-fields-3890] Tue Mar 17 08:05:47 2020 169.0.122.219 [5e43a39d852e0f72a703e823] Peer Connection Initiated with [AF_INET6]::ffff:169.0.122.219:1194
[evening-fields-3890] Tue Mar 17 08:05:47 2020 5e43a39d852e0f72a703e823/169.0.122.219 MULTI_sva: pool returned IPv4=10.0.243.2, IPv6=(Not enabled)
[evening-fields-3890] Tue Mar 17 08:05:48 2020 User connected user_id=5e43a39d852e0f72a703e823
[evening-fields-3890] Tue Mar 17 08:06:34 2020 TCP connection established with [AF_INET6]::ffff:192.143.130.241:1194
[evening-fields-3890] Tue Mar 17 08:07:19 2020 5e43a39d852e0f72a703e823/169.0.122.219 [5e43a39d852e0f72a703e823] Inactivity timeout (--ping-restart), restarting
[evening-fields-3890] Tue Mar 17 08:07:19 2020 User disconnected user_id=5e43a39d852e0f72a703e823
[evening-fields-3890] Tue Mar 17 08:07:34 2020 192.143.130.241 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
[evening-fields-3890] Tue Mar 17 08:07:34 2020 192.143.130.241 TLS Error: TLS handshake failed
[evening-fields-3890] Tue Mar 17 08:07:34 2020 192.143.130.241 Fatal TLS error (check_tls_errors_co), restarting

My openvpn config is as follows:

setenv UV_ID <redacted>
setenv UV_NAME <redacted>
client
dev tun
dev-type tun
remote <redacted> 12957 tcp-client
local 192.168.230.1
#nobind
persist-tun
cipher AES-128-CBC
auth SHA1
verb 2
mute 3
push-peer-info
ping 10
ping-restart 60
hand-window 70
server-poll-timeout 4
reneg-sec 2592000
sndbuf 393216
rcvbuf 393216
max-routes 1000
remote-cert-tls server
comp-lzo no
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
<redacted>
-----END CERTIFICATE-----
</ca>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
<redacted>
-----END OpenVPN Static key V1-----
</tls-auth>
<cert>
-----BEGIN CERTIFICATE-----
<redacted>
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
<redacted>
-----END PRIVATE KEY-----
</key>

With ethernet, LTE and the VPN connected my routing table looks like this:

root@RAK7240:~# ip route
default via 192.168.2.1 dev eth0.2  proto static  src 192.168.2.10  metric 10 
default via 192.143.130.242 dev wwan0  proto static  src 192.143.130.241  metric 20 
10.0.243.0/24 dev tun0  proto kernel  scope link  src 10.0.243.3 
169.254.0.0/16 dev eth0.2  proto kernel  scope link  src 169.254.169.100 
192.143.130.240/30 dev wwan0  proto static  scope link  metric 20 
192.143.130.242 dev wwan0  proto static  scope link  src 192.143.130.241  metric 20 
192.168.2.0/24 dev eth0.2  proto static  scope link  metric 10 
192.168.2.1 dev eth0.2  proto static  scope link  src 192.168.2.10  metric 10 
192.168.230.0/24 dev br-lan  proto kernel  scope link  src 192.168.230.1

And ip addresses:

root@RAK7240:~# ip addr
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
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 60:c5:a8:71:a9:64 brd ff:ff:ff:ff:ff:ff
3: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default 
    link/ether 60:c5:a8:71:a9:64 brd ff:ff:ff:ff:ff:ff
4: ra0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UNKNOWN group default qlen 1000
    link/ether 60:c5:a8:71:a9:64 brd ff:ff:ff:ff:ff:ff
5: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether d2:63:78:07:c4:93 brd ff:ff:ff:ff:ff:ff
    inet 192.143.130.241/30 brd 192.143.130.243 scope global wwan0
       valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 60:c5:a8:71:a9:64 brd ff:ff:ff:ff:ff:ff
    inet 192.168.230.1/24 brd 192.168.230.255 scope global br-lan
       valid_lft forever preferred_lft forever
7: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 60:c5:a8:71:a9:64 brd ff:ff:ff:ff:ff:ff
    inet 169.254.169.100/16 brd 169.254.255.255 scope global eth0.2
       valid_lft forever preferred_lft forever
    inet 192.168.2.10/24 brd 192.168.2.255 scope global eth0.2
       valid_lft forever preferred_lft forever
8: apcli0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 62:c5:a8:01:a9:64 brd ff:ff:ff:ff:ff:ff
9: mon0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 60:c5:a8:71:a9:64 brd ff:ff:ff:ff:ff:ff
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.0.243.3/24 brd 10.0.243.255 scope global tun0
       valid_lft forever preferred_lft forever

The VPN server’s private IP range is 10.0.243.0/24.

yutao · March 18, 2020, 3:52am

As you can see from the information given, there is a problem with the network configuration of the gateway. When your Ethernet cable is unplugged, the gateway’s default routing target interface is still the ethernet interface. This may be due to the static IP address and default gateway you set for the WAN interface. You can set the gateway metric of the WAN interface to a larger value (greater than the gateway metic of the LTE Interface). In this case, the default route with the highest priority of the gateway will be the LTE interface.

jpmeijers · March 18, 2020, 6:50am

As you can see from the information given, there is a problem with the network configuration of the gateway. When your Ethernet cable is unplugged, the gateway’s default routing target interface is still the ethernet interface.

The information that is given was obtained via SSH when ethernet is plugged in. This is because the gateway is not accesible when it is connected via LTE because LTE is behind a NAT firewall and the OpenVPN is not working. That’s why I said “With ethernet, LTE and the VPN connected my routing table looks like this:”.

This may be due to the static IP address and default gateway you set for the WAN interface.

I do not have a static IP set.

You can set the gateway metric of the WAN interface to a larger value (greater than the gateway metic of the LTE Interface). In this case, the default route with the highest priority of the gateway will be the LTE interface.

This is already the case. LTE is on metric 20 and ethernet on metric 10.

All the settings I use are the default settings I have after doing a factory reset. Latest firmware from March is installed.

jpmeijers · March 18, 2020, 12:44pm

I did another factory reset to make sure nothing I changed caused this. WiFi is enabled by default, so I unplugged ethernet and connected to the gateway via WiFi to see what the routing table looks like. Everything looks fine.

But when I ping the VPN server I see huge packet loss. I swapped the sim card to a different provider, and now everything is working perfectly.

So the cause of the issue was packet loss on the mobile network. The RAK gateway’s default settings are fine.

yutao · March 19, 2020, 1:01pm

Congratulations. Thanks for your update.

system · April 18, 2020, 1:01pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.