Wanesy SPN can be reset to recover it's default configuration. All received/send data, configuration, and logs will be removed. This will not remove Wanesy SPN. This action is irreversible.

Factory reset is available in menu Administration ⇒ Gateway ⇒ Factory reset.

To uninstall Wanesy SPN firmware, refer to the Uninstall Wanesy SPN firmware page.

Refer the Quick start page.

The Wanesy SPN version is available on the web user interface. Click on the (i) button in the upper right corner of the screen.

• Ask your IT department to search the IP address from your ethernet MAC address.
• Get the DHCP lease listing from your DHCP server
• Use nmap or any scanning tool from a PC connected to the same network.
  Example on 192.168.4.0/24:

$ nmap 192.168.14.0/24 | grep -i wifc
Nmap scan report for klk-wifc-03002E.klksi.fr (192.168.14.164)

For class C end-devices, the RX window can be forced to RX2 but not to RX1. If the RX window is forced to RX1, then this is no longer class C. Class C relies on being able to send frames during RX2 window. The user must choose between RX2 window and Auto.

The join requests traces are available in the LoRa MAC Server logs in Logs ⇒ LoRa MAC server menu.

Quick logs analysis:

• A join request is received from an end-device with Device EUI 34-37-37-39-5c-33-6a-08

Nov 28 16:01:12 NS: Received join request from Mote 34-37-37-39-5c-33-6a-08

• The join request is accepted by the join controller

Nov 28 16:01:12 NS: JoinController received accept for Mote 34-37-37-39-5c-33-6a-08

• A join response will be sent with on window 0 (frequency 868300000 Hz and SF 7)

Nov 28 16:01:12 NS: Class A Tx Rq for Mote 34-37-37-39-5c-33-6a-08 W0 SF7BW125 (Symbol time 1024us)  W1 SF12BW125 (Symbol time 32768us) Window 0 is better
Nov 28 16:01:12 NS: Use frequency 868300000 SF7BW125

• Join response is sent

Nov 28 16:01:17 NS: GW 72-76-ff-00-39-03-00-04 Tx to Mote 34-37-37-39-5c-33-6a-08  {"txpk":{"tmst":1790938763,"freq":868.300000,"rfch":0,"powe":24,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"ncrc":true,"size":17,"data":"IKP4WomIcDX0eOWq

The hardware serial number can be found in the Overview ⇒ Information menu.

If the gateway has a static IP address and the network does not have a DNS (Domain Name System), the NTP server address in the gateway needs to be changed in Administration ⇒ Gateway ⇒ Time configuration menu. In this scenario, the gateway is not able to link 2.pool.ntp.org and 3.pool.ntp.org to the corresponding IP addresses. To permit the gateway to access the NTP server, the server name (e.g 2.pool.ntp.org) needs to be changed by its IP address.

To find the IP address of a NTP server, use the command nslookup on any Linux machine.

$ nslookup

> 2.pool.ntp.org
Server:         192.168.4.83
Address:        192.168.4.83#53

Non-authoritative answer:
Name:   2.pool.ntp.org
Address: 129.250.35.251
Name:   2.pool.ntp.org
Address: 151.80.19.218
Name:   2.pool.ntp.org
Address: 212.83.145.32
Name:   2.pool.ntp.org
Address: 163.172.61.210

Then replace the name of the server by its IP address in the configuration file of the Wanesy SPN and upload it.

Gathering logs from shell

Gathering logs from the interface

This section explains how to configure OpenVPN with the Wanesy SPN in a multi-gateways configuration over ethernet or cellular in order to setup a secure channel between the master gateway and the slave gateways.

You will need:

• to generate keys and certificates for the server and the clients
• to configure the OpenVPN server
• to configure the OpenVPN clients
• to enable OpenVPN on the OpenVPN clients
• to configure the clients' Packet forwarder
• to add a specific patch to the Packet forwarder

The OpenVPN server can be installed :

• in a standalone PC (Windows or Ubuntu)
• in the Master SPN gateway
• in a Raspberry Pi computer

The OpenVPN server must use a static IP definition.

For ethernet, you can use a static-IP addressing (LAN configuration) or a domain name (WAN configuration with optionally the dynamic DNS feature if the IP address of the server is often changing but we recommend to use a static-IP address).

Note that if the configuration works for cellular, the same configuratio will work for ethernet.

The Master gateway (an OpenVPN client) must have a fixed-IP adressing (ethernet and cellular)
in order the packet forwarder of the slave gateways to forward properly the received LoRa packets to the Master gateway.

It is not mandatory that the slave gateways (OpenVPN clients) have a fixed-IP adressing (ethernet and cellular).

The great convenience of using OpenVPN is the fact that it is using a static-IP addressing (10.8.x.x).

So the only preconditions to have are:

• a static definition for addressing the OpenVPN server (domain name or fixed-IP).
  This definition must be public if you are using cellular for the backhaul of your SPN gateways.
• a static definition for the SPN Master gateway acting as an OpenVPN client (fixed-IP for the ethernet and cellular backhaul).

For ethernet, fixed-IP addressing is not mandatory for slave gateways. For cellular, standard SIM cards can be used in the slave gateways.

The following diagram shows the kind of configuration required for each type of backhaul used for the OpenVPN clients gateways (ethernet/cellular) :

The configuration of the VPN requires:

• A “Certification Authority Certificate” file, authenticating the server and the clients, ca.crt
• A server configuration file, named server-openvpn.conf. This is the main configuration file.
• A “Server key and certificate archive” file, authenticating the OpenVPN server (can be the Wanesy SPN Master gateway): server.p12
• A client configuration file, named client-openvpn.conf.
• A “User key and certificate archive” file, authenticating the Wanesy SPN gateway (the client): client.p12

For configuration files, make sure that non-interactive authentication is enabled (left empty) since the connection is established by a daemon, the password cannot be entered manually.

All those files can to be uploaded via the web interface of the gateway (see below)

Here is the VPN truth chain used for this architecture:

The following chart shows the packet forwarding feature in an SPN architecture using OpenVPN:

The VPN fixed IP addressing is used to target the Master gateway in the Packet Forwarder configuration of the slave gateway.

For the SPN architecture, since a particular VPN client acts as the Master gateway, a communication “client-to-client” must be enabled to allow the slave gateways to forward LoRa packets to the Master gateway. If the SPN Master gateway is used as the OpenVPN server, this directive is not mandatory.

To generate keys and certificates, please refer to the following wiki page:
https://wikikerlink.fr/wanesy-spn/doku.php?id=wiki:webui:administration:openvpn:pki

Here is a simple server side configuration file to put in /etc/openvpn directory:

server-openvpn.conf

port 1194
proto udp
dev tun
 
#tls-version-min "1.0"
#tls-version-max "1.0"
 
# CA certificate
ca ca.crt
 
# Server certificate
cert server.crt
 
# Private Server key # This file should be kept secret
key server.key
 
# Diffie-Hellman parameters
dh dh2048.pem
 
# LAN information and network configuration
topology subnet
 
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt 86400
mssfix 1200
push "route 172.17.0.0 255.255.0.0"
push "route 172.18.0.0 255.255.0.0"
push "dhcp-option DNS 10.8.0.1"
 
# Connection management
comp-lzo
keepalive 15 120
cipher AES-256-CBC
 
# Daemon configuration
user nobody
group nogroup
 
# Persist across restarts
persist-key
persist-tun
persist-local-ip
persist-remote-ip
 
# Management options
status openvpn-status.log
verb 4
management localhost 6666
script-security 2
 
# Enable clients to talk each others
client-to-client

Note: if you set a passphrase to access your private key, just add the following line in your configuration file :

askpass pass.txt

fill the pass.txt file with your password and chmod 600 it.

Start OpenVPN with the following command:

# sudo openvpn /etc/openvpn/server-openvpn.conf

Here is an example of a client configuration file to use and to put in /etc/openvpn directory:

client-openvpn.conf

#################################################
#                                               #
# Client-side OpenVPN 2.X config file for       #
# connecting to multi-client server.            #
#                                               #
# Comments are preceded with '#' or ';'         #
#                                               #
#################################################
 
# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client
 
tls-client
#remote-cert-tls server
 
# Protocol
proto udp
 
#Tunnel
dev tun
 
#Server
remote 192.168.1.14
 
#Certification Authority Certificate - Server Authentication
ca ca.crt
 
#User Key and Certificate - Client Authentication
pkcs12 client.p12
 
cipher AES-256-CBC
 
#auth SHA256
 
tls-version-min "1.0"
tls-version-max "1.0"
 
mssfix 1200
comp-lzo

In this exemple, we are using a static IP for the server IP definition (192.168.1.14).

Note: if you set a passphrase to access your private key, just add the following line in your configuration file :

askpass pass.txt

fill the pass.txt file with your password and chmod 600 it.

Select the “Enable” button from the Administration > OpenVPN menu option and drag and drop the following files :

• ca.crt
• client.p12
• client-openvpn.conf

Automatically the openvpn process will be launched at boot time and be monitored by the monit tool.

The last step to perform is the configuration of the slave gateway's packet forwarder. The VPN IP of the Master gateway will be used as the “node” information of the packet forwarder (here 10.8.0.2).

Due to a bug in the packet forwarder when rebooting the slave gateway (error “operation not permitted”), a specific patch must be applied to each slave gateway in order to restart the packet forwarder at the end of the boot process.

Do the following for each slave gateway:

Create the file S97lorafwd_restart in /etc/rcU.d and order the execution of the command “monit restart lorafwd”:

# cd /etc/rcU.d/
# vi S97lorafwd_restart
monit restart lorafwd

Don't forget to change file permissions:

# chmod 777 S97lorafwd_restart

A specific magic link should be used to keep the actual OpenVPN configuration and patches.

When SPN slaves are using the FW 4.x.x, you must be aware that:

• OpenVPN configuration must be done manually: process monitoring and process start must be enabled at boot time.
• Firewall rules must be added to accept the OpenVPN traffic (port 1194 IN/OUT).
• All secrets (OpenVPN keys and certificates) must be written in the ProvenCore TrustZone.
  The following WIKI page explains how to proceed: https://wikikerlink.fr/wirnet-productline/doku.php?id=wiki:network_mana:vpn_client&s[]=pnr&s[]=uploader.
• passphrase must be removed from the p12 file (protecting the client's private key) and replaced by a passphrase in the cyphered package (.enc).
• tls-version-min 1.1 and tls-version-max 1.2 directives must be explicitly added in the client's OpenVPN configuration file.

This guide explains how to store secrets in the TrustZone.

# sudo apt install python3-crypto

On the gateway:

# pnr_uploader -R -p "kerlinkkerlink"

request completed with status: 0
root@klk-lpbs-060434:~ #

NB: you have to use a different passphrase and stronger !

Since a new passphrase will be added to the encoded package, the initial passphrase generated when building the p12 package can be removed. So regenerate the p12 without passphrase (let empty) as described here: https://wikikerlink.fr/wanesy-spn/doku.php?id=wiki:webui:administration:openvpn:pki#p12_packaging_pkcs_121.

Transfer your client p12 package to your Ubuntu environment (using the scp command) for cyphering.

Perform the following command:

# python3 pnrcipher.py -f client.p12 -p « kerlinkkerlink »

A client.p12.enc file is generated.

Transfer back this encoded file to your gateway using the scp command.

Add the following lines for TLS compatibility:

# Mandatory Param
tls-version-min 1.1
tls-version-max 1.2

Replace the “pkcs12 client.p12” directive by the following line:

pkcs12 [[INLINE]] /trustzone/securestorage/block10 "kerlinkkerlink"

Remove or comment the ca directive :

# cert ca.crt

Add the directive remote-cert-tls server to avoid MITM attacks:

remote-cert-tls server

Here is an example of configurationfile to use:

#################################################
#                                               #
# Client-side OpenVPN 2.X config file for       #
# connecting to multi-client server.            #
#                                               #
# Comments are preceded with '#' or ';'         #
#                                               #
#################################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
#pkcs12 [[INLINE]] 
 
# Verify server certificate by checking that the
# certicate has the correct key usage set.
# This is an important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the keyUsage set to
#   digitalSignature, keyEncipherment
# and the extendedKeyUsage to
#   serverAuth
# EasyRSA can do this for you. 
remote-cert-tls server
 
# Protocol
proto udp
 
#Tunnel
dev vpn0
dev-type tun

#shared key server-client
#tls-auth ta.key 0

nobind
 
#Server
remote 192.168.1.10
 
#Certification Authority Certificate - Server Authentication
# cert ca.crt
 
#User Key and Certificate - Client Authentication
pkcs12 [[INLINE]] /trustzone/securestorage/block10 "kerlinkkerlink"
 
cipher AES-256-CBC
 
#auth SHA256
 
tls-version-min "1.1"
tls-version-max "1.2"
 
mssfix 1200
comp-lzo

askpass pass.txt

# 0 -- Strictly no calling of external programs.
# 1 -- (Default) Only call built-in executables such as  ifconfig,
# ip, route, or netsh.
# 2  --  Allow  calling  of  built-in executables and user-defined
# scripts.
# 3 -- Allow passwords to be passed to scripts  via  environmental
# variables (potentially unsafe).
script-security 2

Transfer the client configuration file to your Ubuntu environment and perform the following commands:

# mv client-openvpn.conf provencore-openvpn.conf
# python3 pnrcipher.py -f provencore-openvpn.conf -p « kerlinkkerlink »

A provencore-openvpn.conf.enc file is generated.

Transfer back the encoded file to your gateway (using the scp command).

# pnr_uploader -u -f client.p12.enc  -b 10

uploading 3408 bytes
request completed with status: 0

# pnr_uploader -u -f provencore-openvpn.conf.enc  -b 2

uploading 2048 bytes
request completed with status: 0

/etc/init.d/openvpn start