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)

The Station and the iFemtocell-Evolution have a SIM card slot that can be used to get a cellular connection.
By default the connection is disabled but the SMS interface is activated, using this interface you can reactivate Ethernet if you have disabled it by error.
you just need to send the following SMS to the phone number of the SIM card in the gateway:

[spn:spnpwd] [coset3] configuration/set_value network.lan.type "dhcp"

the gateway will answer [coset3:ok] if the command is valid.

Then send this SMS:

[spn:spnpwd] [updreb] update/reboot

The gateway will answer [updreb:ok] The gateway will reboot and ethernet connection will be activated on the gateway

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 set up 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 client's 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 using a static-IP address).

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

The Master gateway (an OpenVPN client) must have a fixed-IP addressing (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 addressing (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 section explains how to enable the openvpn autostart at boot time and enable the openvpn process monitoring.

Simply add the following file openvpn in /etc/monit :

openvpn

check process openvpn matching openvpn
        start program = "/etc/init.d/openvpn start"
        stop program = "/etc/init.d/openvpn stop"

Add the following file iptables_openvpn.rules in the /etc/firewall.d directory :

iptables_openvpn.rules

#Firewall rules to accept OpenVPN traffic
 
*filter
-I INPUT  -m udp -p udp --sport 1194 --dport 1024:65535 -j ACCEPT
-I INPUT  -m udp -p udp --sport 30000:35000 --dport 1024:65535 -j ACCEPT
-I OUTPUT -m udp -p udp --sport 1024:65535 --dport 1194 -j ACCEPT
-I OUTPUT -m udp -p udp --sport 1024:65535 --dport 30000:35000 -j ACCEPT
COMMIT

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

Before starting OpenVPN, the following file must be stored in the /etc/openvpn as a “bootstrap”:

#################################################
#                                               #
# 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
 
# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev vpn0
dev-type tun
 
# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp
 
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 192.168.1.10
 
# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random
 
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
 
# Most clients don't need to bind to
# a specific local port number.
nobind
 
# Downgrade privileges after initialization (non-Windows only)
# Keep running as root to be able modifying routing (no persist)
;user nobody
;group nogroup
 
# Try to preserve some state across restarts.
persist-key
# Do not enable persist options related to routing as
# connman can be restarted and can unconfigure routes and interface
;persist-tun
;persist-local-ip
;persist-remote-ip
 
# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
 
# Announce to TCP sessions running over the
# tunnel that they should limit their send packet
# sizes such that after OpenVPN has encapsulated them,
# the resulting UDP packet size that OpenVPN sends
# to its peer will not exceed max bytes.
mssfix 1200
 
# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings
 
# 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
 
# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1
 
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
cipher AES-256-CBC
 
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
 
# Set log file verbosity.
verb 3
 
# Silence repeating messages
;mute 20
 
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 60 600
 
# 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
 
# up   Executed after TCP/UDP socket bind and TUN/TAP open.
# down Executed after TCP/UDP and TUN/TAP close.
;up /etc/openvpn/update-resolv-conf
;down /etc/openvpn/update-resolv-conf
 
# Use route-up instead of up as up is already used !
;route-up
 
#askpass pass.txt

monit openvpn start 

The following tool is designed to automate previous tasks :

• Cyphering VPN certifcates and keys,
• Writing secrets in the ProvenCore Trustzone,
• Activating the packet forwarder (CPF) and updating the forwarding IP (to send LoRa packets to the SPN Master Gateway),
• Activating the monitoring of openvpn process (start and stop).

This script generates a package to install on the gateway.

generate_spn_openvpn_package_v1.0.tar.gz

# usage: ./generate_ipk.sh <GW_EUI> <p12> <server-IP> <passwd> <forwarding-IP>

Ex: ./generate_ipk.sh 7276FF002E060434 client.p12 192.168.1.24 kerlinkkerlink 10.8.0.2

generates a package named configure-openvpn-spn-2e060434_1.0_klkgw.ipk.

• For Production, don't use a self-root CA certificate but a certificate authenticated by a trusted entity like Comodo, GoDaddy, DigiCert, etc…
• Care about the expiration date of your generated certificates.