Documentation
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).
Install OpenVPN software from https://openvpn.net/index.php/open-source/downloads.html
(may also be C:\Users\<IHRPROFIL>\OpenVPN\log\client.txt)
log-append /var/log/openvpn_1nce.log
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:
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.
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)
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”.
$ sudo wvdial 1nce > /tmp/3G_1nce.log 2>&1
$ 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.
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
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
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.
Each customer gets one full /24 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.
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).
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.
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.
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