OpenVPN

Documentation

OpenVPN - Setup and Configuration

General Information

Open VPN is the recommended application setup by 1NCE to establish a secure data connection between the 1NCE network and the customers server.

 

 

Therefore, the OpenVPN client needs to be installed on the customer server (aka application server) to which the data of the device shall be transmitted. The OpenVPN connection to the 1NCE network is established by the OpenVPN client, that can be downloaded via the 1NCE customer portal. There are two different versions for Windows and for Linux/MacOS available.

After the network connection and the OpenVPN connections have been established, you may check the connection with a Ping:

 

SIM-> Server

From the device execute a PING to the OpenVPN client’s address (e.g. 10.x.x.x; the IP is always the same for the customer).

 

Server-> SIM

From your server execute a PING to the IP address of your device. It is a private IPv4 address which has been assigned by the 1NCE network when the mobile connection is established (e.g. 100.x.x.x; the IP address is always the same for one SIM).

 

Installing OpenVPN in Windows

Install OpenVPN software from https://openvpn.net/index.php/open-source/downloads.html

 

 

  1. Download client.ovpn from “Configuration” section in the customer portal and store it on your server in C:\Program Files\OpenVPN\config
  2. Download the file credentials.txt from “Configuration” section in the customer portal and save it in “C:\Program Files\OpenVPN\config”
  3. Start OpenVPN GUI application and monitor the connection. For a log on your last connection open the logfile in C:\Program Files\OpenVPN\log\client.txt

(may also be C:\Users\<IHRPROFIL>\OpenVPN\log\client.txt)

 

Installing OpenVPN in Linux / MacOS

  1. Install OpenVPN with “sudo apt-get install openvpn”; for “Ubuntu” or using “Homebrew” for MacOS with “brew install openvpn”.
  2. Download „client.conf“ from customer portal (Configuration -> OpenVPN Configuration -> Linux/macOS -> Download client.conf).
    * Optional: Added line log /var/log/openvpn_1nce.log just for debugging purpose. *
  3. Copy <client.conf> to /etc/openvpn.
  4. Download „credentials.txt“ from customer portal (Configuration -> OpenVPN Configuration -> Linux/macOS -> 3. Save the following file credentials.txt …).
  5. Copy <credentials.txt> also in /etc/openvpn.
  6. Start the OpenVPN connection with new configuration: “sudo service openvpn restart”

 

Example Setup with two Raspberrys and connection test on Linux

The test environment shows how to check if the OpenVPN connection has successfully been established.

The following test environments have been run on a Linux server.:

Two Raspberry Pis have been used in this test environment. They are called „raspberrypi2“ and „raspberrypi3“.

The following steps show how to check that the OpenVPN connection has been successfully established:

raspberrypi2

1. The raspberrypi2 as data receiving application server establishes the OpenVPN connection.

Look into logfile, e.g. with <sudo cat /var/log/openvpn_1nce.log>.

 

Here are the last lines of the test:

Mon Aug 27 15:31:45 2018 TUN/TAP device tun0 opened

Mon Aug 27 15:31:45 2018 TUN/TAP TX queue length set to 100

Mon Aug 27 15:31:45 2018 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0

Mon Aug 27 15:31:45 2018 /sbin/ifconfig tun0 10.64.71.XX pointopoint 10.64.71.XX mtu 1500

Mon Aug 27 15:31:45 2018 /sbin/route add -net 10.64.X.X netmask 255.255.255.255 gw 10.64.71.XX

Mon Aug 27 15:31:45 2018 /sbin/route add -net 100.117.XXX.0 netmask 255.255.252.0 gw 10.64.71.XX

Mon Aug 27 15:31:45 2018 GID set to nogroup

Mon Aug 27 15:31:45 2018 UID set to root

Mon Aug 27 15:31:45 2018 Initialization Sequence Completed

 

In this example 10.64.71.XX is the address of the OpenVPN client.

2. Type in <ifconfig> and search for tun0.

In the test we have:

 

tun0          Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet addr:10.64.71.XX  P-t-P:10.64.71.XX  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:16 errors:0 dropped:0 overruns:0 frame:0

          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

         RX bytes:1344 (1.3 KiB)  TX bytes:1428 (1.3 KiB)

rastberrypi3

1. The rastberrypi3, in this case a 3G USB Surfstick, Huawei E173, is in this test environment the SIM carrying device (modem).

Using wvdial with following config to get the default configuration of your device:

 

$ cat /etc/wvdial.conf

 

[Dialer 1nce]

Init1 = ATZ

Init2 = ATQ0 V1 E1 S0=0 &C1 &D2

Init3 = AT+CGDCONT=1,”IP”,”iot.1nce.net”

Modem Type = Analog Modem

Baud = 9600

New PPPD = yes

Modem = /dev/ttyUSB1

ISDN = 0

Phone = *99#

Password = *

Username = *

 

Please note that this config is based on this test environment. If you have a different modem you have to run

sudo wvdialconf

first, then set the 1NCE APN and save this configuration with a name of your choice. In this test environment we have named the config file with “1nce”.

2. Starting the connection with

$ sudo wvdial 1nce > /tmp/3G_1nce.log 2>&1

3. Looking into the logfile you see that the connection is established.

$ cat /tmp/3G_1nce.log

–> WvDial: Internet dialer version 1.61

–> Initializing modem.

–> Sending: ATZ

ATZ

OK

–> Sending: ATQ0 V1 E1 S0=0 &C1 &D2

ATQ0 V1 E1 S0=0 &C1 &D2

OK

–> Sending: AT+CGDCONT=1,”IP”,”iot.1nce.net”

AT+CGDCONT=1,”IP”,”iot.1nce.net”

OK

–> Modem initialized.

–> Sending: ATDT*99#

–> Waiting for carrier.

ATDT*99#

CONNECT

–> Carrier detected.  Waiting for prompt.

–> Don’t know what to do!  Starting pppd and hoping for the best.

–> Starting pppd at Mon Aug 27 15:35:54 2018

–> Pid of pppd: 12919

–> Using interface ppp0

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> local  IP address 100.117.XXX.5

–> pppd: ▒[1a]▒

–> remote IP address 10.64.64.XX

–> pppd: ▒[1a]▒

–> primary   DNS address 8.8.8.8

–> pppd: ▒[1a]▒

–> secondary DNS address 8.8.4.4

–> pppd: ▒[1a]▒

 

The private IP address in this case is 100.117.XXX.5, which is the IP of the device.

Now you have a direct connection through the OpenVPN tunnel to the raspberrypi2, which is the application server in this test environment.

1. With a ping you can try it out the connection from application server (raspberrypi2) to device (raspberrypi3):

raspberrypi3 $ ping -I ppp0 10.64.71.XX

PING 10.64.71.57 (10.64.71.57) from 100.117.XXX.5 ppp0: 56(84) bytes of data.

64 bytes from 10.64.71.XX: icmp_seq=1 ttl=62 time=734 ms

64 bytes from 10.64.71.XX: icmp_seq=2 ttl=62 time=518 ms

64 bytes from 10.64.71.XX: icmp_seq=3 ttl=62 time=118 ms

64 bytes from 10.64.71.XX: icmp_seq=4 ttl=62 time=116 ms

64 bytes from 10.64.71.XX: icmp_seq=5 ttl=62 time=95.9 ms

64 bytes from 10.64.71.XX: icmp_seq=6 ttl=62 time=94.8 ms

64 bytes from 10.64.71.XX: icmp_seq=7 ttl=62 time=103 ms

64 bytes from 10.64.71.XX: icmp_seq=8 ttl=62 time=102 ms

64 bytes from 10.64.71.XX: icmp_seq=9 ttl=62 time=101 ms

64 bytes from 10.64.71.XX: icmp_seq=10 ttl=62 time=100 ms

64 bytes from 10.64.71.XX: icmp_seq=11 ttl=62 time=99.9 ms

^C

— 10.64.71.XX ping statistics —

11 packets transmitted, 11 received, 0% packet loss, time 10008ms

rtt min/avg/max/mdev = 94.893/198.913/734.189/206.778 ms

2. The connection from device (raspberrypi3) to application server (raspberrypi2) can also be tested via a ping request:

raspberrypi2 $ ping -I tun0 100.117.XXX.5

PING 100.117.224.5 (100.117.224.5) from 10.64.71.57 tun0: 56(84) bytes of data.

64 bytes from 100.117.XXX.5: icmp_req=1 ttl=62 time=804 ms

64 bytes from 100.117.XXX.5: icmp_req=2 ttl=62 time=133 ms

64 bytes from 100.117.XXX.5: icmp_req=3 ttl=62 time=102 ms

64 bytes from 100.117.XXX.5: icmp_req=4 ttl=62 time=101 ms

64 bytes from 100.117.XXX.5: icmp_req=5 ttl=62 time=100 ms

64 bytes from 100.117.XXX.5: icmp_req=6 ttl=62 time=121 ms

64 bytes from 100.117.XXX.5: icmp_req=7 ttl=62 time=99.9 ms

64 bytes from 100.117.XXX.5: icmp_req=8 ttl=62 time=99.5 ms

64 bytes from 100.117.XXX.5: icmp_req=9 ttl=62 time=99.1 ms

64 bytes from 100.117.XXX.5: icmp_req=10 ttl=62 time=97.4 ms

64 bytes from 100.117.XXX.5: icmp_req=11 ttl=62 time=107 ms

^C

— 100.117.XXX.5 ping statistics —

11 packets transmitted, 11 received, 0% packet loss, time 10007ms

rtt min/avg/max/mdev = 97.494/169.764/804.094/200.879 ms

After having established and tested the OpenVPN connection you may terminate the connection on raspberry2 with:

 

$ sudo killall wvdial

$ tail -f /tmp/3G_1nce.log

Caught signal 15:  Attempting to exit gracefully…

–> Terminating on signal 15

–> pppd: ▒[1a]▒

–> Connect time 108.0 minutes.

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> pppd: ▒[1a]▒

–> Disconnecting at Mon Aug 27 17:23:53 2018

Troubleshooting Guide

1. Locating the client log files

Log file location for the OpenVPN Connect Client for Windows:

C:\Program Files (x86)\OpenVPN Technologies\OpenVPN Client\etc\log\openvpn_(unique_name).log

 

By Default, in most Linux distributions, OpenVPN log output goes to the syslog, which is usually at:

/var/log/syslog

 

The OpenVPN Connect Client for Mac:

/Library/Application Support/OpenVPN/log/openvpn_(unique_name).log

 

Macintosh may not show you this folder in finder as it only shows you certain things and hides others. So, to get to the “/Library” folder, open Finder and in the menu at the top choose Go, followed by Go to folder and then enter the path /Library to get into that directory. You can then go to the correct folder and look up the log file. Please also note that the OpenVPN Connect Client for Macintosh will have permissions set on the log file so that you cannot normally open it. To bypass this, right click the log file and choose the “Get info” option in the menu. Then at the bottom, under “Sharing & Permissions”, you will be able to use the yellow padlock icon to unlock the settings and to give everyone read access. Then you will be able to open the log file with a right click and selecting “Open with” and then choosing something like Text editor to view the contents of the log file.

2. Routing table for OpenVPN

Each customer gets one full /22 IP Subnet assigned during the first order. Depending on the amount of SIM cards more Subnets are added.

The OpenVPN client is pulling the information for all required routes on the systems during the initialization of the connection. Therefore, it is recommended to restart the OpenVPN client regular to ensure that all new Subnets are included into the local routing tables.

3. Potential route subnet conflict

The OpenVPN log entry „potential route subnet conflict” means that your SIM cards which has IP addresses that are also in your local network.

One way to fix this is to include a “redirect gateway local” option in the OpenVPN configuration file.  Another way to fix this is to change the addresses of your local LAN. You do this by changing your router’s configuration. For some routers you specify the first three numbers of the LAN (e.g. 192.168.77); in other routers you specify the address of the router itself (e.g. 192.168.77.1).

4. OpenVPN connection dropped without any reason

Our OpenVPN client does not support more than one active connection to the OpenVPN server. A common reason is that the sample credentials are used already for another connection. Usually this becomes visible if the logs show a continuous reconnection and dropping of the connection.

Please check if another user is also trying to establish an OpenVPN connection with the given credentials.

5. HTTPS timeout through OpenVPN connection

HTTPs connections to your application Server may time out when connecting through OpenVPN.

Changing the MTU size for the network interface may solve the issue. Due to our limited bandwidth of 128 Kbit/s the standard MTU size (1500) is causing these issues. Changing the MTU size to something lower than 1500, like 1400 should help.

6. OpenVPN Authentication issue

Certain OpenVPN versions do not support a password length with more than 128 characters. Therefore, authentication is failing.

This issue is known for example in the “OpenVPN 2.4.6 arm-openwrt-linux-gnu” on OpenWRT with PKCS#11 disabled. Recompiled OpenVPN after patching the support for longer passwords solves the problem. The Bug is known in the OpenVPN community and can be found at: https://community.openvpn.net/openvpn/ticket/712