M2M WirelessGW ConfigurationGuide 758449 Ena

1MRS758449 EN
Technical Note
ABB Oy, Medium Voltage Products
Issued: Nov 2015

Revision: A / 23 Nov 2015
3G/LTE Configuration Guide

Configuring Arctic Wireless Gateways/Controllers and M2M Gateway
Contents:
1
Scope ..................................................................................................................... 5
Introduction ......................................................................................................... 6
Target audience............................................................................................. 6
Conventions .................................................................................................. 6
Pre-requisites ................................................................................................ 6
Identifying the products ................................................................................ 7
Dual SIM models .............................................................................. 7
The Single SIM Lite models .......................................................... 7
Product code mapping .................................................................................. 8
Installation workflow .......................................................................................... 9

Tools needed ................................................................................................. 9
Before starting ............................................................................................ 10
Selecting the cellular operator ......................................................... 10
Pre-installation checklist ................................................................. 10
Configuring the installation computer ............................................................ 12
Cabling the field devices ................................................................................... 15

Power supply cable ..................................................................................... 15
Ethernet cable ............................................................................................. 15
Serial cable for console port ....................................................................... 15
Serial cable for RS1 application port .......................................................... 15
Serial cable for RS2 application port .......................................................... 15
Antenna....................................................................................................... 16
Antenna connectors ......................................................................... 16
Antenna type ................................................................................... 16
Inserting SIM card ...................................................................................... 16
Cabling the M2M Gateway............................................................................... 18
Grounding .......................................................................................................... 20
Configuring the M2M Gateway ....................................................................... 21

Basic configuration guidelines ................................................................... 21
Unique subnets ................................................................................ 21
OpenVPN peer IP addresses ........................................................... 21
Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND
1 (134)
3G/LTE Wireless Gateways/Controllers Configuration Guide

Configuring Wireless Gateways/Controllers and M2M Gateway
1MRS758449 EN
Wireless Gateways/Controllers LANs ........................................... 21

M2M GWs LAN ............................................................................ 21
M2M GWs WAN........................................................................... 22
Wireless Gateways/Controllers cellular IP addresses .................... 22
Customers other subnets ................................................................ 22
Logging in to the M2M Gateway ............................................................... 22
Configuring network interfaces .................................................................. 23
Configuring the routing and gateway in M2M GW ................................... 26
9
Configuring the Wireless Gateway/Controller ............................................... 28

System ........................................................................................................ 28
Welcome page ................................................................................. 28
General settings ............................................................................... 29
Time ................................................................................................ 30
Status ............................................................................................... 31
Network ...................................................................................................... 34
Ethernet ports (dual SIM models) ................................................... 34
Ethernet port (Lite models) ............................................................. 36
Mobile WAN (3G SIM1, 3G SIM2), Mobile WAN (Lite models) 40
Mobile WAN (3G SIM2), dual SIM models .................................. 43
WAN failover .................................................................................. 43
Monitor ............................................................................................ 46
Static routing ................................................................................... 47
SMS config...................................................................................... 47
VPN ............................................................................................................ 49
Certificates ...................................................................................... 49
IPSEC-VPN remotes, tunnels ......................................................... 50
L2TP-VPN ...................................................................................... 50
OpenVPN ........................................................................................ 50
SSH-VPN, SSH-VPN keys ............................................................. 50
Firewall ....................................................................................................... 51
General Settings .............................................................................. 52
Common Functions ......................................................................... 54
Default Actions ............................................................................... 55
IP v.6 ............................................................................................... 56
OpenVPN bridge filtering ............................................................... 56
Filter incoming ................................................................................ 56
Filter forwarded ............................................................................... 56
Filter outgoing ................................................................................. 56
D-NAT ............................................................................................ 56
S-NAT ............................................................................................. 62
Services ....................................................................................................... 62
Common .......................................................................................... 62
DHCP server ................................................................................... 64
DynDNS client ................................................................................ 66
2 (134)

1MRS758449 EN
SNMP agent .................................................................................... 66

SNMP IO (certain Wireless I/O Gateway models) ......................... 67
Arctic Patrol .................................................................................... 67
Serial ports and I/O ..................................................................................... 68
General configuration...................................................................... 68
Serial Gateway (RS1, RS2) ............................................................. 68
SMS modem (RS1, RS2) ................................................................ 71
IEC-104 Gateway, Modbus Gateway ............................................. 72
DCU ................................................................................................ 72
Tools ........................................................................................................... 72
System log ....................................................................................... 73
Support log ...................................................................................... 73
Modem info ..................................................................................... 73
Network test .................................................................................... 75
Monitor graphs ................................................................................ 75
User config ...................................................................................... 76
Restricted shell ................................................................................ 77
Reboot ............................................................................................. 77
Release notes ................................................................................... 78
Configuration profiles ..................................................................... 78
Default settings................................................................................ 78
Firmware update.............................................................................. 79
10 Configuring OpenVPN with Easy mode.......................................................... 80
Configuring OpenVPN in M2M Gateway, Easy mode .............................. 80
Selecting the type of VPN ............................................................... 80
Creating an OpenVPN server instance ............................................ 81
Adding clients to the server............................................................. 81
Exporting the client configuration to Arctic ................................... 84
Finalizing the routing settings in Wireless Gateway/Controller ..... 85
Configuring the PC Easy OpenVPN client for remote administration ....... 86
Adding an OpenVPN client to M2M GW....................................... 87
Exporting the Easy OpenVPN client to a PC .................................. 87
Installing the OpenVPN software to a PC ....................................... 88
Configuring the OpenVPN client in the PC .................................... 89
Using the OpenVPN ................................................................................... 90
11 Configuring OpenVPN in Advanced mode ..................................................... 94
Configuring OpenVPN in M2M Gateway, Advanced mode ..................... 94
Creating a new certificate authority ................................................ 95
Creating a new server certificate ..................................................... 96
Creating new client certificates ....................................................... 98
Creating new server configuration ................................................ 101
Adding clients to the server........................................................... 104
Exporting the client configuration file .......................................... 106
Configuring OpenVPN in Wireless Gateway/Controller ......................... 107
3 (134)

1MRS758449 EN
Importing the client identity .......................................................... 108

Configuring Arctics OpenVPN client settings ............................. 110
Configuring the PC OpenVPN client for remote administration ............. 111
Creating a new OpenVPN client in M2M Gateway ...................... 111
Exporting the certificate from M2M Gateway to a PC ................. 112
Installing the OpenVPN software to the PC ................................. 113
Configuring the OpenVPN client in the PC .................................. 114
Using the OpenVPN ................................................................................. 116
12 Testing the solution Easy OpenVPN setup ................................................. 119
13 Testing the solution Advanced OpenVPN setup ........................................ 120
14 Troubleshooting ............................................................................................... 121
Troubleshooting steps ............................................................................... 121
Troubleshooting the routing ..................................................................... 121
15 Network IP planning ....................................................................................... 126
Scenario 1, the M2M GW connected with public IP address ................... 126
Scenario 2, M2M GW behind the company firewall ............................... 127
Wireless Gateways/Controllers and private cellular access point ............ 129
IP v4 addressing ....................................................................................... 130
Public and private IP addresses ..................................................... 130
IP address classes .......................................................................... 131
Classless IP-addressing ................................................................. 131
Routing .......................................................................................... 133
CIDR, classless inter-domain routing ........................................... 133
Document history, Disclaimer and Copyrights, Trademarks, Contact information .. 134
4 (134)

1MRS758449 EN
Scope
This document provides instructions on how to configure the following Arctic products
against the M2M Gateway product.
ARG600 Wireless Gateways
ARP600 Wireless Protocol Gateways
ARR600 Wireless I/O Gateways
ARC600 Wireless Controllers
The devices listed above are referred to as M2M GW, Arctic, device or Wireless
Gateway/Controller later on in this document.
This Technical Note explains the parameters and certain recommended values for
configuring the devices. There are also descriptions for functionalities, (e.g. WAN
failover mechanism, D-NAT) and information regarding advanced configurations, such
as connecting a remote field laptop safely to the system.
5 (134)

1MRS758449 EN
Introduction
The 3G/LTE Arctic Wireless Gateways/Controllers are having new features and new
Web human-machine interface (abbreviated later as Web HMI), when compared to
RER603 or REC603 products. This Technical Note instructs configuring the Wireless
Gateways for establishing VPN tunnels to the M2M Gateway. There are also detailed
explanations for menu items of the Web HMI of these devices.
The 2G models (ABB RER603 and REC603) are not in scope of this document.
Target audience
The target audience for this document is:
Field engineers
Sales partners
Customers' technical personnel
Conventions
The following conventions may be used in this document:
The menu items in graphical user interfaces are denoted as bolded font and the
sequence of mouse clicks, while configuring the devices in menus is separated
with an arrow. Example: Click Tools System log.
The console or command line output is printed with courier font and user input is
printed with bold courier new font. Example:
[adm@abb ~]# date
Mon Nov 23 14:24:53 EET 2015
The usernames, passwords and parameter-value pairs are denoted with courier
font.
The placeholders for actual values are written between < and > mark.
For example, the <IP address> would mean the place to write the actual IP
address.
Pre-requisites
It is assumed that the reader of this document has a basic knowledge of Linux and
Windows systems and TCP/IP networking.
6 (134)

1MRS758449 EN
The following documents are available.

o M2M Gateways and Wireless Gateways/Controllers Users manuals
o Application note 3G GW dual SIM configuration (if dual-SIM devices)
See the latest documents from the ABB Website
http://www.abb.com/substationautomation
The firmware version of the Wireless Gateway/Controller is 3.2.6 or newer
A PC with operating system, web browser and Ethernet cable connection is
available for configuring the devices.
Identifying the products

There are two basic HW variants of current Arctic 3G/LTE Gateways; Dual SIM and
Single SIM models.
There is a sticker at the bottom of the device, identifying the exact model, product
code and serial number. The Web HMI also identifies the product and firmware
version in welcome and status pages.
Dual SIM models

The 3G/LTE model with two SIM card holders and three port Ethernet LAN switch
is shown below. The LTE Wireless Gateway is identical to 3G model, except for the
LTE internals and product sticker at the bottom of the device. There is also a dual
SIM variant of Wireless Protocol Gateway (with added protocol conversions).
Fig. 2.4.1-1 Dual SIM Wireless Gateway

The Single SIM Lite models
The Single SIM series is built in the same form factor than old 2G devices (ABB
RER601, RER603) and may thus replace such devices in existing installations. The
Web HMI of the Lite series is the same style as in dual SIM models, except the
missing three Ethernet port configurations (only one Ethernet interface) and only one
SIM card.
The Lite models can be differentiated from the old 2G models externally by the
sticker at the bottom or by the antenna connector (Lite models are having smaller
7 (134)

1MRS758449 EN
SMA-type antenna connector whereas the older 2G models are having bigger FME
connector).
Fig. 2.4.2-1 Single SIM Lite model

Product code mapping
Old product code mapping:
C = Communications
P = Protocol (includes Modbus/IEC protocol conversion)
R = RTU (device with IO)
New product code mapping:
Old series name New descriptive name
C-series
Wireless Gateway
P-series
Wireless Protocol Gateway
R-series
Wireless I/O Gateway
Control
Wireless Controller
Full product name

ARG600 Wireless Gateway
ARP600 Wireless Protocol Gateway
ARR600 Wireless I/O Gateway
ARC600 Wireless Controller
8 (134)

1MRS758449 EN
Installation workflow
This document describes the installation and configuration procedures. The theory of e.g.
IP networking and planning is only briefly explained as it is not in scope of this
document. The work flow has been separated into two parts:
1. The procedures for planning and decision making
2. The actual installation procedures
Fig. 3-1 The installation workflow

Tools needed
It is expected that the M2M GW and Wireless Gateways/Controllers are locally accessible,
while performing the initial configuration. Installing, configuring and testing in a
distributed environment may cause unnecessary site visits.
The following is needed:
9 (134)

1MRS758449 EN
The devices; Wireless Gateways/Controllers and M2M Gateway

Installation computer with Ethernet interface and browser
Cables and power supplies
Possible mounting brackets and tools
Software: Web browser, optionally an SSH client (e.g. PuTTY in Windows)
Before starting
Before starting the installation and configuration, make sure that the following
aspects are covered.
Selecting the cellular operator
Select the cellular operator, whose SIM cards are to be used. You may check the
signal strength and service availability at the site with a cellular phone. Note that
prepaid SIM cards may not work with this solution.
For the billing point of view, it is recommended to choose an operator providing flatfee rates for cellular data transfer, especially if the amount of data transferred over
cellular network is large. Compare the local operators based on fees and network
availability at the site.
Pre-installation checklist
Go through the following check list, in order to ensure that you have all required
aspects covered and available:
SIM cards (with cellular data service enabled)

PIN codes, if enabled
Cellular access point name, username and password
IP networking plan
One public, static IP address for M2M Gateway (can be D-NATed and portforwarded from public IP border router to LAN or DMZ of the main site)
Passwords
IT department for assistance, if present (e.g. for border firewall D-NAT and
port forwarding configuration)
Manuals for every device related to the installation
Cables (network, power, serial, etc.)
Antennas for the devices, external antennas if needed
Power supplies for each device
Grounding, especially if using shielded Ethernet and serial cables
10 (134)

1MRS758449 EN
DIN rail mounting kits, if needed

A computer for installation, e.g. a laptop with Windows operating system
11 (134)

1MRS758449 EN
Configuring the installation computer

A computer is needed for configuring the M2M Gateway and Wireless
Gateways/Controllers. Any modern computer with Ethernet port can be used. In this
document, there are detailed instructions for PC with Windows 7. If youre using a
different operating system, refer to the respective documentation from the provider of the
operating system.
1. In a Windows 7 PC, go to Control Panel Network and Internet Network
and sharing center Change adapter settings. Locate the LAN adapter; it may be
named differently in your computer.
Fig. 4-1 Network connections

2. Right-click the LAN adapter and select properties from the context menu. In the
properties screen, select the Internet Protocol Version 4 (TCP/IPv4) and click
properties button.
12 (134)

1MRS758449 EN
Fig. 4-2 TCP/IP protocol properties

3. When the properties page has opened, type in the IP address and netmask. There is
no need for default gateway or name resolution at this point. The IP address would be
10.10.10.11 and netmask 255.0.0.0. These settings will define the laptop to the same
LAN subnet as M2M Gateways default WAN IP address 10.10.10.10.
13 (134)

1MRS758449 EN
Fig. 4-3 Changing the IP address

4. You may now close the Network Connections window. Proceed for cabling the
devices as in the next chapter.
14 (134)

1MRS758449 EN
Cabling the field devices

The devices connection cables are as follows.
Power supply cable
The Wireless Gateways/Controllers are shipped without a power supply. Power
supplies with cable are stocked; contact the sales department for more details on
pricing and availability. The input voltage range is 1236 VDC for dual SIM
models and the single SIM models are rated for 1248 VDC. Connect the power
supply cord, only when the device is powered off from the power switch. The
polarity of the input pins is printed to the device.
Ethernet cable
CAT 5e unshielded Ethernet cable is recommended. There is also an Accessory Kit
available, including the Ethernet cable, as well as power supply and serial console
cable.
Serial cable for console port
When connecting a computer to devices console port, a cross-connected (null
modem cable) is used. In dual SIM products the cable is equipped with D9 and RJ45
connectors. The Lite models have D9 male serial console connector, so the D9-D9
null modem cable is used. In Lite models, there is also a switch for selecting serial
port RS1 operation mode (either console port or application serial port). The serial
console settings are as follows: Data speed: 115200 bps, Data bits: 8, Parity: none,
Stop bits: 1, Flow Control: no flow control.
Serial cable for RS1 application port
In dual SIM products, the RS1 port is configurable between RS-232 and RS-422/485.
Full and half duplex are supported. Switch off the device before changing the DIP
switches states. Do not connect serial cable before verifying the DIP switch positions.
The pinout is described in the users guide. In Lite models, the configurable serial port
is RS2 and the RS1 port is RS-232 only.
Serial cable for RS2 application port
In dual SIM products, the RS2 application port is always type of RS-232. In Lite
models, the RS2 port is configurable between RS-232 and RS-422/485 and the RS1
15 (134)

1MRS758449 EN
port is always type of RS-232. Both RS1 and RS2 port connectors are D9 type in all
models.
Antenna
If the signal in the site is weak or the device is located inside a cabinet, the signal
level may not be sufficient for operation when using the standard antenna. External
antenna can be connected with suitable cable.
Antenna connectors
An external antenna with a cable equipped with the following connectors can be
used.
FME (dual SIM products), male gender in the device itself, female in the
antenna or antenna cable
SMA connector (Lite models; C- P- and R-series), female gender in the
device itself, male in the antenna or antenna cable (the connector is ordinary
SMA).
Antenna type
The recommendation is to use an omnidirectional antenna, which has an even gain in
every direction. Antennas with 3 to 9 dBi gain are recommended, the higher gain the
better. If there is a poor signal level at the site, a directional antenna can be used. It
must be pointing to the cellular base station having the strongest signal. The
polarization of the cellular antennas is vertical; hence mount the directional Yagi
antenna so that the elements are vertically aligned.
Inserting SIM card
Make sure that the SIM card has cellular data plan enabled. You may test the SIM in a
smartphone in order to verify the data transfer capability of the subscription.
If the SIM card requires PIN number, you will need to configure the PIN number in
the device prior to inserting the SIM card. In case of a wrong PIN defined, change the
PIN in web HMI, insert SIM card to a cellular phone and enter the correct PIN. The
device itself tries PIN only once in order to avoid SIM card lockup.
Use standard mini SIM cards. A micro or nano SIM card is not compatible unless a
separate adapter is used (such adapters are not recommended). When the SIM card is
inserted and the device is powered on, the SIM LED should be lit after approx. a
minute from starting (dual SIM products). The SIG LED indicates strong signal (LED
lit), weak signal (LED blinking) or no signal (LED not lit).
16 (134)

1MRS758449 EN
1) Eject the SIM card cradle from the device by pushing the green/yellow eject
button in the SIM holder with e.g. an unfolded paper clip.
Push the button
Fig. 5.7-1 SIM eject button

2) Insert the SIM card to the holder so that the clipped notch aligns with the notch in
the cradle and the electrical contacts of the SIM card are facing upwards.
Fig. 5.7-2 SIM card and holder
3) Insert the holder to the device. Make sure the cradle slides to the rails in the
connector. Push the holder all the way in until it stops.
SIM CARD CRADLE
Rails
Eject
button
Fig. 5.7-3 Rails for SIM card holder
17 (134)

1MRS758449 EN
Cabling the M2M Gateway

Connect the Ethernet cables and possible other cables before connecting the power
supply cable.
Power supply
connector
Keyboard
connector
PS/2
VGA
Connector
15-pin
Port 1: eth0
WAN port
Port 2: eth1
LAN port
Fig. 6-1 M2M Gateways connectors

There are two Ethernet connectors at the back side of the standard M2M GW. The first
one (left one, when seen from the back side of M2M GW) is the WAN port of M2M
GW. It is the eth0 interface in M2M's graphical user interface.
The second Ethernet connector (right one, when seen from the back side of M2M GW) is
the LAN port of the M2M GW. It is the eth1 interface in M2M GW's GUI.
In the Enterprise Edition of M2M GW, there are four Ethernet connectors. Again, the
first one from the left (when looked from behind) is the WAN port and the second one if
the LAN port. The rest two are unused.
There are also connectors for local console with analog VGA connector for monitor and
PS/2 or USB port for local keyboard. The local console is practical in some situations
(e.g. if one has locked him/herself out from the Ethernet ports by firewall), but it is not
usually needed, while configuring the M2M GW.
The power supply of M2M GW is rated for input voltages between 100-240 Volts AC.
The connector in M2M GW is standard IEC 60320, type C14 that accepts the C13 plug,
the wall socket or rack power line connector type varies country by country. The
Enterprise Edition has two power connectors; both of them must be connected.
18 (134)

1MRS758449 EN
Note that the Ethernet port LEDs may be lit even if the M2M GW server is in standby
mode (powered off but power cord and Ethernet cable attached).
19 (134)

1MRS758449 EN
Grounding
In order to avoid device failures due to ground loops or due to other grounding
problems, it is essential to verify that proper actions are taken regarding the
grounding of the equipment.
The grounding of the equipment depends on the use case and also on the national
electrical and safety regulations. Some best practices for grounding of the
equipment are as below:
Consider whether the Shielded Twisted pair Ethernet cable (STP) is
needed, if not, use unshielded cable (UTP) to avoid ground loops.
Use one common grounding point.
Although data transmission is balanced in RS-485, a proper grounding
may be required if the distance between devices is long and/or they dont
otherwise share the common ground.
The most common reason for RS-485/422 circuit damages is the
excessive potential difference between the devices. When separate
grounding is required connect each remote device to the common ground
wire. Connect the common ground to devices signal ground (pin 5) and
to serial connector chassis.
Using optical isolators in serial ports is recommended in e.g. electrical
substations or similarly demanding electrical high-noise environments.
Note that the input voltage DC ground pin of the device has a galvanic
connection to the chassis.
20 (134)

1MRS758449 EN
Configuring the M2M Gateway

Basic configuration guidelines
This document provides an example configuration for OpenVPN tunnel between
Wireless Gateways/Controllers and M2M Gateway. Often one cant freely select
the IP addresses; theyre defined by customers IP planning and already existing
networks. The network IP planning needs to be performed case-by-case.
Unique subnets
In typical routing (Layer 3) configurations, there are following unique, nonoverlapping IP addresses and networks in M2M solution with M2M GW and
Wireless Gateways/Controllers.
OpenVPN peer IP addresses
These virtual IP addresses are denoting the endpoints of the VPN tunnel. They
can be used for connecting the peer on the other side of the VPN tunnel (i.e.
either M2M GW or Wireless Gateway/Controller). They have also meaning in
the routing table entries. The peer IP addresses are available when the VPN
tunnel is up (but may not be answering to ICMP ping).
Wireless Gateways/Controllers LANs
In a typical installation, each field device has its own, unique LAN. These LANs
are tunneled (routed) over OpenVPN tunnel to the M2M GW at the main site.
This enables e.g. a control application (SCADA, etc.) connecting to the Ethernet
devices in Wireless Gateways/Controllers LANs by using devices LAN IP
addresses directly.
The M2M GW works as a router between main sites LAN and Wireless
Gateways/Controllers LANs. A control application server will need only one
CIDR (Classless inter-domain routing) route telling that the Wireless
Gateways/Controllers LANs are accessible via M2M GW.
M2M GWs LAN
This is usually the main sites LAN, where the server running control application
is located and this connected to the same network segment than the M2M GW.
There may be a DMZ as well, where the internet-accessible servers are separated
from companys LAN. Nevertheless, the control application needs to have route
to the M2M GW in order to access devices in Wireless Gateways/Controllers
LANs.
21 (134)

1MRS758449 EN
M2M GWs WAN

Usually the WAN interface of M2M GW is connected to the internet. The
connection can be direct or D-NATed/port forwarded as in the DMZ case. In
some installations, the WAN is not internet but some private wide area network.
Wireless Gateways/Controllers cellular IP addresses
The Wireless Gateway/Controller receives an IP address from cellular network.
This IP address may be public or private, but typically it is a dynamic IP (i.e.
changing frequently). This address cant usually be directly connected to.
Therefore, the Wireless Gateway/Controller uses the cellular IP for connecting to
M2M GW and establishing the VPN connection.
If Wireless Gateways/Controllers are used without M2M GW, there is a need for
private access point, providing a fixed cellular IP address for the particular SIM
card (alternatively, a dynamic DNS service can be used, but this requires that the
cellular IPs are public). The D-NAT needs to be configured in Wireless
Gateway/Controller in order to access a device in Wireless
Gateways/Controllers LAN. Note that the devices GPRS IP must be used in
D-NAT scenario, a private access point only routes SIM IP addresses.
Customers other subnets
In customers main site, there may be several unrelated LAN segments and other
routed IP networks. What makes them relevant in this M2M solutions scope is
that the IP addresses and subnets must not overlap. Therefore, always create an
IP plan with unique subnets in the system and note that it is within the address
space limits defined by already existing infrastructure.
Once the cables are connected and the installation computer used for configuring
the M2M GW is set belonging to the same network as M2M GW, the M2M GW
itself can be configured. Follow the next steps for configuring the M2M GW.
Logging in to the M2M Gateway
The default URL for accessing the M2M GW is https://10.10.10.10:10000
Note that the M2M GW's Web HMI is using the HTTPS and the certificate in
use is "self-signed", which means that it is not among the trusted certificates in
web browsers. Therefore, once logging in, the user must click the add an
exception to add a security policy exception (Firefox) or click "Continue to
this website" (Internet Explorer or GoogleTM ChromeTM).
22 (134)

1MRS758449 EN
Fig. 8.2-1 The main screen of M2M Gateway

Configuring network interfaces
1. Click the Network Configuration icon.
2. Click the Network Interfaces icon. You will see the Network Interfaces screen.
Fig. 8.3-1 The main screen of M2M Gateway
As you are now connected to M2M GW via eth0 interface, which is the future
WAN port, it is recommended to change the eth1 (the LAN port) first
Fig. 8.3-2 The network interfaces
23 (134)

1MRS758449 EN
3. In the Edit Bootup Interface screen of eth1, set the interfaces attributes as
follows. You may change the IP address and netmask according to your setup
(e.g. if the 192.168.0.1 is reserved for the internet gateway, you may configure
the M2M GW as e.g. 192.168.0.2).
a. Name: eth1
b. Netmask: 255.255.255.0
c. MTU: Automatic
d. IP Address: 192.168.0.1, static
e. Broadcast: 192.168.0.255
f. Activate at boot: Yes
g. Enable proxy ARP: No
Fig. 8.3-3 Configuring the network interface

4. Click save and apply to make the changes permanent.
Note: The next step will manipulate the interface, which is used for your current
connection to the M2M GW. After you have changed and applied the IP address
of eth0, your browser will not be able to connect to the M2M GW with URL
https://10.10.10.10:10000 but instead you must change your installation
computers IP address to belong to the LAN of M2M GW.
Respectively, youll need to change the Ethernet connector from M2M GWs
WAN interface (leftmost when looked at back side) to LAN interface (next to
the WAN interface).
5. Click the eth0 text to configure the eth0 interfaces settings.
24 (134)

1MRS758449 EN
Fig. 8.3-4 The eth0 interface

In the Edit Bootup Interface screen of eth0, set the interfaces attributes. Because the
public IP address of M2M GW is case dependent, it is not possible to define any
example. If the M2M GW is located to DMZ, the eth0 IP address can be a private IP
address as well.
Set the eth0 interfaces IP address and other attributes based on information received
from Internet service provider (ISP) or from ICT department.
a. Name: eth0
b. Netmask: <from_ISP>
c. MTU: Automatic
d. IP Address: <from_ISP>, static
e. Broadcast: <from_ISP>
f. Activate at boot: Yes
g. Enable proxy ARP: No
Fig. 8.3-5 The eth0 interface configuration

6. Click Save and apply to make the changes permanent. Now the browser
seems to lose connection, because the eth0 port is now set as WAN port.
25 (134)

1MRS758449 EN
7. Change the IP address and netmask of your installation computer to belong to

the M2M GWs LAN. The example IP address would be 192.168.0.10 and
netmask is 255.255.255.0.
8. Change the LAN cable from installation computer to M2M GW to Ethernet port
2 (eth1, LAN port) at M2M GW. After this step, use the following example
URL to connect to the M2M GW: https://192.168.0.1:10000. This is the LAN
address of M2M GW in the example configuration. If your installation differs
from the example, use respective M2M GWs eth1 IP address to log in to the
system.
Configuring the routing and gateway in M2M GW
1. In the Network Configuration, click the Routing and Gateways icon
2. The following screen opens.
Fig. 8.4-1 Configuring the default gateway

3. Fill the Default routes field usually with only one route, the gateway of the
public IP of M2M GW or the gateway to your border router in DMZ case.
Usually you will receive the value for this parameter from the ISP or from IT
department. Check that the defined default route interface is eth0; this is by
default the WAN port of M2M GW and M2M GWs firewall is preconfigured
respectively.
Note: Verify that the Act as router is set to Yes. This is important, because
otherwise the M2M GW will not route between interfaces eth0, eth1 and VPN
tunnels.
At this point, there is usually no need for adding static/local routes. If the
SCADA or other control entity is in a different subnet than M2M GWs LAN,
26 (134)

1MRS758449 EN
you will need to define a static route to that subnet. Do not define static routes
over dynamic VPN tunnels.
27 (134)

1MRS758449 EN
Configuring the Wireless Gateway/Controller

The following chapters are describing the main menu items in the Web HMI.
This information is supplemental to the users guide.
Fig. 9-1 Wireless Gateways/Controllers menu structure, firmware 3.2.6

System
Welcome page
The welcome page of the Web HMI shows the identification details, such as
product name, firmware and hardware versions and devices serial number.
The hostname is always seen in the upper right corner of the horizontal
information bar.
28 (134)

1MRS758449 EN
Fig. 9.1.1-1 The welcome page

General settings
The general settings include mostly informational values, except the
hostname and domain name parameters.
Fig. 9.1.2-1 General settings

Hostname
Use the following characters in the hostname: a...z, A...Z, 0...9 and (hyphen).
Note: The Devices hostname must match the VPN peer name in M2M
Gateway if SSH-VPN, L2TP-VPN or Arctic Patrol is used.
Domain
Domain name serves as humanly memorable name for Internet participants,
like computers, networks, and services. If the device is set to belong to a
domain, you can set the domain name in this field. Usually it can be left
blank.
Location, Contact, Description
29 (134)

1MRS758449 EN
Free-text fields for respective informational data. These fields can be left
blank.
Web HMI enabled
Usually the Web HMI is always enabled. The setting cannot be changed via
Web HMI.
Menu Style
By default all menu items are shown. To avoid clutter on the screen, the menu
can be collapsed to show only main items.
Session timeout
The devices Web HMI session will time out after specified time (in minutes)
and a new login is needed. The maximum adjustable session timeout is 1440
minutes.
Time
There is an internal real time clock (RTC), which keeps the devices time and
can be synchronized from an NTP server. The time and date can be set
automatically or manually (also manually copied from the computers clock).
There is an internal super capacitor for keeping up the real time clock in a
power outage. In case of long unpowered storage, the capacitor may run out
of power and the real time clock is cleared to time poque, which is the year
1970. While deploying a storage unit, it is a good practice to verify the time.
Note: The OpenVPN will compare the certificates key expiration time with
current reading of RTC. If the certificate is too old (expired) or too new (not
yet valid), the OpenVPN tunnel will not be established.
The device will try resolving the current date and time from cellular network,
but in case it fails, verify that the devices and M2M GWs clocks are in
correct time/date and in matching time zones.
Manual mode
In the manual mode, the time is set manually or copying it from a PC (may
not work if the browser has scripts blocked).
30 (134)

1MRS758449 EN
Fig. 9.1.3-1 Manual time settings

Automatic mode
In the automatic mode (client), the time is synchronized against an NTP (or
SNTP) server. The NTP server is always defining the time in UTC time. The
time zone can be set so that the device will show the time in a local format.
There is also an NTP server in the device (NTP client and server), this
enables the Wireless Gateway/Controller working as NTP server for the LAN
devices.
Fig. 9.1.3-2 Automatic time settings

Status
The status screen is most useful for a quick snapshot of devices condition.
31 (134)

1MRS758449 EN
Fig. 9.1.4-1 Devices status

The status screen provides the following information:
Product name
The product name and product code is displayed.
Hardware and firmware versions, serial numbers
The firmware version is checked from this screen. When contacting to the
Technical Support, always define the product name and firmware version.
The unique device serial number identifies the device.
Uptime
The uptime of the device is shown. If the uptime is short, the device has been
just rebooted:
Manually via Web HMI or command line
Because of lack of power (e.g. blackout or power supply fault)
By devices internal watchdog rebooting the device (e.g. no answer to
monitor ping messages, or a wrong ping target)
32 (134)

1MRS758449 EN
Network interfaces
This section is essential in troubleshooting; the GPRS/WWAN interface
should be seen when the device is equipped with SIM card and the access
point settings are correct. If the gprs0 or wwan0 interface is missing, the
device hasnt been able to establish a GPRS/3G/LTE connection. Note that
some devices are showing the cellular interface differently; the interface name
may also be usb0, depending on the model.
The VPN interface will indicate the establishment of the VPN tunnel. If it is
completely missing, a VPN tunnel has not been established.
Routing table
The routing table shows the destination hosts/networks and the gateway,
through which the destination is available. The LAN subnets network
address is seen in lan0 interface and the 0.0.0.0 destination indicates the
default gateway interface. The routes defined by VPN are appearing in the
routing table once the VPN tunnel is established.
Link status
The dual SIM models have one Ethernet WAN port (wan0) and three
switched Ethernet LAN ports (lan0...lan2). Link status shows the established
Ethernet links as well as cellular link (GPRS/EDGE/3G/LTE depending on
the model). The Lite models are having only one Ethernet interface, which
has operating modes of WAN, LAN and auto.
The link status only shows the established links. The cellular link shows the
information from the time the modem information was last updated. For
recent information, go to Tools Modem info page and click Refresh.
VPN status
The VPN status displays the VPN tunnel and the state of it (enabled/disabled,
active or inactive).
Firewall Status
Application tracking = Track applications that create and use dynamic ports
like FTP.
1. Filter = Use packet filtering firewall
2. LAN-In accept = Accept packets from LAN to the device (e.g. DNS or
DHCP requests)
3. Pass vpnin = Accept packets from VPN tunnel
33 (134)

1MRS758449 EN
4. GUI anti-lockout = Always allow the access to Web HMI regardless of

firewall rules
5. Pass lanssh = Accept SSH client connections from devices LAN
6. LAN-LAN accept = Allow traffic between multiple subnets of devices
LANs
7. Pass lanvpn = Allow traffic from LAN to VPN tunnel
8. Pass vpnlan = Allow traffic from VPN tunnel to LAN
9. Lan-Out accept = Allow traffic from LAN to Internet over
GPRS/3G/LTE
10. D-NAT = Destination NAT/port forwarding (for forwarding packets
from cellular WAN to devices LAN)
11. S-NAT = Source NAT (enabling e.g. LAN to Internet access, on by
default)
12. Qos = Alter Qos bits in TCP header (not used)
13. Deny ipv6 = Deny IP v.6 packets
14. Reduce OpenVPN bridge multicast = Allow only ARP, DHCP, ICMPv6,
and STP Ethernet broadcast/multicast frames.
15. Total fail = Number of failed firewall rules
16. Total ok = Number of working firewall rules
Serial port status
Shows statuses of serial port RS1 (RS-232,485,422) and RS2 (RS-232);
speed, data bits, parity, stop bit(s), handshaking and operating mode:
TCP server (accepts connections in a specified port)
TCP client (sends data to a servers specified port)
Modbus RTU (in Protocol Gateway and Wireless I/O Gateway models
only)
IEC-101 (in Protocol Gateway and Wireless I/O Gateway models
only)
Console (indicates that the serial port is in console mode, in single
SIM models only)
Network
Ethernet ports (dual SIM models)
The characteristics of Ethernet ports are defined below (see next chapter
for Lite models). It is recommended to leave the media and MDI settings
to Auto, unless there is a problem in communication between Wireless
Gateway/Controller and some Ethernet device.
34 (134)

1MRS758449 EN
Fig. 9.2.1-1 Ethernet port settings

Swap LAN and WAN ports
In some configurations, more than one WAN port is needed, but only one
LAN port is sufficient. In such cases, the LAN and WAN ports can be
swapped so that there will be three WAN ports and one LAN port. This
option is available in Wireless Gateways/Controllers having four Ethernet
ports.
WAN media
The speed and duplex of the WAN Ethernet port can be set to the
following:
100 Mbits/s, full duplex, 100 Mbits/s, half duplex, 10 Mbits/s, full duplex
or 10 Mbits/s, half duplex.
WAN VLAN tagging
Enable/disable VLAN tagging on WAN interface. The VLAN tagging is a
feature presented in the 2.4.1 version of 3G Wireless Gateways firmware.
For more information on VLAN configuration, refer to Application Note
3G GW VLAN Guide. Do not enable VLAN tagging in a normal scenario.
LAN VLAN tagging
Enable/disable VLAN tagging on LAN interface. For more information
on VLAN configuration, refer to Application Note 3G GW VLAN Guide.
Do not enable VLAN tagging in a normal scenario.
Note: Do not configure and enable LAN VLAN tagging if your
configuration computer is not a part of the VLAN, as you will lose the
access to the device via LAN interface.
35 (134)

1MRS758449 EN
Lan0, 1, 2 media
The speed and duplex of the lan0...2 Ethernet ports can be set to the
following: 100 Mbits/s, full duplex, 100 Mbits/s, half duplex, 10 Mbits/s,
full duplex or 10 Mbits/s, half duplex.
Lan0, 1, 2 MDI
The MDI (medium dependent interface) is the physical twisted pair
cabling Ethernet port (here 10 or 100 baseT), whereas the MDI-X port is
crossover port. The MDI-X allows using straight Ethernet cable when
connecting two computers, or Wireless Gateway/Controller and computer
(otherwise, a cross-connected cable should be used). The selectable
options are MDI, MDI-X or Auto. The Auto-selection is recommended
unless there are problems in connectivity.
Ethernet port (Lite models)
Lite models have only one Ethernet port and the Ethernet port menu item
is used for selecting the ports functional mode (port function), forcing
media type if needed (Ethernet speed and duplex) and forcing the MDI
settings. See the explanations for these menu items in the previous
chapter.
Fig. 9.2.2-1 Ethernet port settings, Single SIM models

The functional mode of the Ethernet port is selected from the following:
LAN Use the Ethernet port as local LAN port (usually
recommended)
WAN Use the Ethernet port as WAN port
VLAN Use the Ethernet port as VLAN trunk port
Auto Try first DHCP in WAN mode, then fail back to LAN mode if
no DHCP server found
36 (134)

1MRS758449 EN
Note: Usually the devices Ethernet port is used in LAN mode for
connecting Ethernet devices at site. Remember to configure the selected
port via respective menu item (Ethernet LAN, Ethernet VLAN, Ethernet
WAN).
Ethernet VLAN
Do not enable VLAN tagging in a normal setup scenario. If it is needed to
be used, see the separate VLAN Guide document.
Ethernet LAN
Change to 255.255.255.0
Fig. 9.2.2-2 Ethernet LAN settings

The Ethernet LAN defines the subnet characteristics of the LAN network.
This is the LAN at a remote site. With the M2M Gateway, this LAN can
be tunneled over VPN to the central site (i.e. routed through the VPN
tunnel).
The default mask 255.0.0.0 should be changed to e.g. 255.255.255.0 so
that the whole 10.0.0.0/8 network is not reserved by one device solely.
Note: If using the device without M2M Gateway, the devices LAN
cannot be directly accessed via cellular network. Instead, the D-NAT must
be used. See chapter D-NAT for more information.
Primary IP address, basic information
Enabled
Defines whether the local LAN interface is enabled, or not. Even if the
remote site doesnt have local area network (e.g. if remote devices are
serial-connected devices only) it may be a good practice to define LAN
networks for field devices for future use.
37 (134)

1MRS758449 EN
Interface
The lan0 is the default name of the LAN interface.
IP address, Netmask
The default IP address/netmask of the device is 10.10.10.10/255.0.0.0. It
should be changed to accommodate to remote sites IP planning. Each
field devices LAN subnet needs to be unique. The netmask defines the
size of the LAN. The 8-bit default netmask 255.0.0.0 is recommended to
be changed to a netmask that divides the network to smaller LAN subnets.
Note: The default netmask 255.0.0.0 covers the whole 10.x.x.x network.
This will affect routing if smaller subnets of 10.0.0.0/8 address space are
used. Change the netmask to e.g. 255.255.255.0, this way the first device
in this example will have subnet 10.10.10.010.10.10.255 in its use.
Example:
Device #
Subnet
IP address
Netmask
Device 1
10.10.10.0
10.10.10.10
255.255.255.0
Device 2
10.10.11.0
10.10.11.10
255.255.255.0
Device 3
10.10.12.0
10.10.12.10
255.255.255.0
Device 4
10.10.13.0
10.10.13.10
255.255.255.0
CIDR route covering all devices LANs: 10.10.0.0/255.255.0.0

Notes
The Ethernet LAN basic information page allows writing a free-text note,
which is an informational field that doesnt need to be filled.
Additional IP addresses
If needed at the remote site, an additional IP address can be given to the
device. This IP is bound to the devices LAN interface. In most cases, this
can be omitted.
Ethernet WAN
The Ethernet WAN option is used if the Ethernet WAN interface provides
access to WAN network. An example of such configuration would be to
use a DSL router or fiber channel router as a primary access path to WAN
38 (134)

1MRS758449 EN
network (i.e. Internet or another WAN network) and cellular network as a

backup access path.
If the cellular network (GPRS, 3G or LTE, depending on the model) is
solely used, the Ethernet WAN can be disabled (or defined to LAN mode
in Lite models).
Fig. 9.2.2-3 Ethernet WAN settings

WAN configuration, Enable, WAN interface
These settings are similar to LAN interfaces settings, except that the
interface name is wan0.
Configuration mode
The WAN interface can be manually configured or a DHCP server can be
used for offering the device the networking parameters, such as IP
address, netmask, default gateway, etc.
Manual settings, IP address, Netmask, Gateway
The WAN interfaces networking settings can be set manually to a fixed
IP address, netmask, default gateway, etc.
DNS servers
The DNS servers can be set manually. The DNS servers are usually not
needed in as the IP addresses are directly used. If, however, there is a
need for e.g. a PC to access Internet through the devices WAN interface,
the DNS servers can be defined. Enable DNS proxy in this case as well
(Services Common DNS Proxy).
39 (134)

1MRS758449 EN
MTU
Usually it is not needed to limit the MTU (maximum transfer unit) in the
WAN level. Leave empty for default value.
Connectivity monitor
The WAN interfaces have connectivity monitor, which is used in WAN
failover for testing the availability of a WAN interface. Enable ping
testing only if WAN failover is used. Select an always-on ping target,
which is available through the particular Ethernet WAN interface.
Mobile WAN (3G SIM1, 3G SIM2), Mobile WAN (Lite models)
The Mobile WAN is to be enabled if cellular network connection is used.
In dual SIM products, there are two cellular connection possibilities,
mobile WAN 1 and mobile WAN 2. When only one SIM card is used, it
can be put to either of the SIM slots, however, the Primary WAN must be
respectively enabled and chosen in WAN failover settings.
Fig. 9.2.3-1 Mobile WAN settings

PIN code
The 2G/3G/LTE cellular networks use a SIM card (SIM, USIM, LTE
USIM). The SIM card can be protected by PIN code (personal
identification number). If the PIN code is used, it must be entered to
40 (134)

1MRS758449 EN
Mobile WAN settings. Leave the PIN code field empty if no PIN code is
used. If a wrong PIN code is entered, correct the code and enter the
correct PIN code to the SIM card in a mobile phone.
APN type
By default, the automatic APN (access point name) discovery is
The device tries APN values based on the network ID received
cellular network. If the automatic setting is not working, set the
Type parameter from automatic to manual and define the APN,
username and APN password manually.
used.
from
APN
APN
APN
The APN parameter defines the GPRS access point name. The GPRS
access point is a set of configurations in a cellular network element,
which works as a gateway from cellular network to internet.
There are public and private access points. A public access point is
usually defined. A private access point requires contract with a cellular
operator. This M2M solution is compatible with both public and private
access points. Define the access point name as according to information
received from the cellular operator.
Authentication, username, password
If the cellular network requires authentication for using the access point,
the access points username and password need to be defined in the
device. In this case, select the authentication type (PAP, password
authentication protocol or CHAP, challenge handshake authentication
protocol) as according to information received from cellular operator.
DNS selection, DNS servers
Allows user defined DNS servers, receiving DNS server IP addresses
from cellular network or leaving DNS configuration as disabled. The
DNS servers are used for resolving names to IP addresses.
This M2M solution doesnt require DNS services as the IP addresses are
used instead of hostnames. However, if the Wireless Gateway/Controller
is used as a modem, providing the internet access to a PC, it is
recommended to leave the DNS enabled and automatic. The DNS servers
addresses must be manually defined if the selection type is manual (set
the values as according to information received from cellular operator).
41 (134)

1MRS758449 EN
Connectivity Monitor ping target, ping IP

The WAN interfaces have connectivity monitor, which is used in WAN
failover for testing the availability of WAN interface. Enable ping testing
only if WAN failover is used. Select an always-on ping target (ping IP),
which is available through the Cellular WAN interface.
Note: If youre using only one WAN, e.g. Mobile WAN, do not enable
the WAN-level connectivity monitor, but only the vertical left menu bars
Monitor, which is the main system monitor of the device.
Timeout and retries
The timeout for one ping attempt is definable between 5120 seconds.
Usually, it is recommended to allow at least 30 seconds for one try and
retry count e.g. 2.
Note: The WAN failover has also failure tolerance setting for each WAN,
which multiplies the WAN level retries.
Advanced settings, network service, frequency, operator
There are advanced settings for defining the cellular parameters, like
network service or frequency and operator code. Usually these can be left
as automatic/default values. If the device is in a border of two countries,
it may be needed to define the operator code so that there is no roaming
taking place.
MTU
Usually it is not needed to limit the MTU (maximum transfer unit) in the
WAN level. Leave empty for default value.
Idle timeout
The Mobile WAN can be restarted if there is no traffic in the selected
duration of time. If set, this value should be longer than Monitors ping
interval. This can be usually left blank (no duration limit).
Reconnect interval
Reconnect either with constant time value or increase the value in every
connection attempt to decrease billing in a case where there is something
wrong in the cellular network. For quick recovery, it is recommended to
set the value as Constant. A recommended constant value would be 10
seconds between attempts.
42 (134)

1MRS758449 EN
Mobile WAN (3G SIM2), dual SIM models

The Mobile WAN 3G SIM2 is similar to SIM1. This slot is used in a
two-SIM configuration (remember to add this interface to WAN failover
settings, if enabled). The connectivity monitor must be configured and
enabled in both SIM1 and SIM2 interface configurations in dual-SIM
setup. See the dual SIM configuration application note for details.
WAN failover
It is important to understand how the WAN failover works. The WAN
interface means the connection interface from the remote sites Wireless
Gateway/Controller to the main site. Usually the WAN connection is the
cellular connection, but it can also be a local Ethernet connection to an
external device (e.g. to a DSL modem, leased line or satellite modem),
which in turn has makes the connection to the main site.
WAN interfaces are set according to desired priority in WAN failover;
the main WAN interface is the primary WAN. If the primary interface
becomes unusable for some reason, or it is not working right from the
start of the device, it switches to the backup WAN interface. If the
backup interface fails as well, the device fails over to the secondary
backup WAN interface. This cycle is repeated until a working interface
is found.
The WAN failover settings are defining how often the primary WAN
interface is tested, while a lower priority WAN is in use (Note that the
device has only one cellular modem, which is used by both SIM cards. If
e.g. SIM1 is defined as primary interface, in SIM2 failover situation, the
SIM2 WAN connection is disrupted each time the SIM1 primary
connection is tested).
43 (134)
1MRS758449 EN

Primary WAN
Primary WAN timeout * fault
tolerance
Backup WAN
Backup WAN timeout * fault
tolerance
Secondary backup
WAN
Secondary backup WAN
timeout * fault tolerance
Fig. 9.2.5-1 WAN failover logic

The following picture illustrates two WAN connections; the primary
WAN is an ADSL connection to the main site and the secondary WAN
is the GPRS (or 3G) connection to the main site. If the primary WAN
connection is not working or fails the ping tests, the device automatically
switches to the lower priority WAN (secondary in this case).
Main Site
Remote Site
Arctic
GPRS
Secondary WAN
Cellular
Operators
Network
Viola M2M
Gateway
MAIN
LAN
Primary WAN
Access
Router #2
Arctic LAN
ADSL
Operators
Network
Access
Router #1
REMOTE
LAN
Remote
Router
Main
PC
PC 2
PC 1
Fig. 9.2.5-2 Primary and secondary WAN

An example of primary and secondary WAN is seen above.
WAN default route
Defines the concurrent WAN interface as default route for outgoing
packets. In most setups, this setting must be enabled. (In certain GPRS
44 (134)

1MRS758449 EN
private access point configurations, enabling WAN default route may

lead to asymmetrical routing).
Mobile WAN On Demand
If enabled, the mobile WAN is activated only when required and can be
used only without VPN connections. This option is usually not enabled.
Force VPN restart
This parameter will force the VPN tunnel termination and reestablishment when the device is changing from one WAN interface to
another. When the VPN is used and there are several WAN interfaces,
this parameter should be set as enabled. Otherwise the VPN tunnel may
not be aware of changes in underlying data path.
Recovery Interval
Defines how often the availability of higher priority WAN is checked
when using lower priority WAN. Leave empty to try only when lower
priority terminates. Do not define too short recovery interval (except
when e.g. testing). Note that the backup cellular WAN is disrupted,
while the primary cellular WAN is tested.
Recovery Hysteresis
Defines how many seconds the higher priority WAN must be available
before starting to use it again. Usually left empty (60 seconds default).
Primary WAN
It can be SIM1, SIM2 (if available in the device) or Ethernet WAN. The
fault tolerance defines the number of WAN connection retries before
switching to lower priority connection.
Backup WAN
It can be SIM1, SIM2, (if available in the device), Ethernet WAN or
disabled. The fault tolerance defines the number of WAN connection
retries before switching to lower priority connection.
Secondary backup WAN
It can be SIM1, SIM2, (if available in the device), Ethernet WAN or
disabled. The fault tolerance defines the number of WAN connection
retries before switching to try the primary connection.
45 (134)

1MRS758449 EN
Monitor
The Monitor provides important main level watchdog functionality. As
opposite to WAN and VPN health checks, the Monitor is connected to
internal hardware and provides overall health checking. Furthermore,
Monitor is able to perform functions like WAN and VPN interface
restarts and even rebooting the device if a problem situation is detected. It
is recommended to always enable the Monitor.
Fig. 9.2.6-1 Monitor settings

Target, secondary target
The Monitors ping target must be always-on type. If there is M2M
Gateway in the setup, the ping target can be set to M2M Gateway's VPN
peer IP address (in SSH-VPN or L2TP-VPN use case) or M2M GW's
eth1 LAN interface IP or M2M GW's public IP (in OpenVPN use case).
If no M2M Gateway in the installation, use other always-on ping target.
Interval, timeout, retries
These parameters are defining how often the ping target is pinged, what
the timeout for receiving the ping response is and how many times the
ping is retried.
Count, success
These values are defining exactly how many ping messages is sent in one
trial and how many replies are counted as a success.
Warning: Defining unavailable ping target causes unnecessary
disruption in the VPN tunnels and also device restarts. Double-check the
availability of the ping target by e.g. pinging the address from devices
command line.
46 (134)

1MRS758449 EN
Static routing
The static routes can be set if there are several subnets in devices LAN
(i.e. remote sites LAN). Usually static routes are left undefined as the
VPN tunnel logic handles all necessary routing. Do not define static
routes over dynamic VPN tunnels; instead use routing parameters under
VPN menu.
SMS config
The SMS config enables certain get and set commands to be sent to the
device via cellular phone SMS messages. The purpose for this is to get the
status of the device, get the detail of devices configuration or reboot the
device. For security reasons, if this feature is used, an allowed phone should
be configured; SMSes from other numbers would then be ignored. Below is a
list of available commands.
GET GPRS COMMANDS
get gprs enabled
Description: returns is the GPRS enabled or not
Return values: 0=disabled,1=enabled,error
get gprs pin
Description: returns the PIN code
Return values: PIN code or error
get gprs apn
Description: return the GPRS apn
Return values: apn name or error
get gprs username
Description: returns the GPRS PAP user name
Return values: user name or error
get gprs password
Description: returns the GPRS PAP password
Return values: password or error
get gprs signal
Description: returns the GSM signal level
Return values: signal level or error
get gprs operator
Description: returns the name of GPRS operator
Return values: operator name or error
47 (134)

1MRS758449 EN
get gprs settings (enabled, pin, apn, user, passwd, idle,

defroute)
Description: returns the most important GPRS settings in one
message
Return values: error or comma seprated list of:
o enabled - GPRS enabled or not
o pin - GPRS PIN code
o apn - GPRS APN name
o user - GPRS user name
o passwd - GPRS password
GET ETHERNET COMMANDS

get ethernet status [lan|wan]
Description: returns ethernet runtime status
Return values: error or comma-separated list of ethernet ip, netmask
GET SERVICES COMMANDS
get services dnsproxy
Description: is the DNS proxy/forwarder enabled or not
Return values: 0=disabled,1=enabled, error
get services ssh
Description: is the SSH server enabled or not
Return values: 0=disabled, 1=enabled, error
OTHER GET COMMANDS
get hostname
Description: returns hostname
Return values: hostname or error
get fs
Description: returns the operating system file descriptor usage
Return values: error or space separated list of:
o allocated file descriptors
o currently free file descriptors
o maximum amount that can be allocated
get date
Description: returns the date and time
Return values: date and time or error
get temperature
Description: returns devices internal temperature
48 (134)

1MRS758449 EN
Return values: temperature in degrees of Celsius or error

get firmware
Description: returns the name and version of firmware
Return values: firmware name and version or error
get version
Description: returns the version of smsconfig
Return values: smsconfig version or error
SET COMMANDS
set reboot
Description: reboots the device (soft reboot)
Parameters: none
Return values: ok or error
set echo
Description: echoes back the message
Parameters: [message]
Return values: message or error
VPN
All VPN-related settings, regardless of the VPN type, are defined under VPN menu. The
following VPN tunnels can be chosen:
OpenVPN
SSH-VPN
L2TP-VPN
IPsec (note that the M2M GW doesnt terminate IPsec tunnels).
Certificates
In the certificates menu, the local identity and trusted CA are defined. Both are
created in M2M Gateway. Local identity is used for authenticating the Wireless
Gateway/Controller to M2M Gateway and trusted CA certificate guarantees the
Wireless Gateway/Controller that the M2M Gateway is authentic.
Note that the local identity and trusted CA certificates are self-signed by M2M
Gateway. These certificates are used internally in this M2M solution. There is no
need for using external Certificate Authorities for issuing these certificates.
49 (134)

1MRS758449 EN
IPSEC-VPN remotes, tunnels

See a separate IPsec application note for example configuration (configuring the
devices IPsec client against a third-party IPsec router). Note that the M2M Gateway
product doesnt terminate IPsec tunnels.
L2TP-VPN
L2TP-VPN is inherently insecure, as there is no encryption used. While it is not the
most recommended VPN implementation, there may be cases, where it is justified.
The L2TP-VPN is recommended only for networks, where there is an additional
safety layer and there is also a need for fast and lightweight VPN.
Note: The Wireless Gateways/Controllers hostname, L2TP-VPN login name and
L2TP-VPN peer name (in M2M Gateway) must be identical.
OpenVPN
The OpenVPN is the recommended VPN tunnel for Wireless Gateways/Controllers
with M2M Gateway. It is reasonably light-weight and implements encryption. In
addition, the M2M Gateway is able to create OpenVPN client configuration for PC
computers for remote operation and management use.
There are the following setup options:
Easy OpenVPN setup wizard for importing client configuration package
created by M2M GW
Advanced OpenVPN setup completely manual setup
OpenVPN Static Key The Wireless Gateway/Controller is able to work as
static key OpenVPN server or client. See a separate Technical Note for this
feature.
SSH-VPN, SSH-VPN keys
The SSH-VPN within this solution is implemented with OpenSSH. The SSH-VPN
uses cryptographic keys for authentication and encrypted transport layer. SSH
packets are encapsulated inside TCP packets.
When configuring SSH-VPN, the SSH keys need to be manually exchanged between
M2M Gateway and Wireless Gateway/Controller. Copy-paste the keys between the
two and note that the SSH-keys are longer than the visible part in Wireless
Gateways/Controllers and M2M GWs Web HMI.
50 (134)

1MRS758449 EN
Note: The Wireless Gateways/Controllers hostname and SSH-VPN peer name (in
M2M Gateway) must be identical.
Firewall
The Wireless Gateway/Controller has packet filtering, stateful firewall, which is highly
configurable. By default, the firewall is enabled and pre-set rule list for standard traffic is
applied. The recommended approach is to drop all packets by default and then "whitelist"
wanted packets, most frequent first in the list.
Stateful firewall
The term refers to the firewalls ability to remember the state of TCP/IP connections. It
allows both a simplified firewall configuration and detailed filtering. Typically, LAN
devices are allowed to connect to and then communicate with other Internet devices.
However, nobody from the Internet should be allowed connecting to devices LAN side. As
the firewall understands the connection states, it can be configured to allow outgoing
connections and the communication between established connections but deny all connection
attempts initiated from the outside of the LAN.
Connection states
When the firewall inspects the IP packet, it will determine the packet status to be one of
following:
NEW packet requests a new connection
ESTABLISHED packet belongs to a connection that is already open
INVALID packet is not part of any connection or is malformed
RELATED packet is somehow related to an existing connection or connection attempt.
This is usually used to match ICMP destination unreachable messages.
The state information mostly applies to TCP traffic but for stateless UDP traffic the
request and response rules should be defined separately.
Filtering actions
The firewall will make one of the following decisions with regard to the packet.
PASS packet is accepted
DROP packet is silently dropped and nobody ever sees it again
REJECT packet is dropped, but the other end of the connection is notified with the
ICMP message port unreachable
51 (134)

1MRS758449 EN
Filtering chains
INPUT packets coming from any interface and terminating to the device itself. This
chain is used to restrict access to devices internal services, such as the SSH server, Web
HMI, or the static key OpenVPN server.
OUTPUT packets originated from the device
FORWARD packets coming to the device from any interface, not targeted to the device
itself, but to be routed to another interface instead. This chain is usually used to control
traffic between remote devices and LAN devices
Output
Input
Forward
Fig. 9.4-1 Firewall chain directions
Interfaces
Any The rule applies to packets entering or leaving via any interface
Any VPN Applies to packet entering or leaving via any VPN tunnel
Any WAN Applies to packet entering or leaving via any WAN interface (i.e. Mobile
WAN SIM1, Mobile WAN SIM2 or Ethernet WAN)
Mobile WAN Applies to packet entering or leaving via cellular WAN interface (i.e.
Mobile WAN SIM1, Mobile WAN SIM2, note that the Lite models are having only
one Mobile WAN interface)
Ethernet WAN Applies to packet entering or leaving via Ethernet WAN interface
Ethernet LAN Applies to packet entering or leaving via Ethernet LAN interface
General Settings
The General settings page makes it easy to configure the most usually used
actions by simple Yes/No configuration.
52 (134)

1MRS758449 EN
Fig. 9.4.1-1 General settings

Use filter
Defines whether or not to use packet filtering firewall. It is recommended to
use and configure the firewall.
Use S-NAT
Use source network address translation (recommended). See chapter S-NAT
for more information.
Use D-NAT
Use destination network address translation (and port forwarding). It is not
needed to use D-NAT when theres M2M Gateway in the system. The M2M
GW is able to route the packets to Wireless Gateways/Controllers LAN
using VPN tunnel. See chapter D-NAT for details.
Track applications
Track application-specific connections like FTP. Some applications are using
separate ports for control and data streams, like active FTP. When enabled,
53 (134)

1MRS758449 EN
the firewall can track such applications. It is recommended to leave the setting
enabled.
Log unauthorized traffic
The packets that are not allowed by firewall rules are logged. It is
recommended to leave the setting as disabled to avoid flooding the system log
file. It can be used in troubleshooting for detecting accidentally dropped
packets.
Reply to ping
Defines whether the device will answer to ICMP ping messages.
Common Functions
There are additional common functions for making the firewall
configuration easier. One can also define more accurate rules in Filter section
(Filter incoming / forwarded / outgoing).
LAN-LAN accepted
When enabled, the device is allowed to route between LAN interfaces
subnets. Usually the device has only one subnet. The setting can be left as
enabled.
LAN-in accepted
It allows the LAN devices to use Wireless Gateways/Controllers services
(i.e. DHCP, DNS proxy, NTP and so on). It is usually left as enabled.
LAN-out accepted
Defines whether the LAN devices are allowed to access the internet (WAN)
through the Wireless Gateway/Controller. It can be disabled if theres no need
for directly accessing internet through the Wireless Gateway/Controller.
LAN-VPN accepted
If allowed, the LAN devices can freely access the services available via VPN
tunnel.
GUI anti-lockout
When enabled, the GUI access is always allowed from devices LAN,
regardless of other firewall settings. It is highly recommended to leave the
setting as enabled, as it prevents accidental lock-out from GUI.
54 (134)

1MRS758449 EN
Note: If using WAN interface only, enable the Allow Web HMI access from
WAN.
SSH anti-lockout
When enabled, the SSH access from LAN is always permitted.
Note: If using WAN interface only, enable the Allow SSH access from
WAN.
VPN-in accepted
Allows the devices on the M2M side of VPN tunnel to access services
running inside the Wireless Gateway/Controller.
VPN-LAN accepted
Allows the devices on the M2M side of VPN tunnel to access devices in
Wireless Gateways/Controllers LAN.
Allow access to OpenVPN server
Allows incoming connections to the OpenVPN static key server running in
Wireless Gateway/Controller. See a separate static key OpenVPN application
note for more information regarding this feature.
Allow SSH access from WAN
Allow SSH connection from WAN interfaces.
Allow Web HMI access from WAN
Allow the graphical user interface connection from WAN interfaces.
Default Actions
Incoming
Defines which action to take by default for packets targeted to the device.
Usually set as Drop. Note however that additional allowed
protocols/ports/IP addresses (if any) must be configured prior to setting the
action to drop.
Forwarded
Defines which action to take by default for routed packets. Usually set as
Drop. Note however that extra allowed protocols/ports/IP addresses (if any)
must be configured prior to setting the action to drop.
55 (134)

1MRS758449 EN
Outgoing
Defines which action to take by default for packets generated by Wireless
Gateway/Controller. Usually set as Pass. If defined as drop, note that he
allowed protocols/ports/IP addresses must be configured prior to setting the
action to drop.
IP v.6
Set the Deny all IPv6 traffic to yes for denying all IPv6 traffic from/to
Wireless Gateway's/Controller's LAN.
OpenVPN bridge filtering
When the OpenVPN Bridge Filtering is enabled, it will allow only ARP,
DHCP, ICMPv6, and STP Ethernet broadcast/multicast frames. This is used
with bridged OpenVPN setup for limiting unnecessary Ethernet traffic.
Filter incoming
Use packet-level filtering for incoming packets. It is recommended to enable
the firewall and use packet-level filtering. When used, the filter rules must be
defined for incoming, forwarded and outgoing packets.
The main principle is to categorically drop any packet and then white list all
allowed packets before the drop-rule. The firewall processes the filter rule set
rule-by-rule from top to bottom. The first rule that matches the packet causes
the defined action.
Filter forwarded
Use packet-level filtering for forwarded packets (from interface to another,
e.g. from OpenVPN TUN-interface to Ethernet LAN interface).
Filter outgoing
Use packet-level filtering for outgoing packets (out from Wireless Gateway/
Controller to any interface).
D-NAT
D-NAT (destination network address translation and port forwarding) is used
for forwarding packets from Wireless Gateways/Controllers WAN to LAN.
When theres M2M Gateway in the setup, there is usually no need for D-NAT
since the M2M GWs and Wireless Gateways/Controllers LANs are routed
via VPN tunnel.
56 (134)
1MRS758449 EN

A typical example of D-NAT would be a use case, where there is no M2M

Gateway in the system and a private GPRS access point (private APN) is
used. The access point is only routing the GPRS IP addresses (i.e. IP
addresses assigned by cellular network), not Wireless Gateways/Controllers
LAN IP addresses. Without M2M GW, the Wireless Gateways/Controllers
LAN cannot be routed over VPN tunnel, so D-NAT is needed.
The D-NAT will forward packets with destination IP as Wireless
Gateways/Controllers IP to a device in Wireless Gateways/Controllers
LAN. The port number is used for differentiating the traffic (port forwarding).
It is not recommended to enable D-NAT when there is M2M Gateway in the
setup.
Example scenario:
Remote Site, LAN 10.10.10.0/24
Central site, LAN 192.168.1.0/24
D-NAT
17
6.0
2.1
.2
Cellular APN,
172.16.0.0/24
LAN
10.10.10.0/24
10.10.10.1
APN
Viola Arctic 3G GW
172.16.0.X
Default GW
Cell operator
17
2.1
6.0
.1
19
2.1
68
1
.1 .
LAN
192.168.1.0/24
APN Router
Device_1
10.10.10.2
Default GW
PC_1
192.168.1.2
Fig. 9.4.9-1 D-NAT scenario

The example scenario assumes that there is a device at the remote site, e.g. a
PC, RTU, PLC or similar, which is TCP/IP capable and needs to be accessed
from central site.
The device has LAN IP, netmask and default gateway settings. If the device is
a PC, it is assumed that its firewall is passing the ICMP ping, which is used in
this example (note that typical PC firewall or security suite settings prevent a
PC for answering ping messages).
IP addresses used in this example:
Wireless Gateway LAN subnet 10.10.10.0/24
o Wireless Gateway LAN IP: 10.10.10.1
o A device (Device_1) in Wireless Gateways LAN: 10.10.10.2
Main site's LAN subnet: 192.168.1.0/24
57 (134)
1MRS758449 EN

o Cellular APN router's LAN IP: 192.168.1.1

o A PC (PC_1) in main site: 192.168.1.2
Private APN cellular IP subnet: 172.16.0.0/24
o Cellular APN router's WAN IP: 172.16.0.1
o Wireless Gateway mobile WAN IP: 172.16.0.2
In this example, it is described how to define the D-NAT and port forwarding
so that the remote device can be accessed, despite the fact that the private
APN network is not routing the Wireless Gateways LAN subnet IP
addresses.
In the ping packet flow diagram below, there is a ping request made (by
PC_1) against the Wireless Gateways cellular assigned WAN IP address.
However, the Wireless Gateway is configured so that it will not answer the
ping request by itself, but forwards the ping packets to the Device_1 (a PC in
this example), which is located in Wireless Gateways LAN subnet. In the
same manner, the Wireless Gateway will forward ping reply packets back to
the originator.
In addition, an HTTPS request is made from main sites PC to Wireless
Gateway itself, this is included for demonstrating that the access to Wireless
Gateways internal services (here the Web HMI, but also access to Serial
Gateways, SSH server, etc. can be configured) is possible despite the D-NAT
configuration.
Packet flow diagram:
Device_1
Arctic
(If a PC, the firewall must allow
Cellular APN
172.16.0.0/24
APN Router
ICMP ping)
D-NAT
Routing
10.10.10.2
Ping
10.10.10.1
172.16.0.2
10.10.10.2
Ping reply
10.10.10.1
172.16.0.2
Ping
Ping reply
PC_1
Default
GW
172.16.0.1
192.168.0.1
Ping
172.16.0.1
192.168.0.1
Ping reply
192.168.0.2
192.168.0.2
Routing
S-NAT
Commands:
Default
GW
Routing
Web UI 172.16.0.2:443
HTTPS request
HTTPS reply
172.16.0.1
172.16.0.1
192.168.0.1
192.168.0.1
HTTPS request
HTTPS reply
1) ping 172.16.0.2
2) HTTP(S) GET
172.16.0.2:443
Routing
Fig. 9.4.9-2 D-NAT packet flow

To conclude the example scenario:
With this setup, when pinging to wireless Gateway's WAN IP 172.16.0.2, youre
actually pinging the Device_1 (10.10.10.2) in Wireless Gateway's LAN.
58 (134)

1MRS758449 EN
Private access point doesnt route IP addresses form other private subnets than
what it will assign to the mobile clients. One cannot access the Wireless
Gateway's LAN devices IP address (10.10.10.2) directly from PC_1.
It is also possible that the operator has assigned routing to the same IP address
space to its own internal use, so there may be a server answering to ping messages
sent to 10.10.10.2; however that it is not the Device_1, but some other server in
operators backbone (therefore, use only SIM IP addresses when connecting).
If a public access point, assigning public IP addresses, is used with DynDNS
service, the same rule applies; you cannot access the devices in Wireless
Gateway's LAN directly, but via Wireless Gateway's IP using D-NAT. If
hostnames are used in Wireless Gateway's D-NAT configuration, the Wireless
Gateway must be configured to use DNS for resolving the names to IP addresses.
When troubleshooting (e.g. do the ping messages really flow to the destination
Device_1), you can make protocol traces from the end device if possible, but also
from Wireless Gateway/Controller; in command line as root user, you can use the
command:
tcpdump -i lan0 icmp (do you see outgoing requests and incoming replies
from the LAN device?), pressing <ctrl-c> will stop the trace.
Example configuration for forwarding ping messages.
Fig. 9.4.9-3 Example rule for ping

Example configuration for forwarding a TCP port (with source address
matching).
59 (134)

1MRS758449 EN
Fig. 9.4.9-4 Example rule for TCP

Example configuration for accessing Wireless Gateway's/Controller's Web
HMI, when all other traffic is forwarded (This rule must be set on top of the
list if the next rule is forward all traffic to a LAN device).
Wireless Gateway's own LAN IP address

Fig. 9.4.9-5 Example rule for Web HMI
Example configuration for forwarding all traffic to a LAN device.
60 (134)

1MRS758449 EN
Fig. 9.4.9-6 Example rule for forwarding all traffic
Common problems
All traffic is forwarded to a device in Wireless Gateway's LAN. When defining
rules for forwarding all traffic to a device in Wireless Gateway's LAN (regardless
of the protocol or destination port), it is recommended first to define rule(s) for
accessing Wireless Gateway's own services, like Web HMI. Otherwise all traffic
is indeed forwarded to the LAN device and the Wireless Gateway wouldnt be
accessible through the WAN at all.
Source address is defined in the rule, but the traffic is originated from some other
source address. It is recommended to test the rule first without source IP matching,
then test the functionality and after verification, add the source IP matching, and
then re-test.
Source port is defined in the D-NAT rule. Usually, it is not known what is the
source port; hence leave the source port empty in D-NAT rule, unless youre
absolutely sure that the same defined source port is always used.
Destination IP address is defined as new destination address. The destination
address means the packets original destination address (172.16.0.2 in this
example). The original destination address must be the Wireless Gateway's WAN
IP address.
The Wireless Gateway's LAN devices IP address is tried to be accessed directly.
This is not possible. You must define the destination IP address in originating PC
as Wireless Gateway's WAN IP address (e.g. in PC_1, type ping 172.16.0.2).
61 (134)

1MRS758449 EN
S-NAT
A typical use case for S-NAT would be that computers in Wireless
Gateway/Controller LAN need to access Internet via cellular connection (i.e.
using the Wireless Gateway/Controller as 3G/LTE modem). As the computers
have private IP addresses from Wireless Gateway's/Controller's LAN (e.g.
from 10.10.10.0/24 network), it is not possible for them to access the internet
(the internet doesnt route private IP addresses).
With S-NAT, the Wireless Gateway/Controller will change the source IP
address of the computer that needs to access the Internet via cellular network
to Wireless Gateway's/Controller's own IP address (acquired from cellular
network, this is called masquerading). Respectively, while the packets are
coming back to intranet computer, Wireless Gateway/Controller knows to
forward the packets to the correct host in Wireless Gateway's/Controller's
LAN.
S-NAT masquerade rule is enabled by default and it is recommended to be
left unchanged.
Services
The services are running in Wireless Gateway/Controller itself. Services can be offered to
other devices and usually limited by firewall.
Common
Use DNS proxy
To simplify, the DNS is a naming system that resolves the human memorable
names to IP addresses.
When the Wireless Gateway/Controller has DNS servers IP address set either
automatically or manually, it can work as DNS proxy for the LAN devices.
The Wireless Gateway/Controller is defined as DNS server for LAN devices
(either manually or through DHCP) and the Wireless Gateway/Controller will
forward the name queries to the actual DNS server and back to the LAN
devices.
If the Wireless Gateway/Controller is used as a DHCP server for LAN clients,
remember to add the DHCP servers IP address to Wireless
Gateways/Controllers DHCP server configuration and set the value as
Wireless Gateway's/Controller's LAN IP if its DNS proxy is used.
62 (134)

1MRS758449 EN
This M2M solution doesnt require name resolution; IP addresses are usually
used throughout the configuration. However, if there is a need for e.g.
browsing the internet through Wireless Gateway/Controller, the DNS is likely
required.
LLMNR responder
The link-local multicast name resolution is a protocol, which enables
Windows machines on LAN to find Wireless Gateway/Controller using its
hostname. This is currently supported in Windows Vista, Windows
Server 2008, Windows 7, 8.x and 10.
mDNS responder
The multicast domain name system is a protocol, which enables Mac OS
X machines on LAN to find Wireless Gateway/Controller using its
hostname.
SSH server
The SSH (secure shell) is an encrypted network protocol for e.g. safe
command line connections. It is widely replacing unencrypted Telnet
protocol.
The Wireless Gateway/Controller has internal SSH server, which allows
incoming SSH connections, if enabled. By default the SSH service is
disabled. There are two options for allowing SSH connections; from all
interfaces or from LAN interface only.
For security reasons, it is recommended to enable the SSH only from LAN
network. Note that remote access to Wireless Gateways/Controllers LAN is
usually possible via VPN tunnel from M2M Gateway side (from the main
site). Also, for security reasons enable only SSH2 connections (only SSH2
tick box ticked). If login authorization is needed, you can define clients SSH
public keys to the text box.
When connecting Wireless Gateways/Controllers command line via SSH, an
SSH client is needed in some operating systems. PuTTY is a free SSH client
and is recommended, because apart from being SSH client, it can also be used
as serial terminal emulator. The login to Wireless Gateway/Controller is done
as adm user and certain actions, like pinging can be done as that user. More
advanced commands usually require root user privileges and the change to
63 (134)

1MRS758449 EN
root user can be done with the following command (without quotes,
remember the dash mark): su -.
DHCP server
The Wireless Gateway/Controller has an embedded DHCP server. It can offer
IP addresses, netmasks and other optional parameters to DHCP clients. You
may refer to RFC2131 for more details on DHCP.
Enabled
When enabled, the Wireless Gateway/Controller will work as DHCP server
for the LAN devices.
Subnet
The subnet, where the Wireless Gateway/Controller listens to DHCP requests
from clients. Usually the whole devices LAN address space (whole subnets
IP address) is defined here. In some configurations, the DHCP enabled subnet
may be smaller than Wireless Gateways/Controllers whole LAN subnet,
because certain address space is reserved for LAN devices with fixed IP
addresses.
Subnet mask
Usually the Wireless Gateway/Controllers LANs whole subnet mask is
defined here.
Range low IP address
This is the lowest IP address given to a client. For example, if Wireless
Gateways/Controllers LAN is 10.10.10.0/255.255.255.0, the usable IP
address space is 10.10.10.110.10.10.254, the Wireless Gateway/Controller
may be 10.10.10.1, and then some space may be reserved for fixed IP clients.
The Range low IP address in this example could be e.g. 10.10.10.100, which
would leave the range 10.10.10.210.10.10.99 to fixed IP clients.
Range high IP address
This parameter respectively defines the highest IP address given to a DHCP
client. In this example, it would be 10.10.10.254 (the last IP address of this
subnet, the 10.10.10.255, is used as IP broadcast address and thus cant be
used as device IP address).
Domain name
64 (134)

1MRS758449 EN
The domain name given to clients is entered here. Usually domain name is not
needed in this M2M solution.
DNS servers
A comma separated list of DNS servers. This may also be Wireless
Gateway's/Controller's IP address if it works as DNS forwarder.
Gateway IP address
The IP address of the default gateway. Usually it is defined as Wireless
Gateway's/Controller's LAN IP address. When this parameter is passed on to
the DHCP client, it tells the client (in Wireless Gateway's/Controller's LAN)
to use Wireless Gateway/Controller as default gateway (i.e. IP packets having
destination address other than Wireless Gateway's/Controller's LAN subnet
are sent to Gateway/Controller for further routing).
Broadcast IP address
Usually, this parameter is set as the last IP address of the subnet.
Default lease time
Define a time for clients that dont request a specific lease time.
Maximum lease time
Define the maximum time for DHCP client leases.
NTP Servers
If Network Time Protocol is used (i.e. there is an NTP server in the network),
enter here the list of NTP servers separated by comma. This may also be
Gateways/Controllers IP address if it works as NTP server.
Usually the following parameters are required to be defined in DHCP server
settings.
Enabled
Subnet
Subnet mask
Range low IP address
Range high IP address
Gateway IP address
Broadcast IP address
65 (134)

1MRS758449 EN
DNS Servers
DynDNS client
There is an Internet name service company Dyn, who is offering name service
for dynamically changing public IP addresses for a monthly fee (it used to be
a free service).
If there is no M2M Gateway in the system, this service may be used for
bypassing the problem of constantly changing public IP address of Wireless
Gateway/Controller. Other options are to use the M2M Gateway or to use a
private APN.
The list of other service providers can be seen from the drop-down menu of
DynDNS service provider. Currently supported dynamic DNS services:
Dyndns.org
No-ip.com
Freedns.afraid.org
Zoneedit.com
Easydns.com
3322.org
Sitelutions.com
SNMP agent
A subset of SNMP v2, (simple network management protocol) is supported.
The SNMP GET and SET for MIB-II tree (RFC 1213) are partially
supported. Note that the vendor specific MIBs are not supported. Refer to
RFC 1157 for more details on SNMP.
Read only SNMP community
The name of the read-only community, default public.
Read and write SNMP community
The name of read and write community, default private.
Server port
The UDP port, where the Wireless Gateway's/Controller's SNMP agent listens
to, usually 161.
66 (134)

1MRS758449 EN
SNMP IO (certain Wireless I/O Gateway models)

In firmware version 3.2.5, a new SNMP functionality is introduced for certain
Wireless I/O Gateway models. There is a possibility to send SNMP traps
based on IO state changes and toggle IO states with SNMP GET/SET
commands. The MIB files are found in the following directory of Wireless
I/O Gateway: /opt/viola/mibs/.
General
Enable SNMP Traps: (Yes/No)
Trap Managers: IP address
Trap Community: max. 30 characters, valid characters are a-z, A-Z, 0-9 and +_.,():*@!/
Digital IO x
Name = max. 20 characters, valid characters are a-z, A-Z, 0-9 and +_.,():*@!/
Rising Edge = Yes/No
Rising Edge Event Name = max. 30 characters, valid characters are a-z, A-Z,
0-9 and -+_.,():*@!/
Falling Edge = Yes/No
Falling Edge Event Name = max. 30 characters, valid characters are a-z, A-Z,
0-9 and -+_.,():*@!/
Arctic Patrol
The Arctic Patrol is a tool in M2M Gateway for detecting and displaying the
state of the Wireless Gateways/Controllers in the field. The Wireless
Gateways/Controllers are respectively having Arctic Patrol clients that are
reporting periodically their statuses to M2M Gateway (the M2M Gateway
versions that are supporting Arctic Patrol are having Patrol icon in the main
page of Web HMI).
Fig. 9.5.6-1 Patrol configuration

Server
67 (134)

1MRS758449 EN
M2M Gateways IP address.

Connection interval
How often to report to server (in seconds), default value is 1500 seconds (25
minutes).
Backup active configuration to server
Transfers the active configuration to M2M gateway each time the Patrol
detects it has been changed. The Wireless Gateway's/Controller's password is
required for displaying the configuration in M2M Gateway.
Registration password
The registering password needs to be copied from the M2M Gateway (Patrol
Configuration Device registration password) to Wireless
Gateway/Controller. The initial registration may take some time if the
Wireless Gateway/Controller has been switched on a long time. The
registration password is used only one time in the registration phase. The
M2M Gateway will assign a strong permanent Patrol password to the
Wireless Gateway/Controller automatically after initial registration.
Serial ports and I/O
There are different models of equipment what comes to supported serial protocols and
number of internal I/O.
General configuration
In this page, the role of serial ports is selected. In addition, it is selected
whether to hide the unused serial port roles from the main menu or not.
Possible serial port roles (the availability is depending on the device model)
Serial Gateway - wrapping serial data to TCP/IP frame
SMS modem - sending SMS messages with serial port AT commands
IEC-104 Gateway - Adapting IEC-60870-5-101 slave to IEC-104 master
Modbus Gateway - Adapting Modbus RTU serial slave to Modbus TCP master
DCU For reading some meters data (requires customization, not commonly
used)
Serial Gateway (RS1, RS2)
The serial connector configurations are as follows:
68 (134)

1MRS758449 EN
Dual SIM products:

o RS1 port (configurable modes: RS232, RS422 or RS485)
o RS2 port (always RS232)
o Separate serial RJ45 console port (RS232, 115200-N-8-1)
Single SIM products:
o RS1 port (always RS232)
o RS2 port (configurable modes: RS232, RS422 or RS485)
o RS1 port works as console port (115200-N-8-1) when console switch is set
to console position.
The Serial Gateway application inside Arctic wraps the serial data into
TCP/IP frame and provides the data for reading in Arctics TCP or UDP port
(listens on any IP address the Arctic is having), this is called server mode, or
sends the serial data to a server in certain IP address and certain TCP port
(this is called client mode). The server mode is commonly used.
Fig. 9.6.2 Serial Gateway configuration

Network protocol
TCP or UDP can be selected. Usually TCP is used.
Mode
Server = Provides serial data wrapped inside TCP/IP frame in a selected TCP
port of Arctic. This mode is usually used. When the server mode is selected,
the local port needs to be defined and must not overlap any other application
69 (134)

1MRS758449 EN
port in the device. The remote server host/port setting has no effect in the
server mode.
Client = Sends the serial data to a server to certain TCP port. The data is sent
to a server defined by Remote server host and port parameters. The local port
parameter has no effect in client mode.
New connection priority
When the "new connection priority" is enabled a new incoming connection
will override the present/old connection. Usually this is the preferred method.
Connection slot
Defines how long time the old connection must be connected before accepting
new one (used only in server mode with new connection priority enabled).
The default value is 0 seconds. Usually the default value can be used.
Local port
Defines in server mode, which port to listen to. Verify that the port number is
unique (e.g. check that another serial Gateway is using a different port).
Remote server
Defines the remote servers IP address and port for connecting (only in client
mode).
Idle timeout
The device will close connection when it has been idle over defined amount
of time, empty=infinite. The empty value can usually be used as there is likely
a retry-mechanism in the originating end.
Serial settings
These values must be set according to the serial device, which is connected to
Wireless Gateway/Controller. Speed, 300460800 bps, data bits, 58,
parity, even, odd or none, number of stop bits, 1 or 2.
Serial handshaking
The flow control in RS-232 can be hardware controlled with RTS/CTS pins,
software controlled with certain XON/XOFF characters or none (no flow
control).
70 (134)

1MRS758449 EN
Set the value according to the serial device connected to Arctic and note that
if the hardware handshaking is used, the serial cable must have the respective
pins connected. Select None if RS-422 or RS-485 is used.
Flush old data
Empty serial data buffers when new connection arrives. Usually enabled.
Serial Frame Spacing
The time of a pause in serial traffic, after which the already received data is
sent. Usually the default value 100 milliseconds can be used.
Serial Frame Size
The maximum amount of bytes received from serial device, after which the
packet is sent. Usually can be left empty for default value.
Network Frame Spacing
The time of a pause in IP traffic, after which the already received data is sent.
Usually can be left empty for default value.
Network Frame Size
The maximum amount of bytes received from the IP device, after which the
packet is sent. Usually can be left empty for default value.
SMS modem (RS1, RS2)
There is an AT-command emulator for sending SMS messages via serial port.
An external entity can use Arctic for sending text mode SMS messages by
connecting to Arctic via serial port. The same serial port cannot be used by
other applications (such as Serial Gateway).
Enable
When enabled, the serial port is used as AT-command emulator for sending
SMS.
SMS Modem logging
Log AT commands to syslog.
Serial Settings
Speed, data bits, parity and stop bit.
71 (134)

1MRS758449 EN
Serial Handshaking
Handshaking mode (None, hardware by RTS/CTS signals, software by
XON/XOFF characters).
The following AT commands are supported
ÀT`: replied with ÒK`
ÀTE0`: replied with ÒK`. Turn echo off
ÀTE1`: replied with ÒK`. Turn echo on
ÀT+CPIN?`: replied with `+CPIN: READY` (i.e. no PIN code needed)
ÀT+CMGF?`: replied with `+CMGF:` `0` or `1` depending which format is in
use; PDU or TEXT. (Note: Only text mode allowed, returns always `1`)
ÀT+CMGF=?`: replied with `+CMGF: (1)`
ÀT+CMGF=<format>`: `<format>` only `1` is accepted. Setting `0` will reply
ÈRROR`
ÀT+CSCS=?`: replied with `+CSCS: ("IRA")`, "IRA" is default charset in
the Arctic (See ITU recommendation T.50).
ÀT+CSCS?`: replied with `+CSCS: "IRA"`, "IRA" is default charset in the
device.
ÀT+CSCS="IRA"`: allow to change charset to "IRA"
ÀT+CMGS="[tel.no]"`: replied with a `>` prompt. After this, the message is read
until Control-Z (0x1A) is received. Can be break with ESC.
Unknown AT commands are replied to with "ERROR" for compatibility.
Note: Enabling this functionality makes the sending of SMS messages via
Arctics serial port possible without logging in to Arctic. This must be noted
from security point of view.
IEC-104 Gateway, Modbus Gateway
Certain models have special serial protocol conversions (i.e. Modbus
RTU/ASCII to Modbus TCP or Modbus RTU over TCP and IEC-101 to IEC104). Refer to their user manuals for more information.
DCU
Some models have DCU application, which is able to poll certain electric
meters. This feature requires customization and is not commonly used.
Tools
72 (134)

1MRS758449 EN
The Tools section has a selection of supportive tools for system administration and
troubleshooting.
System log
The system log is a good troubleshooting tool and is usually requested by
technical support in a support case. It shows the boot time actions, cellular
network attachment, VPN tunnel establishment and other important
information.
The default view shows recent events, click View all log to see the complete
system log. You can download the full log to your PC as a text file by clicking
the Download all log button.
The device can also send its syslog to a remote syslog server. Note however,
that this may generate a lot of traffic over Mobile WAN.
Support log
The support log takes a snapshot of the devices configuration so that it can be
sent to the technical support. The Supportlog will collect device information
for further problem solving. The following are collected: system log, devices
configuration, setup files, performance data and so on.
Modem info
This option displays internal cellular modem related information.
Wireless WAN
Enabled or disabled, up or down.
Last information update
When the modem information has been updated last time. You may force the
modem information update by clicking the Refresh button at the Modem Info
page.
Manufacturer, Type
The manufacturer and model of the internal cellular modem module.
Firmware
Shows the firmware version of the cellular modem module.
IMEI
73 (134)

1MRS758449 EN
The IMEI code of internal cellular modem. IMEI stands for International
Mobile Station Equipment Identity. It is a unique identifier for GSM, 3G and
LTE devices. In this device, it is the identity code of the internal modem. In
some countries, the IMEI code needs to be sent to the mobile network
operator for allowing the use of the device in operators network.
Supported services
The network services that the internal modem is supporting. Possible values
are: GSM, GPRS, EDGE, UMTS, HSDPA/HSUPA and LTE (depending on
the model). All supported services are not necessarily available in serving
cellular network.
PIN tries used
Indicates how many times the PIN code has been entered erroneously. The
SIM card allows two false codes and locks on third. If the SIM requires PIN
code and you have misconfigured the code in the device, put the SIM card to
a cellular phone, enter correct PIN number, correct the PIN code setting in the
Wireless Gateway/Controller and re-enter the SIM card to the device.
SIM status
Tells whether the PIN number is required by SIM card, or not.
SIM IMSI
Displays SIM cards IMSI (International Mobile Subscriber Identity) code.
With this code, the SIM card of the device can be identified by the cellular
operator.
Temperature
Displays the temperature of the internal cellular modem. The temperature may
be higher than the ambient temperature, especially if there are large amounts
of data transferred over the cellular interface.
Signal level
Displays the signal strength in dBm (decibels referenced to one milliwatt).
The typical range is -70 to -90 dBm. The -90-100 dBm is quite a poor
connection and negative numbers over -100 dBm indicate non-working
connection. If needed, consider external omnidirectional antenna with FME
female plug (SMA male in Lite models) and recommended antenna gain
39 dBi.
74 (134)

1MRS758449 EN
Registration status
Displays the devices registration to the cellular network. Usually should
show registered to home network.
Available services, Current service
The Available services are displaying services available via cellular
operator in a certain place. Possible values are: GSM, GPRS, EDGE, UMTS,
HSDPA/HSUPA, HSPA+ and LTE (depending on the model). The Current
service displays the currently used service.
Current operator
Displays the currently used cellular operator, preceded by operator code, if
available.
Location area code, Cell ID
Displays the location area code and the cell identification code of the
operator, if available.
APN
The cellular access point name used for establishing the cellular data
connection.
Network test
Network test will test the configured connections for troubleshooting
purposes. The following tests will be done:
Check whether the following features are enabled: Mobile WAN, Mobile WAN
pinger, Monitor, Ethernet WAN, DNS, VPN, Patrol (note that the ping may be
disabled in some firewall configurations)
If respective item is enabled, try pinging it (ping Mobile WAN monitor IP,
Ethernet WAN IP, Monitor IP, VPN peer IP and Patrol IP)
If DNS enabled, try resolving certain hostnames to see that the name resolution is
working.
Monitor graphs
When the Monitor is configured to ping a certain ping target, it will produce
data of the round-trip times for each ping message sent and reply received.
This data is shown in graphical form. The graph can be used to get historical
75 (134)

1MRS758449 EN
snapshot of the delays in round trip times, which along with packet loss data
will reveal the quality of the cellular connection.
Fig. 9.7.5-1 Monitor graphs screen

User config
The standard administrative user is called viola-adm (or arctic-adm) and the
username is changeable. Direct root user login is only allowed at serial
console. One can login via SSH as viola-adm (or arctic-adm) user and become
root user by command: su - (remember the dash).
Fig. 9.7.6, User configuration screen

Username
It is recommended to leave the username as default viola-adm (or arctic-adm).
76 (134)

1MRS758449 EN
Old/New/(confirm) Password
Enter the previous password and the new password for changing the violaadm (or arctic-adm) users password. Enter the same new password again for
comparison.
Old/New/(confirm) Console access password
Enter the previous console access password and new password changing the
root users password. Enter the same new console password again for
comparison.
Restricted shell
The restricted SSH shell enables creating a safe sand-box for e.g. 3rd party
operations and management personnel. When enabled, the restricted shell user
can perform actions that are defined below. The commands that are not
selected cant be performed by the restricted shell user.
Fig. 9.7.7-1 Restricted shell

The quota defines how much space the user can allocate from ramdisk (so
that the user cannot fill up the filesystem). Usually the default value is
sufficient. The number of simultaneous logins defines how many concurrent
login sessions the user may have (the default value 5 is usually enough).
Reboot
The device can be rebooted from reboot menu by clicking the Reboot button.
There will be a confirmation dialog after clicking the button.
77 (134)

1MRS758449 EN
Release notes
This menu item shows brief release notes for the firmware versions.
Configuration profiles
The Wireless Gateways/Controllers are storing the devices entire
configuration in one XML file. It is possible to edit and clone configuration
files. However, there are certain unique identifiers that will need to be
changed after cloning, for example:
Hostname
Administrators password
Console users password
Ethernet IP address/netmask
SIM PIN code, (if used and unique)
VPN username in L2TP-VPN (if used)
VPN login password in L2TP-VPN (if used)
SSH key in SSH-VPN
Certificates for OpenVPN (if used)
Fig. 9.7.10-1 Configuration profiles

The currently running configuration is indicated by radio button. In addition
to running configuration (device configuration), there are usually last boot
and factory default settings configurations available.
Default settings
It is possible to restore factory configuration profile by clicking default
settings and selecting the configuration profile, which will be overwritten by
factory configuration profile. There will be a confirmation dialog after
clicking the Submit button.
78 (134)

1MRS758449 EN
In dual SIM models, it is also possible to restore the factory settings by

pushing the reset button approx. 15 seconds, until all status LED lights will be
lit. Note that this method doesnt preserve any previously stored profile.
Firmware update
The firmware can be updated via Web HMI or via command line. See the
separate Technical Note for details on the update. In the update process, the
firmware file is first uploaded to the device. After that and if the
preconditions are met (e.g. HW and firmware checks passed), the actual
update is done.
79 (134)

1MRS758449 EN
10 Configuring OpenVPN with Easy mode

M2M Gateways have two configuration modes for certificate based OpenVPN:
1. OpenVPN Easy mode (with certificate-based authorization)
In this mode, the configuration is done with the wizard, which guides the configuration
process. Several actions that were previously done manually are now automated. The
M2M GW will create pre-configured IP addressing on your behalf. The addressing can be
manually edited later on (in the Advanced mode), if needed.
2. OpenVPN Advanced mode (with certificate-based authorization)
In advanced mode, all actions are done manually. This is the only option in older M2M
Gateways.
The following chapters are describing the setup with these two configuration modes. The
Easy mode is recommended for new users. You will need to do either Easy mode or
Advanced mode configuration, not both.
Configuring OpenVPN in M2M Gateway, Easy mode
Once logged in, click the OpenVPN icon.
Fig. 10.1-1 OpenVPN icon

Click OpenVPN Easy mode with certificate-based authorization.
Fig. 10.1-2 OpenVPN with certificate based authentication icon

Selecting the type of VPN
There are two options, Normal and Bridge. The differences are as follows:
Normal, Layer 3, IP mode
o The solution is based on routing. There are different, unique subnets for
each Wireless Gateway/Controller and also the M2M GWs LAN is
unique. The M2M Gateway acts as a router between Wireless
Gateways'/Controllers' LANs and its own LAN
o The traffic is routed by IP addresses (layer 3 in OSI model)
o This is the most common and recommended setup
Bridge, Layer 2 Ethernet mode
80 (134)

1MRS758449 EN
o The M2M GW is creating Ethernet (layer 2 in OSI model) bridges

between the Wireless Gateways/Controllers
o The M2M GWs LAN Ethernet interface can be configured to be a part of
the bridge
o All Ethernet packets are transferred between the nodes (including Ethernet
broadcast and multicast packets) which may cause high traffic in VPN
tunnels and thus high billing
o This setup is recommended only in few special cases and is not described
in the scope of this document
Select the Normal (Layer 3, IP) OpenVPN.
Fig. 10.1.1-1 Normal (routing) OpenVPN

Creating an OpenVPN server instance
Give a name to the server; you can name it as testserver and click Create server.
Fig. 10.1.2-1 Creating OpenVPN server

Once youll click the server creation button, the certificate generation is taking place,
wait until the next screen appears.
Adding clients to the server
You will need to define the number of clients, client prefix and remote IP and decide
whether the Arctics LANs should be accessible of not. See the descriptions for these
terms below.
81 (134)

1MRS758449 EN
Fig. 10.1.3-1 Adding OpenVPN clients

Number of clients
How many clients are you adding in this session (you can add more clients later). In
this example, were only adding one Arctic. If you have more Arctics, you can enter
the respective number here.
Client name prefix
Some prefix can be automatically added to client names. You can separate different
groups of Arctics with different prefixes. The M2M GW will automatically add a
running number to the prefix, so if the prefix is e.g. testclient, the actual OpenVPN
peer name for the first Arctic will be testclient1, the second testclient2 and so on.
Note: The Arctics hostname (in Arctic) should match the OpenVPN client name in
M2M GW if the Patrol is used.
Remote IP
Define the IP address of M2M GWs WAN interface; this is the IP address the Arctic
is going to use, when connecting to M2M Gateway. If the M2M GW is in the DMZ,
use the public border router IP (the router must then have a D-NAT and port
forwarding configuration to M2M GWs DMZ IP address). See different network
scenarios in VA-09-1-4 Configuration guide.
Add Arctic LAN (iroute) to clients
The term iroute refers to OpenVPN terminology and it is used for telling the
OpenVPN server (in M2M GW) that the clients (Arctics) have their own LANs that
need to be accessed (routed by OpenVPN). This parameter is enabled when the
Arctic has TCP/IP connected device(s) in its LAN. It is recommended to enable this
option.
82 (134)

1MRS758449 EN
It is recommended to plan the solution so that each Arctic will have own unique LAN
subnet even though currently there would be only serial connected devices connected
to Arctics. Such configuration would be future proof without any changes to the
configuration if TCP/IP devices were added to the Arctics later on.
You can still change the name(s) of client(s) in the next step, if needed, see the
picture below.
Click the Create clients button.
Fig. 10.1.3-2 Creating OpenVPN clients

The screen shows the server status and created clients. The Tunnel IP refers to the
OpenVPN assigned virtual IP of the client (Arctics OpenVPN tunnel endpoint IP
address) and the Arctic LAN parameter shows the LAN subnet assigned to each
Arctic.
Fig. 10.1.3-3 Downloading OpenVPN client

The client is now created. You will need to export the client configuration to the
Arctic, see the next chapter.
Finalizing the routing settings
The Arctic needs to be aware of the main sites LAN subnet, from where the SCADA
or other possible control/monitor software sends commands to remote devices in
Arctics LAN. This can be done either by defining the VPN tunnel as default
83 (134)

1MRS758449 EN
gateway in Arctics OpenVPN settings or by configuring the M2M GW sending a

push route to the Arctic when the tunnel is up.
It is a matter of preference on how to set the routing; defining the VPN tunnel as a
default route in Arctic is the easiest option.
1) Using Push route: If the M2M GW servers firmware is 3.5.1 or newer (see the
firmware version from the upper right corner of the M2M GWs Web HMI. If not
visible, the version is 2.4), you can define up to three push routes in the OpenVPN
client configuration. Older firmwares are only allowing one push route. In this case,
use the default route option in Arctics configuration.
Click the clients name in M2M GWs Easy mode OpenVPN configuration. The
clients details are shown. Add a push route by entering the SCADA/etc. LANs
subnet IP address and netmask to the push route 2 row and click Save button.
Repeat this for other clients (that need to access the M2M GW sides LAN) as well.
2) Using Default route routing option in Arctics OpenVPN configuration: See chapter
Finalizing the routing settings in Wireless Gateway/Controller for details.
Exporting the client configuration to Arctic
If you have the device configured as according to the instructions in chapter
Configuring the Wireless Gateway/Controller, it is probably having IP address
10.10.10.10 with netmask 255.255.255.0. However, the M2M GW has automatically
configured the subnet 10.32.1.0 for Arctic and adjusted the routing respectively.
Note: For simplicity, it is now recommended to change the Arctics Ethernet LAN IP
to 10.32.1.1, keep the netmask as 255.255.255.0. Remember to change your PCs IP
address to the same subnet as well, e.g. to IP 10.32.1.2/255.255.255.0.
First, download the client configuration file to your PC by clicking the icon with the
download arrow (see figure 10.1.3-2 above). This is repeated for each Wireless
Gateway/Controller. Alternatively, you can click similar icon in the left side of the
window for downloading all clients configurations to your PC.
The client configuration file name in this example is testclient1.zip. Note that you
wont need to unzip the file manually, just store it to your PC to a place it is easily
found later on.
Next, open the Arctics Web HMI, click the OpenVPN menu item in the left menu
bar and click the Easy OpenVPN setup button.
84 (134)

1MRS758449 EN
Fig. 10.1.4-1 Easy OpenVPN setup
Fig. 10.1.4-2 Easy OpenVPN upload

Select the file from a place in your PC where you have saved if from M2M GW and
press Upload button. The Arctic will show you the client configuration information
details. Accept the configuration by clicking the Accept button and wait some time
until the Arctic will show the configuration steps it has made. Reboot the Arctic after
changes.
If you have configured the Arctic according to this document, the OpenVPN tunnel
should start soon after the Arctic has been rebooted. You may check the existence of
the VPN tunnel at Status screen of the Arctic.
Fig. 10.1.4-3 OpenVPN interface
Finalizing the routing settings in Wireless Gateway/Controller

The Wireless Gateway/Controller needs to be aware where to send packets destined
to servers in M2M GWs side (a SCADA/etc. server may be in the M2M GWs LAN
subnet or in some other dedicated LAN in M2M GWs side and the Wireless
Gateway/Controller needs a route to this LAN in order to send the response packets
back via proper interface, i.e. via VPN tunnel). If this is solely done by defining
push routes in M2M GW, the Wireless Gateway/Controller doesnt need additional
routing settings.
85 (134)

1MRS758449 EN
However, with older M2M GWs, there is only possible to define one push route and
it may not be enough for arranging routing between both from Wireless
Gateway/Controller to another and also from Wireless Gateway/Controller to M2M
GWs LAN.
Therefore, it is recommended to define the VPN tunnel as a default route, so that the
Wireless Gateway/Controller will send all packets via OpenVPN tunnel to M2M GW
for further routing.
This is done by clicking OpenVPN in the left menu column of Arctic and editing the
current OpenVPN configuration (by clicking the pen and paper icon). Change the
Routing drop down menu item to Default Route and click Submit button.
Fig. 10.1.5-1 OpenVPN default route

Configuring the PC Easy OpenVPN client for remote administration
Sometimes there is a need for connecting to M2M Gateway or Arctics and other field
devices (e.g. Remote Terminal Units) through the field engineers laptop. The safest
way to do it is to use the OpenVPN tunnel between the M2M Gateway and the
laptop.
Fig. 10.2-1 OpenVPN field laptop connection diagram

The configuration work is divided into the following sub steps (see next chapters).
Creating the PC client certificate in M2M Gateway
Exporting the certificate from M2M Gateway to a PC
Installing the OpenVPN software to the PC
Configuring the OpenVPN client in the PC
86 (134)

1MRS758449 EN
Adding an OpenVPN client to M2M GW

1. Click OpenVPN Configuration OpenVPN Easy mode with certificate-based
authorization Add clients.
2. Youre creating one test client for a PC, so set the number of clients as 1.
3. Change the prefix to e.g. clientpc. Set the remote IP as the IP for accessing the M2M
Gateway from internet (i.e. M2M GWs public IP or border routers public IP if M2M
GW is in DMZ).
4. You dont need to route the PCs LAN network, therefore, take the tick off from Add
Arctic LAN (iroute) to clients tick box, then click the Next button.
5. The M2M GW adds a running number to your client, so the client name would be
clientpc1.
6. Click the Create clients button. You should now have at least two configured clients,
similar to the picture below.
Fig. 10.2.1-1 Client list
Exporting the Easy OpenVPN client to a PC

1.
Export the OpenVPN client configuration to your PC by clicking the download
arrow (see the picture below).
Fig. 10.2.2-1 Download client configuration

2.
Select a directory in the PC where to store the client configuration file (either
directly to the computer, which is used in remote administration or you may first
export the file and later transfer it to the remote administration PC. Perform step 3
and beyond only after the file is transferred to the PC used in remote
administration).
87 (134)

1MRS758449 EN
Fig. 10.2.2-2 Saving client configuration

3.
Go to the directory where the file is and unzip the file (click the file with right
mouse button and select Extract all, Extract here or similar, depending on the
extract program).
Installing the OpenVPN software to a PC

For a safe connection over internet (from a remote laptop to the M2M
Gateway), the OpenVPN tunnel can be used. This way the web server of
M2M Gateway is not directly exposed to the internet and can be guarded by
firewall. For installing the OpenVPN client to a PC, perform the following
steps.
1. Obtain the OpenVPN client software. The newest version can be downloaded
from the internet from the following URL: http://openvpn.net/index.php/opensource/downloads.html. In case the link changes, you may navigate to the correct
location by opening http://openvpn.net page and going to Community and from
there to Downloads.
The correct package is called Windows installer and the filename is in form
of openvpn-install-n.n.n- Ix.x.x-<architecture>.exe, where the n.n.n
represents the current version (at the time of writing this document, the
filenames are):
openvpn-install-2.3.8-I601-i686.exe (32-bit)
openvpn-install-2.3.8-I601-x86_64.exe (64-bit)
Click the filename to download it. If youre unsure which package to
download, select the 32-bit version.
2. Run the installer and allow the installer to make changes to the computer.
Accept the default settings by clicking Next to the questions asked. If asked
whether to install TAP-Windows device software, click Install.
88 (134)

1MRS758449 EN

The OpenVPN uses secure cryptographic certificates for ensuring that:
The Client (PC) is authorized to connect to the server (M2M Gateway)
The server is really the server it states to be
The certificates are really coming from the stated authority (M2M GW)
The client configuration, created in M2M Gateway, needs to be put to OpenVPN
configuration directory. Follow the instructions below.
1. When the installation is done, start the OpenVPN GUI.
Note: In Windows Vista, 7 or 8, you will need to run the OpenVPN GUI with
administrator privileges, so that it can add routes (pulled from the OpenVPN
server) to the routing table. You can do this by right-clicking on the OpenVPN
GUI desktop icon (or OpenVPN GUI start menu icon), and selecting Run as
administrator.
To make "Run as administrator" permanent:
1. Right-click the OpenVPN GUI icon and select Properties.
2. Select the Compatibility tab and enable Run this program as an administrator.
3. OpenVPN can be started without selecting Run as administrator each time.
2. Open the directory, where you have extracted the clientpc1.zip file. Leave this
window open.
3. Click the start button (Windows logo) and select Open Windows Explorer,
then select Computer from the right-side vertical menu bar. Alternatively, type
explorer.exe to the search row and press enter.
4. In the Explorer window, double-click the C-drive text (showing as
Windows7_OS (C:) in the next picture, this is the usual drive letter).
Fig. 10.2.4-1 Selecting C-drive.

If you have changed the OpenVPN installation directory/drive in the installation
phase, select the respective drive, containing the OpenVPN folder.
5. Scroll down the list of folders until you see the folder Program Files. Again, scroll
down until you see a folder named OpenVPN. Double-click the OpenVPN folder.
Now you see several folders, double-click the config folder.
89 (134)

1MRS758449 EN
6. Copy the extracted files from the folder you have extracted the clientpc1.zip file
to OpenVPNs config folder.
Fig. 10.2.4-2 Copying files.

You may be asked for elevated permissions as the program files folder is
protected. Accept this by clicking Continue (See the picture below).
Fig. 10.2.4-3 Windows UAC verification

You have now copied the client certificate files to the OpenVPN directory and
may now start using the OpenVPN.
Using the OpenVPN
In a Windows PC, the OpenVPN is managed by the OpenVPN GUI, which can be
started as any other program. When started, the OpenVPN places an icon to the notification
area in Windows taskbar. You can select whether the icon is always shown or hidden
until Show hidden icons button is pressed.
In contemporary Windows versions, the programs are not run with Administrator
privileges, unless theres a need for that. The OpenVPN needs to be run with Administrator
90 (134)

1MRS758449 EN
rights as it needs to push routing entries to Windows routing table. The following steps are
instructing how to run the OpenVPN permanently with Administrator rights.
1. Start the OpenVPN by clicking Windows start button (Windows logo) and click
All programs and scroll down to OpenVPN, then click the OpenVPN text to see the
OpenVPN GUI menu option. Do not click it yet.
2. With right mouse button, click the OpenVPN GUI menu option, and then from the
context menu, select Properties (at the bottom of the context menu). The following
window opens. Click Compatibility tab.
Fig. 10.3-1 Properties screen

Place a tick to the checkbox Run this program as an administrator and press OK button.
Again, click Windows start button (Windows logo), click All programs and scroll
down to OpenVPN, then click the OpenVPN text and click OpenVPN GUI. If asked,
allow changes to be made to computer.
3. Now the OpenVPN client is started, but it hasnt established a VPN tunnel yet. You can
see the OpenVPN icon in the notification area of Windows taskbar.
91 (134)

1MRS758449 EN
4. When the OpenVPN is running, the OpenVPN GUI icon is seen, either directly in the
taskbar or by clicking Show hidden icons button (triangle-shaped button in the picture
above). You can customize the visibility of the OpenVPN GUI icon, see Windows
help for selecting which icons and notifications appear on the taskbar.
5. Click the OpenVPN GUI icon with right mouse button. A context menu opens.
Fig. 10.3-3 Connecting OpenVPN

Note: For this step, you will need to have an active internet connection in the PC.
6. Click Connect for establishing a VPN tunnel to the OpenVPN server (M2M Gateway).
You will momentarily see the connection screens similar to the pictures below,
disappearing once the
connection
is
established.
Fig. 10.3-4 Connecting log
Fig. 10.3-5 Connecting notification
92 (134)

1MRS758449 EN
7. Once the connection screen disappears, the VPN connection to M2M Gateway is
established. The state of the VPN connection can be checked by hovering the mouse
pointer over the OpenVPN icon.
8. For shutting down the VPN tunnel, right-click the OpenVPN icon and select
Disconnect from the context menu.
93 (134)

1MRS758449 EN
11 Configuring OpenVPN in Advanced mode

The advanced mode lets the person configuring the M2M GW to freely select the IP address
ranges, so it is a recommended approach when adapting the M2M solution to the already
existing site infrastructure.
Configuring OpenVPN in M2M Gateway, Advanced mode

If the M2M is a new one, follow first the users manual for connecting the device,
powering it up and performing initial setup, such as network interface configuration.
1. Open the M2M Gateways graphical user interface (GUI), the default URL for
accessing the M2M GW is https://10.10.10.10:10000. See M2M Gateways Users
manual for more details on accessing the GUI.
The M2M GW's GUI is using the HTTPS protocol and the certificate is "self-signed",
which means that it is not among the trusted certificates in web browsers. Therefore,
while logging in, the user must click the add an exception to add a security policy
exception or click "Continue to this website" (depending on the web browser).
2. Once logged in, click the OpenVPN icon.

Then, select the advanced mode with certificate based authentication.
Fig. 11.1-2, Advanced mode icon
94 (134)

1MRS758449 EN
Creating a new certificate authority

The Certificate Authority (CA) is typically used for ensuring that a webserver in the internet
is really the server it claims to be (e.g. a banks web server). In the context of this M2M
solution, were using CA certificate for ensuring that the client configuration has been
created with the particular, authorized M2M Gateway the client is connecting to.
1. First, one needs to create the CA certificate as it is empty by the default. Click the New
Certification Authority button.
Fig. 11.1.1-1 OpenVPN Administration window

2. Enter the name for CA, use only numbers and small letter alphabets without spaces or
special characters. You can leave the other settings as defaults and click Save for creating
the CA. You can e.g. use name testca (without quotes).
Fig. 11.1.1-2 Certificate Authority details

While the CA is created, the following screen output is printed.
95 (134)

1MRS758449 EN
Fig. 11.1.1-3 Generating CA certificate

3. Click Return to VPN List text.
Creating a new server certificate
The server (M2M Gateway) and each client (Arctics and PCs) are requiring certificates.
Create first the server certificate. Usually youll only need one OpenVPN server (and
thus one server certificate) in M2M Gateway, but there are configurations, where
several OpenVPN servers are running in one M2M GW.
An example of such configuration is one where Arctics are logging into one OpenVPN
server and another one is reserved for management purposes only.
1. Click Server/Client key administration button.
96 (134)

1MRS758449 EN
Fig. 11.1.2-1 Server/client key Administration
2. Enter the server certificate name and select the Server from drop down menu. Use only
numbers and small letter alphabets without spaces or special characters for server name.
Fig. 11.1.2-2 Server certificate details
97 (134)

1MRS758449 EN
You can leave the other settings as defaults and click Save for creating the server
certificate. While the server certificate is created, the following screen output is printed.
Fig. 11.1.2-3 Generating server certificate

3. Click the text Return to Keys list of Certification Authority testca.
Creating new client certificates
1. In the similar manner than creating server certificate, create at least one client certificate.
Note that each Arctic (or other client, like PC) will need its own client certificate.
98 (134)

1MRS758449 EN
Fig. 11.1.3-1 Client certificate details

2. You can leave the other settings as defaults and click Save for creating the client
certificate. While the client certificate is created, the following screen output is printed.
99 (134)

1MRS758449 EN
Fig. 11.1.3-2 Generating client certificate

3. Click the text Return to Keys list of Certification Authority testca and click again the
Server/Client key administration button.
4. Create one client for possible remote management PC client as well.
100 (134)

1MRS758449 EN
Fig. 11.1.3-3 Client PC certificate details

5. You can leave the other settings as defaults and click Save for creating the client PC
certificate. Click the text Return to Keys list of Certification Authority testca and click
return to OpenVPN with CA
Creating new server configuration

Once the server certificate exists, the OpenVPN server can be created.
1. Click the New VPN server button.
101 (134)

1MRS758449 EN
Fig. 11.1.4-1 Creating a new VPN server

2. The following setup page opens.
Fig. 11.1.4-2 OpenVPN server settings

Note: Before configuring the OpenVPN server, you will need to have the IP
addressing plan ready.
Use unique (separate networks, no overlapping) subnets for:
M2M GWs LAN
M2M GWs WAN
Each Arctics LAN
VPN peer IP addresses
Enter the following values:
Server name
Use only alphabets az and numbers 09
102 (134)

1MRS758449 EN
Port
You can leave the port as default 1194. If you wish to select another port, you need
to change the respective INPUT and FORWARD rules in M2M GWs firewall as
well.
Key
Select the server key youve created (testserver in this example).
Server Net IP assigns
The Net IP assigns parameter defines the subnet from where the OpenVPN server
allocates the clients peer IP addresses. The peer IP addresses are virtual IP addresses
denoting the endpoints of the VPN tunnel. Define the whole subnet address here,
individual peer IP addresses are set in each clients configuration.
In this example, the network 172.16.30.0/255.255.255.0 has been chosen. This 24-bit
mask subnet allows 64 clients (256 C-class addresses are divided into 30-bit peer
subnets, each having four IP addresses and two of them are actually used. See
OpenVPN documentation for more information on this peer IP design aspect).
Route
The server route covers all clients LANs. For example, if the clients (Arctics) have
the following LANs: Arctic1: 10.10.10.0/24, Arctic2: 10.10.11.0/24 and Arctic3:
10.10.12.0/24, we can set the server route to 10.10.0.0/16. Now the server has only
one routing entry for all Arctics LANs and it also covers future expansion (Arctic4:
10.10.13.0 and so on). In a production installation, smaller subnets may be defined
than in this example (It is unlikely that e.g. Arctics LAN would require 254 usable
IP addresses, as in the 24-bit mask subnet).
The other parameters can be left as defaults (in a large installation the maximum
number of concurrent clients can be increased, though).
3. Create the server by clicking Save button. The Administration page should now
show the created server.
4. Click Start for starting the server.
103 (134)

1MRS758449 EN
Fig. 11.1.4-3 Starting OpenVPN server

Adding clients to the server
1. Click add/list clients for adding the client configurations.
Fig. 11.1.5-1 Adding clients

2. Click New VPN client button. Fill in the values as instructed below. Change the
M2M_Public_IP to real value of the public IP Of M2M GW (the IP address the
M2M GW can be connected to via internet or other WAN).
Fig. 11.1.5-2 Client configuration

Name
104 (134)

1MRS758449 EN
Select the clients name form pull down menu (the name is the client certificates
name, testclient in this example).
Protocol
The protocol in this implementation is UDP although the OpenVPN allows also
TCP.
Device
Select the tun device. The OpenVPN supports tun and tap devices, but only tun is
supported in this implementation.
CA
Select the CA, which was used in this client certificate generation. Usually, there
is only one CA and it is automatically selected.
Choose key, Client certificate and Client key and Random file
These are configured automatically.
Server settings
The server settings network and netmask is already defined in Server
configuration. This is the subnet from where the OpenVPN peer IP addresses are
allocated.
Ifconfig (Transport network)
Define Arctics VPN peer IP here. The OpenVPN peer IP address pairs can be
selected from the following set. The address pair must be unique and a 30-bit
netmask (4 IP addresses per subnet) is used for each pair. The structure is in form
of [<M2M_peer_IP>,<Arctic_peer_IP>].
[1, 2] [5, 6] [9, 10] [13, 14] [17, 18] [21, 22] [25, 26] [29, 30] [33, 34] [37, 38]
[41, 42] [45, 46] [49, 50] [53, 54] [57, 58] [61, 62] [65, 66] [69, 70] [73, 74] [77,
78] [81, 82] [85, 86] [89, 90] [93, 94] [97, 98] [101,102] [105,106] [109,110]
[113,114] [117,118] [121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158] [161,162] [165,166]
[169,170] [173,174] [177,178] [181,182] [185,186] [189,190] [193,194]
[197,198] [201,202] [205,206] [209,210] [213,214] [217,218] [221,222]
[225,226] [229,230] [233,234] [237,238] [241,242] [245,246] [249,250]
[253,254]
105 (134)

1MRS758449 EN
Remote IP server
This is the WAN IP address of M2M Gateway, which is static, usually public, IP
address. The client configuration generated here is installed to Arctic, which is
put to the field, therefore the term remote denotes remote to Arctic.
The M2M GWs WAN IP can also be private, but then the border router having
public IP address must forward the packets to M2M GW (D-NAT and port
forwarding). See different scenarios in VA-09-1-4 Configuration guide.
Remote backup IP server
The backup M2M GWs public IP address, if present.
Push route
The M2M GW is able to push routes to Arctics. These routing table entries are
enabled after the VPN tunnel has established. In this example, it is assumed that
all Arctics are available in 10.10.0.0/16 subnet, which is further divided into
smaller subnets for each Arctic, e.g. 10.10.10.0/24, 10.10.11.0/24, 10.10.12.0/24
and so on.
In this example, the push route allows Arctics to communicate with each other
via M2M GW; if the packets destination IP fits to 10.10.x.x and doesnt belong
to Arctics LAN, the Arctic will send the packet to M2M GW via OpenVPN
tunnel and the M2M GW in turn routes the packet to another VPN tunnel for
destination Arctic.
3. Click Save button to store the configuration. Now clicking the add/list clients
shows the following screen.
Fig. 11.1.5-3 VPN client list
Exporting the client configuration file

1. Still, in the add/list clients page, click the Export text.
106 (134)

1MRS758449 EN
Fig. 11.1.6-1 Exporting the client configuration file

2. The open dialog opens, select save file and save the file to your PC to an
easily locatable directory.
Fig. 11.1.6-2 Saving client configuration file

The file is in form of .zip file. Extract the Zip to the directory youve created.
The following files are inside the Zip file (see picture below).
Fig. 11.1.6-3 Files inside the Zip

The files will be later on transferred to Wireless Gateway/Controller.
Configuring OpenVPN in Wireless Gateway/Controller

Configuring the OpenVPN client settings in Wireless Gateway/Controller includes the
following sub steps that are instructed in next chapters.
Importing the client identity
Importing the trusted CA certificate
Configuring the OpenVPN client settings
107 (134)

1MRS758449 EN
Importing the client identity

1. Click the VPN Certificates. In the local identity page, click the Import new button.
Fig. 11.2.1-1 Import new OpenVPN client local identity

2. Verify that the Complete certificate (PEM) is selected. Click Continue button. In
the following screen, you will need to define the name of the local identity, (enter a
free text description) and define the path to the following files.
X.509 Certificate (=*.crt, in this example testclient.crt)
RSA Private Key (= *.key, in this example testclient.key)
Fig. 11.2.1-2 Importing certificate and private key

Click Browse button for defining the X.509 Certificate; locate the directory
where you have previously extracted the client configuration file exported
from M2M Gateway. Select the file testclient.crt. You dont have to
define name to the client (the certificate filename will then be used).
In the similar manner, define the private key by clicking the Browse button
for defining the RSA private key; locate the directory where you have
previously extracted the client configuration file exported from M2M
Gateway. Select the file testclient.key.
3. Click Submit button for storing the settings. The screen should look as follows.
108 (134)

1MRS758449 EN
Fig. 11.2.1-3 Local identity window

Importing the trusted CA certificate
1. In the Certificates page, click the Trusted CA tab. Fill in the Name field by
typing e.g. CA. Click Browse button and for defining the CA Certificate, locate
the directory where you have previously extracted the client configuration file
exported from M2M Gateway. Select the file ca.crt. You dont need to write
the certificate name to the Name field, the filename will be used.
Fig. 11.2.1-4 Importing truested CA certificate
2. Click Submit button for storing the settings. The screen should look as follows.
Fig 11.2.1-5 Trusted CA window
109 (134)

1MRS758449 EN
Configuring Arctics OpenVPN client settings

1. Click OpenVPN from the left menu pane of Arctic. Click Advanced
OpenVPN setup, click Create New button. Fill in the following values, leave
others as defaults.
a. Server IP, port (M2M GWs WAN IP address), OpenVPN port, 1194
by default.
b. Routing, select Default Route. With this setting, all packets to
unknown destination are sent to M2M Gateway via OpenVPN tunnel
for further routing.
c. Local Certificate, select the client you have imported (testclient in this
example).
d. Trusted CA, select the CA certificate you have imported (ca.crt in this
example).
Fig. 11.2.2-1 OpenVPN client configuration screen
110 (134)

1MRS758449 EN
2. Click Submit button. The following screen should appear.
Fig. 11.2.2-2 OpenVPN client window

3. Reboot the Wireless Gateway/Controller.
Configuring the PC OpenVPN client for remote administration

In some cases there is a need for connecting to M2M Gateway or Wireless
Gateways/Controllers and other field devices (e.g. Remote Terminal Units) through
the field engineers laptop. The safest way to do it is to use the OpenVPN tunnel
between the M2M Gateway and the laptop.
Fig. 11.3-1 OpenVPN field laptop connection diagram

The configuration work is divided into the following sub steps that are instructed in
next chapters.
Configuring OpenVPN in M2M Gateway
(the PC client certificate is already created)
Creating a new OpenVPN client in M2M Gateway
1. Go to M2M Gateway Open VPN configuration OpenVPN with certificatebased authorization Add/list clients.
2. Click new VPN client button. Fill in the following and leave others as defaults.
111 (134)

1MRS758449 EN
a. Name, select clientpc1 from the pull down menu (you have earlier
created this client certificate).
b. Ifconfig (Transport network), select 172.16.30.250 as peer IP address.
c. Remote (Remote IP), enter the M2M GWs public IP address.
d. Push route, enter 10.10.0.0/255.255.0.0 here. This covers all Arctics.
Fig. 11.3.1-1 OpenVPN PC clients settings

1. Click Export text in the clientpc1 row.
Fig. 11.3.2-1 Exporting PC client configuration

2. Select a directory in the PC where to store the client configuration file (either directly
to the computer, which is used in remote administration or you may first export the
file and later transfer it to the remote administration PC. Perform step 3 and onwards
only after the file is transferred to the PC used in remote administration).
112 (134)

1MRS758449 EN
Fig. 11.3.2-2 Saving Zip file

3. Unzip the file (click the file with right button and select Extract all or similar,
depending on the extract program).

For safe connection from remote laptop to M2M Gateway over the internet, the VPN
tunnel can be used. This way the web server of M2M Gateway is not directly
exposed to the internet and can be guarded by firewall. For installing the OpenVPN
client to your PC, perform the following steps.
1. Obtain the OpenVPN client software. The newest version can be downloaded from
the internet from the following URL: http://openvpn.net/index.php/opensource/downloads.html. In case the link changes, you may navigate to the correct
location by opening http://openvpn.net page and going to Community and from there
to Downloads.
Fig. 11.3.3-1 Installing PC OpenVPN client
113 (134)

1MRS758449 EN
The correct package is called Windows installer and the filename is in form of
openvpn-install-n.n.n-Ix.x.x-<architecture>.exe, where the n.n.n represents the
current version (at the time of writing this document, the filenames are):
openvpn-install-2.3.8-I601-i686.exe (32-bit)
openvpn-install-2.3.8-I601-x86_64.exe (64-bit)
Click the filename to download it. If youre unsure which package to download, select
the 32-bit version.
2. Run the installer and allow the installer to make changes to the computer. Accept the
default settings by clicking Next to the questions asked. If asked whether to install
TAP-Windows device software, click Install.

The OpenVPN uses secure cryptographic certificates for ensuring that:
The Client (PC) is authorized to connect to the server (M2M Gateway)
The server is really the server it states to be
The certificates are really coming from the stated authority (M2M GW)
The client configuration, which was created in M2M Gateway, needs to be put to
PCs OpenVPN configuration directory. Follow the instructions below.
1. When the installation is done, you can start the OpenVPN GUI.
Note: In Windows Vista, 7 or 8, you will need to run the OpenVPN GUI with
administrator privileges, so that it can add routes to the routing table that are pulled
from the OpenVPN server. You can do this by right-clicking on the OpenVPN GUI
desktop icon (or OpenVPN GUI start menu icon), and selecting "Run as
administrator".
To make "Run as administrator" permanent:
Right-click the OpenVPN GUI icon and select Properties.
Select the Compatibility tab and enable Run this program as an administrator.
You can now start OpenVPN without having to select Run as administrator each
time.
2. Open the directory, where you have extracted the clientpc1.zip file (See chapter
Exporting the certificate from M2M Gateway to a PC for details). Leave this
window open.
114 (134)

1MRS758449 EN
3. Click the start button (Windows logo) and select Computer from the right-side
vertical menu bar. Alternatively, type explorer.exe to the search row and press enter.
4. In the Explorer window, double-click the C-drive text (showing as Windows7_OS
(C:) in the next picture).
Fig. 11.3.4-1 C-Drive

5. Scroll down the list of folders until you see the folder Program Files. Again, scroll
down until you see a folder named OpenVPN. Double-click the OpenVPN folder.
Now you see several folders, double-click the config folder.
6. Copy the extracted files from the folder you have extracted the clientpc1.zip file to
OpenVPNs config folder.
Fig. 11.3.4-2 Copying extracted client configuration files

You may be asked for elevated permissions as the program files folder is protected by
Windows. Accept this by clicking Continue.
Fig. 11.3.4-3 Windows UAC verification

115 (134)

1MRS758449 EN
7. You have now copied the client certificate files to the OpenVPN directory. You may
now start using the OpenVPN.
Using the OpenVPN

In a Windows PC, the OpenVPN is managed by the OpenVPN GUI, which can be
started as any other program. When started, the OpenVPN places an icon to the
notification area in Windows taskbar. You can select whether the icon is always
shown or hidden until Show hidden icons button is pressed.
In contemporary Windows versions, the programs are not run with Administrator
privileges, unless theres a need for that. The OpenVPN needs to be run with
administrator rights as it needs to push routing entries to Windows routing table. The
following steps are instructing how to run the OpenVPN permanently as
Administrator.
1. Start the OpenVPN by clicking Windows start button (Windows logo) and click All
programs and scroll down to OpenVPN, then click the OpenVPN text to see the
OpenVPN GUI menu option. Do not click it yet.
2. With right mouse button, click the OpenVPN GUI menu option, and then from the
context menu, select Properties (at the bottom of the context menu). The following
window opens. Click Compatibility tab.
Fig. 11.4-1 Running OpenVPN with Administrator rights
116 (134)

1MRS758449 EN
Place a tick to the checkbox Run this program as an administrator and press OK button.
Again, click Windows start button (Windows logo), click All programs and scroll
down to OpenVPN, then click the OpenVPN text and click OpenVPN GUI. If asked,
allow changes to be made to computer.
3. Now the OpenVPN client is started, but it hasnt established a VPN tunnel yet. You can
see the OpenVPN icon in the notification area of Windows taskbar.
Fig. 11.4-2 Opening OpenVPN context menu

4. When the OpenVPN is running, the OpenVPN GUI icon is seen, either directly in the
taskbar or by clicking Show hidden icons button (triangle-shaped button in the picture
above). You can customize the visibility of the OpenVPN GUI icon, see Windows
help for selecting which icons and notifications appear on the taskbar.
5. Click the OpenVPN GUI icon with right mouse button. A context menu opens.
Fig. 11.4-3 Connecting OpenVPN client

Note: For this step, you will need to have an active internet connection in the PC.
6. Click Connect for establishing a VPN tunnel to the OpenVPN server (M2M Gateway).
You will momentarily see the connection screens similar to as pictures below,
disappearing once the connection is established.
117 (134)

1MRS758449 EN
Fig. 11.4-4 and 11.4-5 Connecting and connected client

7. Once the connection screen disappears, the VPN connection to M2M Gateway is
established. The state of the VPN connection can be checked by hovering the mouse
pointer over the OpenVPN client name.
8. For shutting down the VPN tunnel, right-click the OpenVPN icon and select
Disconnect from the context menu.
118 (134)

1MRS758449 EN
12 Testing the solution Easy OpenVPN setup

This test setup sets the OpenVPN client PCs route so that the Arctics LANs can be
reached. This is done by pushing the route 10.32.0.0/11 (from 10.32.0.0 till
10.63.255.255) to the PC when the VPN tunnel is coming up. This way the PC has a
route to all Arctics configured by Easy OpenVPN.
Verify that the Arctic is turned on for this test and that it is configured as according to
these instructions.
Perform the following tests.
1. When the OpenVPN client is on, ping the Arctics IP from the PC. Open the
command prompt (Start cmd) and enter the command:
ping n 5 10.32.1.1
The Arctic should answer to the ping messages.
2. Open a browser and enter the URL for Arctics GUI, e.g. https://10.32.1.1. The
Arctics GUI should open. Note that depending on the cellular speed, this may
take a while.
3. If there is a PC in the Arctics LAN, e.g. 10.32.1.2, you may try pinging it as well.
Remember to allow ICMP ping in PCs firewall and check that the Arctics LAN
IP (10.32.1.1) is set as default gateway in the PC and that no other gateway (e.g.
through WiFi) is enabled.
4. Youre also able to connect to M2M GWs Web HMI if configured accordingly.
This can be tested by changing the M2M GWs eth1 (LAN) interface to e.g.
10.64.0.1/255.255.255.0 (Save and Apply). Then, you can enter the M2M GWs
LAN interface address to a browser in your PC: https://10.64.0.1:10000, the M2M
GWs Web HMI should now open.
119 (134)

1MRS758449 EN
13 Testing the solution Advanced OpenVPN setup

This test setup sets the OpenVPN client PCs route so that the Arctics LANs can be
reached. This is done by pushing the route 10.10.0.0/16 to the PC when the VPN
tunnel is coming up. This way the PC has a route to all Arctics.
Verify that the Arctic is turned on for this test and that it is configured as according to
these instructions.
Perform the following tests.
1. When the OpenVPN client is on, ping the Arctics IP from the PC. Open the
command prompt (Start cmd) and enter the command:
ping n 5 10.10.10.10
The Arctic should answer to the ping messages.
2. Open a browser and enter the URL for Arctics GUI, e.g. https//10.10.10.10.
The Arctics GUI should open. Note that depending on the cellular speed, this
may take a while.
3. If there is a PC in the Arctics LAN, e.g. 10.10.10.20, you may try to ping it as
well. Remember to allow ping in PCs firewall and check that the Arctics
LAN IP (10.10.10.10) is set as default gateway in the PC and that no other
gateway (e.g. through WiFi) is enabled.
120 (134)

1MRS758449 EN
14 Troubleshooting
Troubleshooting steps
Follow the instructions below for troubleshooting the system. Try to test each leg of
the connection path individually.
1. Check that Arctic has received an IP address from cellular network (System Status).
There should be interface called gprs0, usb0 or wwan0 depending on the model of the
device. If not, verify that the SIM card is inserted and check the Access point name,
Authentication, Username and Password parameters in SIM card settings of Mobile
WAN. Check also that the interface using the SIM card is enabled and set as primary
WAN interface in WAN failover.
2. Check that Arctic has VPN interface vpnc_tun0 in (Menu Status). This means that
the OpenVPN tunnel is up. If not, check that the M2M GW is available in the IP
address defined in Arctics OpenVPN setup. Check as well that the certificates are
properly installed and that the Arctics clock is set to time. Check the Arctics syslog
(Tools System log) for further troubleshooting.
3. Check the OpenVPN peer from M2M Gateway. In OpenVPN (with certificate based
authentication) page, click Add/list clients text and check the checkbox in the left side
of testclient. Then click Start check button. Wait until the test completes and see the
check column in the display. The result should be OK. If Failed verify the M2M
Gateways default gateway setting and firewall settings for OpenVPN port.
4. Try pinging the M2M GW from your SCADA or other monitoring program. If it is in a
different LAN than M2M Gateways LAN, you will need to define a static route to
M2M GW (Network configuration Routing and gateways Static routes). Verify
as well that you have 10.10.0.0/16 (Arctics LANs) set as a static route to SCADA
server (or if in the same LAN as M2M GW, the M2M GWs LAN IP can be set as
default gateway to SCADA).
5. Try pinging the Arctics LAN IP 10.10.10.10 (10.32.1.1 in Easy OpenVPN setup) from
SCADA server. If there is an Ethernet connected RTU in Arctics LAN (e.g.
10.10.10.21), try pinging it as well. If no answer, check that the Arctics IP 10.10.10.10
(10.32.1.1 in Easy OpenVPN setup) is set as default gateway to RTU.
6. Try polling the RTU or similar directly with its LAN IP from SCADA. If no answer,
check the static route and other routing to the M2M GW.
Troubleshooting the routing
121 (134)
1MRS758449 EN

Even though the cellular connection and the VPN tunnel is up and running, there may
still be some routing settings that need to be done. The following picture describes
each route or routing setting, in order to give an idea on how the routing is working.
8
9
1
M2M
LAN
SCADA
LAN
Eth1
Eth0
Arctic
LAN
GPRS
Internet
M2M Gateway
Arctic
10
11
7
3
SCADA
VPN tunnel
M2M GWs
Peer IP
4
Arctics
Peer IP
Device
Fig. 14.2-1 Routing

As the system operates in IP routing layer, each node of the system must have a route
to another remote nodes, or a default route entry to the next router. The route arrows
are explained below.
1. M2M GWs default route
In usual installations, the Arctics are having dynamic (i.e. changing) cellular IP
addresses and the operator may also change the IP address ranges for mobile clients.
Because of that, it is recommended that the M2M GWs default GW is the internet
router (i.e. WAN router towards the mobile clients), accessible via M2M GWs eth0
network interface.
Verify that the default GW of M2M GW can be reached via M2M GWs eth0 interface
(the default router must have a network interface in the subnet of M2M GWs eth0
interface). Usually it is not advised to create more than one default route.
2. M2M GWs route to SCADA subnet
There are cases, where the SCADA server(s) are in a dedicated SCADA LAN, attached
to M2M GWs LAN via a router and firewall. If this is the case, the M2M GW will
need a static route so that it is aware of the SCADA LAN, accessible via a router in
M2M GWs LAN. If your setup has a dedicated SCADA LAN, verify that the M2M
GW is having a static route to the SCADA LAN.
In M2M Gateway, the static routes are entered in Network Configuration
Routing and gateways
122 (134)

1MRS758449 EN
Fig. 14.2-2 Static routes

Note as well that the Arctic needs to know where to send packets destined to SCADA
LAN. Usually this is done by setting the Routing as Default route in Arctics VPN
settings. Using this first option, there is no need for defining the SCADA LAN routing
entry in Arctic. Second option would be to use e.g. OpenVPN push route to push the
SCADA LAN route to Arctic.
Third, an explicit routing entry can be done in Arctics VPN routing setting, however,
only one route can be added this way, so if both M2M LAN and SCADA LAN routes
are needed (and if they cant be covered by a single CIDR route), it is recommended to
use the first option (i.e. default route towards the VPN tunnel).
3. SCADA servers route to all Arctics LANs
The SCADA server needs to know where to send IP packets going to Arctics. This can be
done by setting the M2M GWs eth1 interfaces IP as SCADA servers default GW.
Usually this is not possible, as the SCADA server may need to have another default GW
than M2M GW server. Alternatively, a static (persistent) route can be set in SCADA server
so that it is aware that the IP addresses of Arctic LANs are accessible through the M2M
GWs eth1 interface.
Example for Windows operating system:
route add p 10.32.0.0 mask 255.255.0.0 192.168.0.1
The command above enters a persistent (rebooting doesnt remove it) route to
SCADA servers routing table so that it will send IP packets with destination
address in a range from 10.32.0.0 till 10.32.255.255 to M2M GW.
The M2M GW in turn will send the packets to the respective Arctics VPN tunnel.
The range 10.32.0.0 till 10.32.255.255 is enough for 256 Arctics each having 254
IP addresses (netmask 255.255.255.0) in their LANs.
4. M2M GWs point-to-point route to Arctics peer IP
The VPN peer IP addresses are denoting the endpoints of the VPN tunnel and are virtual IP
addresses appearing when the tunnel is up. The addresses are configured in the M2M GW
and it is responsible for allocating the peer IPs to the clients (i.e. Arctics). The peer IP
addresses are tied to VPN adapters (tun or tap adapter in OpenVPN case). Note that the
OpenVPN peer IP addresses may not answer to ping requests in all configurations.
The peer IP address can be used for logging in to the device (M2M GW or Arctic).
Also, the peer IP address is used for adding routing entries (i.e. which subnets are
123 (134)

5.
6.
7.
8.
9.
1MRS758449 EN
available at the other end of the tunnel). As the Arctic has by default the S-NAT
enabled (see chapter S-NAT for more information), the packets coming from Arctic
to M2M GW are having Arctics OpenVPN peer IP address as source address.
Arctics point-to-point route to M2M GWs peer IP
See the previous point. The Arctic will rename the tunnel adapter to vpnc_tun[n] and it can
be seen in the status screen as one of the network interfaces.
M2M GWs OpenVPN server route to all clients (Arctics)
The OpenVPN server needs a route that covers all clients LANs. This is a CIDR route that
contains all consecutive Arctics subnets. This is set in OpenVPN advanced mode, by
clicking the server name, the parameter is route. If all Arctics subnets are within the
10.32.x.x address space, the server route can be 10.32.0.0/255.255.0.0.
M2M GWs route to Arctics LAN via VPN tunnel
The M2M GW needs to know all the Arctics LAN subnets (i.e. which Arctics subnet is
behind which tunnel). This is defined in M2M GWs OpenVPN peer settings with iroute
parameter. The iroute is the LAN subnet IP address, e.g. if the Arctic has IP
10.32.0.1/255.255.255.0, the subnets IP address is 10.32.0.0. Each Arctic must have
unique LAN subnet (they cant overlap each other).
Arctics cellular network connection
When the cellular modem of the Arctic is enabled, it registers to cellular network and
receives an IP address. From the Arctics scope, this is a point-to-point IP towards the
cellular infrastructure. There are different modem drivers depending on the modem module
and Arctics kernel version, so the Arctics cellular interface name and point-to-point IP
address will vary.
WAN default route in Arctic
In Arctics WAN failover menu, there is a setting WAN default route, which is usually
configured as enabled (recommended). Then the Arctic will use currently enabled WAN
interface as a default route for outgoing packets.
There are some configurations, where the WAN default route may cause problems
(e.g. asymmetric routing in some private APN cases), but these are rarely encountered.
If the WAN default route is set as No, the Next hop parameter needs to be
defined in Arctics OpenVPN configuration.
10. Arctics LAN devices default gateway
A device in Arctics LAN should use the Arctic as the default gateway. This is the easiest
option and doesnt require any configuring work for devices in Arctics LAN if the network
configuration changes. Alternatively (e.g. in a case there is a PC with a need for default
gateway via other network interface), a static (persistent) route can be configured. The
static route must include the SCADA or other control servers subnet and if it is a different
124 (134)

1MRS758449 EN
network than M2M GWs LAN subnet, there may be a need for adding a separate route for
M2M GWs LAN as well.
11. Arctics VPN routing
The Arctic is configured to know the LAN subnet in the other side of the VPN tunnel.
When the VPN tunnel is up, there are three possibilities for telling the Arctic which
networks can be connected through the VPN tunnel:
Routing entry in Arctics VPN configuration (a host, a subnet or several contiguous
subnets in CIDR notation)
Default route in Arctics VPN configuration (all packets are sent to the VPN
tunnel)
OpenVPN push route, defined in M2M GW (a host, a subnet or several subnets in
CIDR notation, the M2M GW will push this route over VPN tunnel to Arctic
once the tunnel is established)
While it is usually the easiest to configure the Arctic to use the VPN tunnel as a
default route, there are some cases, where it is not possible. If the Arctic is to be used
as GPRS router directly to the internet and also as a VPN router towards M2M GW,
one must define either a routing entry in VPN configuration or the OpenVPN push
route. In such a use case, the packets going to M2M GWs LAN are routed via VPN
tunnel and other packets are sent to internet via cellular network.
An example of this kind of use case would be a PC in a remote site, which needs
internet connection, but at the same time it will need a VPN connection to the main
site.
125 (134)

1MRS758449 EN
15 Network IP planning
As in any TCP/IP-connected computer network, the IP network planning plays very
important role when setting up the M2M solution. It is a good practice to have a ready-made
IP plan before continuing to the setup of the devices.
The answer for how many private and public IP addresses are needed depends on the
network setup; the number of M2M GWs and field devices and also on the number of
TCP/IP connected devices in Wireless Gateways/Controllers LANs, if any.
The private IP addresses are typically used in M2M GW's LAN, in VPN peer IPs and in
Wireless Gateways/Controllers LANs. To avoid overlapping the network address space
(thus causing possible routing problems), it is a good practice to use different class of private
IP addresses for each set of addresses.
Scenario 1, the M2M GW connected with public IP address
In this example, the M2M GW LAN networks IP address is 192.168.0.0 and netmask is
255.255.255.0. This is also represented as 192.168.0.0/24, since the 255.255.255.0 netmask
is 24-bit. The 24-bit netmask (C class network) is chosen for the example as it is easy to
understand.
The LAN subnet address is 10.10.10.0/24 and the VPN peer addresses are chosen from
172.16.0.0/16 address space.
Note: In order to avoid routing problems, it is important that the VPN peer IP addresses are
not overlapping the existing IP addresses in the system.
In this simple setup, there is only one public, routable IP address needed; The M2M GW's IP
address. In this scenario, the M2M GW is connected directly to Internet with one public IP
address via its eth0 interface.
126 (134)

1MRS758449 EN
Fig. 15.1-1 Scenario 1
Entity
IP address
Netmask
M2M LAN
192.168.0.0
255.255.255.0
M2M LAN IP (eth1)
192.168.0.1
255.255.255.0
SCADA computer
192.168.0.2
255.255.255.0
VPN peer addresses
M2M: 172.16.0.1
Device: 172.16.0.2
Point-to-point
M2M WAN IP (eth0)
Public, not shown
N/A
Wireless Gateway LAN
10.10.10.0
255.255.255.0
Wireless Gateway LAN IP
10.10.10.1
255.255.255.0
Ethernet device
10.10.10.2
255.255.255.0
Wireless Gateway GPRS IP
Dynamic, not shown
N/A
Scenario 2, M2M GW behind the company firewall

Again, only one public IP address is needed in this scenario, for company firewall/router.
The M2M GW is behind the firewall in a de-militarized zone (DMZ). Since the M2M GW
has now a private IP address, there must be a way for connecting to it from the Internet.
127 (134)

1MRS758449 EN
The connection from the Internet to M2M GW is implemented with D-NAT and port
forwarding. Again, here the Wireless Gateways/Controllers are using the cellular operators
public access point for connecting to the Internet.
Example network plan:
Fig. 15.2-1 Scenario 2
Entity
IP address
Netmask
M2M LAN
192.168.0.0
255.255.255.0
M2M LAN IP (Eth1)
192.168.0.1
255.255.255.0
SCADA computer
192.168.0.2
255.255.255.0
VPN peer addresses
M2M: 172.16.0.1
Device: 172.16.0.2
Point-to-point
DMZ LAN
192.168.1.0
255.255.255.0
M2M DMZ LAN IP (eth0)
192.168.1.2
255.255.255.0
FW/Router DMZ LAN IP
192.168.1.1
255.255.255.0
FW/Router public IP
Public, not shown
N/A
10.10.10.0
255.255.255.0
10.10.10.1
255.255.255.0
128 (134)
1MRS758449 EN

Ethernet device
10.10.10.2
255.255.255.0
Dynamic, not shown
N/A
Wireless Gateways/Controllers and private cellular access point

In some solutions it is decided to use the operators private access point in cellular network.
This will always need a special contract with cellular operator. Using the private access point
has a benefit in form of fixed IP addresses for each SIM card, but theyre also more
expensive solution.
The M2M GW is not necessarily needed in this scenario, as the cellular network is able to
provide static IP addressing. However, the following scenario is possible to implement with
M2M GW. The added value is two-fold; the private access point increases security and
M2M GW provides easy and proven methods and tools for controlling the VPN tunnels and
managing Wireless Gateways/Controllers.
Example network plan:
Cellular operators
VPN tunnel
Static IP address
associated to the
SIM card
192.168.1.1
M2M
LAN
Eth1
Eth0
M2M Gateway
DMZ network
192.168.1.0/24
Arctic
LAN
GPRS Private
APN
DMZ
Arctic
VPN Router
IP: 10.10.10.1
Netmask: 255.255.255.0
Default GW: VPN
Eth0: 192.168.1.2
Netmask: 255.255.255.0
Default GW: 192.168.1.1
Eth1: 192.168.0.1
Netmask: 255.255.255.0
SCADA
computer
IP: 192.168.0.2
Netmask: 255.255.255.0
Default GW: 192.168.0.1
VPN tunnel
VPN peer IP addresses:
172.16.0.1:172.16.0.2
Ethernet
device
IP: 10.10.10.2
Netmask: 255.255.255.0
Default GW: 10.10.10.1
Fig. 15.3-1 Private APN scenario
129 (134)

Entity
IP address
Netmask
M2M LAN
192.168.0.0
255.255.255.0
M2M LAN IP (Eth1)
192.168.0.1
255.255.255.0
SCADA computer
192.168.0.2
255.255.255.0
VPN peer addresses
M2M: 172.16.0.1
Device: 172.16.0.2
Point-to-point
DMZ LAN
192.168.1.0
255.255.255.0
M2M DMZ LAN IP (eth0)
192.168.1.2
255.255.255.0
FW/Router DMZ LAN IP
192.168.1.1
255.255.255.0
FW/Router WAN IP
Static, not shown
N/A
10.10.10.0
255.255.255.0
10.10.10.1
255.255.255.0
Ethernet device
10.10.10.2
255.255.255.0
Static, not shown
N/A
1MRS758449 EN
IP v4 addressing
Public and private IP addresses
The public IP addresses are routable unique addresses in Internet. Private IP addresses are
not routable in Internet, but they can be routed between the private networks. This M2M
solution needs at least one public IP address, for the connection to the Internet. It may be
assigned to M2M Gateway or it can be a company border router, which needs to be
configured for forwarding packets to M2M GW (see Scenario 2, M2M GW behind the
company firewall).
130 (134)

1MRS758449 EN
IP address classes
In the modern IP-addressing, especially in public IP addresses, the classful addresses are not
very common. The lack of addresses in IP v.4 are causing the Internet service providers
switching to classless addressing, where the netmasks are not fitting to the A, B or C classes,
but instead are used to divide the classful addresses into smaller networks.
The historical division of network classes as A, B and C are described in the following table.
The D and E classes are omitted for the sake of clarity. The important thing in planning the
IP network in M2M solution is the number of hosts per network.
Class
Netmask
Size of network
Number bits
Size of host Number of Hosts per

Number bits networks
network
255.0.0.0
24
128
16777214
255.255.0.0
16
16
16384
65534
255.255.255.0 24
2097152
254
Classless IP-addressing
As can be seen in the table of classful private IP addressing, the smallest number of hosts per
network is 254 (class C). Sometimes, especially in Wireless Gateways/Controllers LANs, a
smaller number of hosts would be enough.
When calculating the network size, it is commonly found that there is probably one or two
Ethernet connected devices behind each Wireless Gateway/Controller. Let's assume in this
example, that we may need some room for future expansion. Therefore, the suitable netmask
would be 29-bit for leaving three IP addresses for maintenance purposes or future use.
131 (134)

1MRS758449 EN
Fig. 15.4.3 CIDR example

When we look closer to LAN, we can see that the IP addresses are from class A private
network 10.x.x.x, but the netmask, 255.255.255.248 is not. The class A has been subnetted
to smaller networks having 8 IP addresses per network.
The number of IP addresses in class A private network is 16777216. It would be a waste of
IP addresses to use all 16777216 addresses, when there is only a need for 8 IP addresses.
Instead, by dividing the class A private IP address space to networks having 8 IP addresses,
there is now a possibility in theory to have 2097152 Wireless Gateways/Controllers, each
having 8 IP address network, which can handle 6 TCP/IP connected devices, gateway device
itself included (2 IP addresses are consumed for network and broadcast address per
network).
The following table shows IP addressing, when using 29-bit subnet for Wireless
Gateway/Controller.
IP address
Netmask
Description
10.10.10.0
255.255.255.248 Network address
10.10.10.1
255.255.255.248 Wireless Gateway
10.10.10.2
255.255.255.248 Device #1
10.10.10.3
255.255.255.248 Device #2
10.10.10.4
255.255.255.248 Reserved for future
132 (134)

10.10.10.5
10.10.10.6
10.10.10.7
255.255.255.248 Broadcast address
1MRS758449 EN
Routing
A typical scenario of routing in M2M solution is that there is a local network at the M2M
GW and a remote network behind the Wireless Gateway/Controller. Furthermore, the
devices connected to these two networks need to communicate with each other. An example
of such communication would be a SCADA system in the LAN of M2M GW that
communicates with an Ethernet RTU device, connected to Wireless Gateways/Controllers
LAN at a remote site.
In routing point of view, the M2M GW knows the route to each Wireless
Gateway/Controller via the VPN tunnel (via VPN peer IP addresses). For achieving end-toend communication between two devices residing at LANs of M2M GW and Wireless
Gateway/Controller, this is not enough; it is needed to tunnel the local area networks over
the VPN connection.
This is done by setting the VPN routing parameters with the required values of the network
IP address of the opposite end's LAN (i.e. it is defined which networks are available via
certain VPN tunnel).
CIDR, classless inter-domain routing
When there are several networks, it may be a tedious task to maintain routing table entries
for each individual network. In CIDR routing, a contiguous address space of several smaller
networks is referenced with one routing entry having netmask of a larger network.
An example would be the following networks
10.10.10.0/29
10.10.10.8/29
10.10.10.16/29
10.10.10.24/29
All of these networks can be referenced with only one CIDR network address with netmask
10.10.10.0/27.
See RFC 1519 for more information on CIDR.
133 (134)
Document revision history

Document revision/date
A / 23 November 2015
History
First revision
Disclaimer and Copyrights

The information in this document is subject to change without notice and should not be construed as a
commitment by ABB Oy. ABB Oy assumes no responsibility for any errors that may appear in this document.
In no event shall ABB Oy be liable for direct, indirect, special, incidental or consequential damages of any
nature or kind arising from the use of this document, nor shall ABB Oy be liable for incidental or consequential
damages arising from use of any software or hardware described in this document.
This document and parts thereof must not be reproduced or copied without written permission from ABB Oy,
and the contents thereof must not be imparted to a third party nor used for any unauthorized purpose.
The software or hardware described in this document is furnished under a license and may be used, copied, or
disclosed only in accordance with the terms of such license.
Copyright 2015 ABB Oy
All rights reserved.
Trademarks
ABB is a registered trademark of ABB Group. All other brand or product names mentioned in this document
may be trademarks or registered trademarks of their respective holders.
Contact information
ABB Oy, Medium Voltage Products
P.O.Box 699
Visiting address: Muottitie 2A
FI-65101 Vaasa, FINLAND
Phone: +358 10 22 11
Fax: +358 10 22 41094
www.abb.com/substationautomation

M2M WirelessGW ConfigurationGuide 758449 Ena

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

M2M WirelessGW ConfigurationGuide 758449 Ena

Încărcat de

Drepturi de autor:

Formate disponibile

1MRS758449 EN

ABB Oy, Medium Voltage Products

Issued: Nov 2015

3G/LTE Configuration Guide

Installation workflow .......................................................................................... 9

Configuring the installation computer ............................................................ 12

Cabling the field devices ................................................................................... 15

Cabling the M2M Gateway............................................................................... 18

Configuring the M2M Gateway ....................................................................... 21

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Wireless Gateways/Controllers LANs ........................................... 21

Configuring the Wireless Gateway/Controller ............................................... 28

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

SNMP agent .................................................................................... 66

3G/LTE Wireless Gateways/Controllers Configuration Guide

Importing the client identity .......................................................... 108

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

The following documents are available.

Identifying the products

Dual SIM models

Fig. 2.4.1-1 Dual SIM Wireless Gateway

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Fig. 2.4.2-1 Single SIM Lite model

Full product name

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Fig. 3-1 The installation workflow

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

The devices; Wireless Gateways/Controllers and M2M Gateway

SIM cards (with cellular data service enabled)

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

DIN rail mounting kits, if needed

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Configuring the installation computer

Fig. 4-1 Network connections

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Fig. 4-2 TCP/IP protocol properties

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Fig. 4-3 Changing the IP address

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Cabling the field devices

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Copyright 2015 ABB Oy, Medium Voltage Products, Vaasa, FINLAND

3G/LTE Wireless Gateways/Controllers Configuration Guide

Push the button

Fig. 5.7-1 SIM eject button

Fig. 5.7-2 SIM card and holder

SIM CARD CRADLE

Fig. 5.7-3 Rails for SIM card holder