RACOM s.r.o. | Mirova 1283 | 592 31 Nove Mesto na Morave | Czech Republic
Tel.: +420 722 937 522 | E -mail: racom@racom.eu
.
M!DGE2
GPRS/UMTS/HSPA+/LTE
router
.
fw 4.2.x.x
6/11/2019
version 1.2
Page 2
Page 3
Table of Contents
Important Notice .................................................................................................................................. 5
Getting started ..................................................................................................................................... 6
A. Glossary ...................................................................................................................................... 184
Index ................................................................................................................................................ 186
B. Revision History .......................................................................................................................... 189
Although every precaution has been taken in preparing this information, RACOM assumes no liability
for errors and omissions, or any damages resulting from the use of this information. This document or
the equipment may be modified without notice, in the interests of improving the product.
Trademark
All trademarks and product names are the property of their respective owners.
Important Notice
• Due to the nature of wireless communications, transmission and reception of data can never be
guaranteed. Data may be delayed, corrupted (i.e. have errors), or be totally lost. Significant delays
or losses of data are rare when wireless devices such as the M!DGE are used in an appropriate
manner within a well‐constructed network. M!DGE should not be used in situations where failure to
transmit or receive data could result in damage of any kind to the user or any other party, including
but not limited to personal injury, death, or loss of property. RACOM accepts no liability for damages
of any kind resulting from delays or errors in data transmitted or received using M!DGE, or for the
failure of M!DGE to transmit or receive such data.
• Under no circumstances is RACOM or any other company or person responsible for incidental, accidental or related damage arising as a result of the use of this product. RACOM does not provide the
user with any form of guarantee containing assurance of the suitability and fit for purpose.
• RACOM products are not developed, designed or tested for use in applications which may directly
affect health and/or life functions of humans or animals, nor to be a component of similarly important
systems, and RACOM does not provide any guarantee when company products are used in such
applications.
M!DGE Wireless Router will only operate reliably over the cellular network if there is a strong signal.
For many applications a flexible stub antenna would be suitable but in some circumstances it may be
necessary to use a remote antenna with an extension cable to allow the antenna itself to be positioned
so as to provide the best possible signal reception.
1. Install the SIM card
Insert a SIM card into the SIM socket. Make sure the SIM is enabled for data transmission.
2. Connect and fit the cellular antenna
If needed, contact RACOM for suitable antennas and other details.
3. Connect the LAN cable
Connect one M!DGE Ethernet port to your computer using an Ethernet cat.5 cable.
4. Connect the power supply
Connect the power supply wires to the M!DGE screw terminals, ensuring correct polarity. Switch
on the power supply.
5. Setting of IP address of the connected computer
By default the DHCP server is enabled, thus you can allow the Dynamic Host Configuration Protocol
(DHCP) on your computer to lease an IP address from the M!DGE. Wait approximately 20 seconds
until your computer has received the parameters (IP address, subnet mask, default gateway, DNS
server).
As an alternative you can configure a static IP address on your PC (e.g. 192.168.1.2/24) so that it
is operating in the same subnet as the M!DGE. The M!DGE default IP address for the first Ethernet
interface is 192.168.1.1, the subnet mask is 255.255.255.0.
6. Start setting up using a web browser
Open a web browser such as Internet Explorer or Firefox. In the address field of the web browser,
enter default IP address of M!DGE (i.e. http://192.168.1.1); initial screen will appear. Follow the instructions and use the M!DGE Web Manager to configure the device.
Fig. 1: Cellular router M!DGE
Note
M!DGE can be safely turned off by unplugging the power supply.
Although M!DGE wireless routers have been specifically designed for SCADA and telemetry, they are
well suited to a variety of wireless applications. M!DGE HW and SW are ready to maintain reliable and
secure connections from a virtually unlimited number of remote locations to a central server. Both
standard Ethernet/IP and serial interfaces are available. Moreover, a digital input and a digital output
can be used for direct monitoring and control of application devices; the second DI and DO are available
using an extension module.
M!DGE versatility is further enhanced by four independent Ethernet ports. These can be configured to
either support independent LANs (e.g. LAN and WAN settings), or simply connect up to four devices
within one LAN (effectively replacing an Eth switch). M!DGE software is based on proven components,
including an Embedded Linux operating system and standard TCP/IP communication protocols.
Thanks to the compact size and versatility of M!DGE, wireless routers prove indispensable in many
SCADA and telemetry, as well as POS, ATM, lottery and security/surveillance applications.
M!DGE together with RACOM RipEX radio router offers an unrivalled solution for combining cellular
and UHF/VHF licensed radios in a single network.
1.2. Key features
Mobile Interface Parameters
• Mobile Connection options: LTE, HSPA+, HSDPA, HSUPA, UMTS, EDGE, GPRS and GSM
EN 62368-1:2014Safety / Health
EN 62311:2008
EN 55032:2015EMC
EN 55035:2017
EN 61000-6-2:2016
EN 61000-6-3:2007+A1:2011+AC:2012
EN 301 489-1 V2.1.1
EN 301 489-3 V2.1.1
EN 301 489-7 V1.3.1
EN 301 489-17 V3.2.0
EN 301 489-24 V1.5.1
EN 301 489-52 V1.1.1
EN 300 328 V2.1.1RF Spectrum
EN 301 511 V9.0.2
EN 301 908-1 V11.1.1
EN 301 908-2 V11.1.1
EN 301 908-13 V11.1.1
○ SDK
○ NTP Server
○ DHCP Server
○ DNS Server
○ Dynamic DNS Client
○ E-mail Client
○ Notification via E-mail and SMS
○ SMS Client
○ SSH/Telnet Server
○ SNMP Agent
○ Web Server
○ Redundancy
○ Modbus TCP
○ Discovery
○ Terminal server
○ LXC containers
•
System Administration (Section 7.7, “SYSTEM”)
○ Configuration via Web Manager
○ Configuration via Command Line Interface (CLI) accessible via Secure Shell (SSH) and telnet
○ Batch configuration with text files
○ User administration
○ Troubleshooting tools
○ Over the air software update
○ Licensing (extra features)
○ Keys and certificates (HTTPS, SSH, OpenVPN, ...)
○ Legal Notice
SCADA equipment with an Ethernet protocol behaves as standard Ethernet equipment from a communications perspective. Thus the communication goes transparently through the cellular network. The
implementation requires heightened caution to IP addressing and routing. NAPT functionality should
be used frequently.
3.2. Serial SCADA protocols
A SCADA serial protocol typically uses simple 8 or 16 bit addressing. The mobile network address
scheme is an IP network, where range is defined by the service provider (sometimes including individual
addresses, even in the case of a private APN). Consequently, a mechanism of translation between
SCADA and the IP addresses is required. To make matters worse, IP addresses may be assigned to
GPRS (EDGE, UMTS, etc.) devices dynamically upon each connection.
Please read application note "M!DGE/MG102i - Serial SCADA Protocols"1which describes how to efficiently solve this problem using RACOM routers.
3.3. Network center
In every network, the center plays a key role and has to be designed according to customer's requirements. Several possible solutions are described in the application note "M!DGE/MG102i - Typical us-
age"2.
3.4. VPN tunnels
Customer data security arriving through the mobile network is often very important. Private APN is the
basic security requirement, but not safe enough for such applications.
VPN tunnels solution is closely connected with the center and is also described in application note
The M!DGE router is equipped with two antenna connectors. The ANT connector serves as a main
antenna connection, the AUX connector is auxiliary and serves for better communication with BTS
(diversity).
The M!DGE router is equipped with two MicroSIM (3FF) cards slots which are placed under a SIM card
cover. Use PH0 screw driver for its opening. If using only one SIM card, use holder one.
The SIM card holder has a locking mechanism - for opening pull the front part of the holder down and
then you can open it. After inserting of SIM card (cropped edge left, connectors down), close the
holder and lock it.
Important
Power off the rourter before inserting the SIM card.
4.2.5. Screw terminal
Screw terminal plug type Stelvio Kontek CPF5/15 or MRT3P/15V01 can be used.
Fig. 4.5: Screw terminal
Screw terminal plug types:
Phoenix Contact 1847204 (MC 1.5/10-STF-3.5) for 10 pins plug and
Phoenix Contact 1847181 (MC 1.5/ 8-STF-3.5) for 8 pins plug (or equivalent).
This EXT plug is delivered only for units equipped with internal extension module.
Tab. 4.5: Screw terminal pin assignment
signalpin descriptionpin
Power input plus: 12–24 VDC (−20% +20 %) = 9.6–28.8 VDC12-24 VDC +1
Power input minus – internally connected with casing12-24 VDC -2
RS-232 GND (non-isolated)RS232 GND3
RS-232 RxD (non-isolated)RS232 RxD4
RS-232 TxD (non-isolated)RS232 TxD5
Digital input - Negative signal input (isolated to GND)DI -6
Digital input - Positive signal input (isolated to GND)DI +7
Digital Output isolated, Relay contact normally openDO NO8
Digital Output isolated, Relay commonDO COM9
Digital Output isolated, Relay contact normally closedDO NC10
Tab. 4.6: Digital input levels
0 to 3 VDClogical level 0
9 to 32 VDClogical level 1
Note: Negative input voltage is not recognised.
Tab. 4.7: Digital output parameters
1 AMaximal continuous current
32 VDCMaximal switching voltage
32 WMaximal switching capacity
Tab. 4.8: Voltage Polarity connector misconnection Risks
[1] - If the applied voltage is > 15 V, damage is likely
[2] - If the relay is closed (normally open), the relay is damaged when current > 5 A
[3] - If the relay is closed (normally closed), the relay is damaged when current > 5 A
[4] - If the applied voltage is > 40 V, input circuit damage is likely
4.2.6. Reset button
The Reset button is placed close to the USB connector. Use a blunt tool
no more than 1 mm in diameter (e.g. a paper clip) to press the button.
The reset button has two functions:
• Reboot the system
○ Press at least 3 seconds to release a system reboot.
○ The reboot is indicated with the red blinking STAT LED.
+
Nde [4]
−+DI2+15
• Factory reset
○ Press at least 10 seconds to release a factory reset.
○ The start of the factory reset is confirmed by all LEDs lighting up
GREEN for a second.
• Recovery procedure
○ Press at least 15 seconds to release a recovery procedure.
○ The start of the recovery procedure is confirmed by all LEDs lighting up RED for a second.
Note
Contact our technical support (support@racom.eu) for recovery procedure details and required
files.
The following table describes the default M!DGE status indicators.
Tab. 4.9: M!DGE interfaces and status indicators
STAT
WANHotlink connection is being establishedblinking
LAN
VPNVPN connection is being establishedgreen blinking
on / off / blinkingEXT
SYS
Device busy device is in startup, software- or configuration updategreen blinking
Device is readygreen on
Hotlink is disabledoff
Hotlink connection is upon
ETH: enabled as LAN and link status is upgreen
No ETH LAN-connection is upoff
VPN connection is upgreen on
VPN connection downoff
EXT LED indicates the state of the extension interfaces.
Hint: Cellular (WWAN) signal strength can be indicated (green =
excellent, orange = medium, red = weak).
Shows the overall system state. This could be derived from health
indicators such as:
- all services up and running
- overall throughput is normal
- CPU load is normal
- the supervisor
- User application (state set by user in SDK or LXC)
FunctionStateDescription
System operation state: normalgreen on
System operation state: warning or in a transitiongreen blinking
System operation state: emergency, watchdog, failurered on
Relay outputs
Limiting continuous current 1 A
Max. switching voltage 32 VDC
Max. switching capacity 32 W
Isolation 1500 Vp (transients)
USB service
interface
Antenna
Interface
Power Supply
Environmental
Conditions
USB host interface supporting memory devices
USB type A connector USB2.0
2× micro SIM (3FF)SIM
50 ΩImpedance:
2× SMA female supporting MIMOConnector:
9.6–28.8 VDC (12–24 VDC −20 % / +20 %)Input voltage:
7 W (including max. 2.5 W on USB port)Avg. power
consumption:
For indoor use only, IP40
Metal casing, DIN rail mounting kit included
−40 to +70 °C (−40 to +158 °F)Temperature range:
0 to 95 % (non condensing)Humidity:
> 220.000 hours (> 25 years)MTBF (Mean Time Between Failure)
IOvervoltage Category:
2Pollution Degree:
• Trade name – trade and marketing name of the product. This name is used for the all products
within the same product family.
Possible values: M!DGE
• Gen. – generation of the product of specific Trade name. The very first generation doesn’t have any
number in this position.
Possible values: none, 2
•
Bands – frequency bands
Possible values: E, P, A, U
E – 4G/3G/2G, Europe, Middle East, Africa
P – 4G/3G/2G, Asia, Pacific, South America
A – 4G/3G/2G, Americas
U – only 3G/2G, world wide
Note: ‘P’ and ‘A’ are available for high volumes only
• Slot – Proprietary extension slot
Possible values:
N – not used
C – The second RS232/485 + 1×DI,1×DO, Part No.: M!DGE2-HW-COM/IO
signalpin description
RS-232 GND (non-isolated)1
RS-232 RxD (non-isolated); RS485 A (Half-Duplex)2
RS-232 TxD (non-isolated); RS485 B (Half-Duplex)3
Digital input - Negative signal input (isolated to GND)4
• mPCIe – mPCIe slot
Digital input - Positive signal input (isolated to GND)5
Digital Output isolated, Relay contact normally opened6
Digital Output isolated, Relay common7
Digital Output isolated, Relay contact normally closed8
Possible values:
N – not used
E – The second cellular module, Bands E, Part No.: mPCIe-E
P – The second cellular module, Bands P, Part No.: mPCIe-P
A – The second cellular module, Bands A, Part No.: mPCIe-A
U – The second cellular module, Bands U, Part No.: mPCIe-U
G – Internal GPS (GNSS) module, Part No.: mPCIe-GPS
Note: just one option for mPCIe slot is possible
• Bands, Slot, mPCIe positions are used only for M!DGE2.
• SW keys – if unit is ordered with SW keys, all keys are specified in this bracket. SW key activates
the feature, which is under the license. SW key can be ordered independently for specific S/N anytime
later on.
Possible values M!DGE2:
LXC – Linux container, Part No.: M!DGE2-SW-LXC
SERVER – Server clients extension, Part No.: M!DGE2-SW-SERVER
M!DGE2GPRS/EDGE/UMTS/HSPA+/LTE router, 4× Eth, 1× RS232, 1× DI, 1× DO
DIN rail holder included
HW optional module
The HW optional module has to be added into the M!DGE router in the factory.
COM/IOExtension with 1× RS232/RS485 + 1× DI + 1× DO
Tab. 4.11: Pin Assignments of COM/IO module
signalpin description
RS-232 GND (non-isolated)1
RS-232 RxD (non-isolated); RS485 A (Half-Duplex)2
RS-232 TxD (non-isolated); RS485 B (Half-Duplex)3
Digital input - Negative signal input (isolated to GND)4
Digital input - Positive signal input (isolated to GND)5
Digital Output isolated, Relay contact normally opened6
Digital Output isolated, Relay common7
Digital Output isolated, Relay contact normally closed8
SW feature keys
The SW feature key should be added to a new or running system via adding a license: menu SYSTEM
– Licensing (see Section 7.7.7, “Licensing”).
LXC VirtualizationLinux container LXC
Server LicenceEnlargement of feature items count - see table below
Before starting to work with the HW please be sure that you have a SIM card enabled for data and you
have all the necessary information from the mobile operator (PIN, APN, login, passwd)
5.1. Connecting the hardware
5.1.1. Install the SIM card
Insert a SIM card into the SIM socket, use the first one. Make sure the SIM is enabled for data transmission.
There are two reasons for installing the SIM card as the first task: a) the SIM card could be damaged
when inserted into the powered equipment, b) the information from SIM card are read only after a power
cycle.
5.1.2. Connect the cellular antenna
Fit a cellular antenna. For details see RACOM web1or contact RACOM for suitable antennas.
5.1.3. Connect the LAN cable
Connect one M!DGE Ethernet port to your computer using an Eth cat.5 cable.
5.1.4. Connect the power supply
Connect the power supply wires to the M!DGE screw terminals, ensuring correct polarity. Switch on
the power supply.
5.2. Powering up your wireless router
Switch on your power supply. The STAT LED flashes for a few seconds and after 8 seconds it starts
blinking to a green light. After approximately 30 seconds your router will have booted and will be ready;
the STAT LED remains shining.
When the Mobile Connection is enabled the WAN LED starts blinking while connecting to the cellular
network – the color (green/orange/red) represents the signal strength (excellent, medium, weak).
You’ll find the description of the individual LED states in Section 4.3, “Indication LEDs”.
5.3. Connecting M!DGE to a programming PC
a. Please connect the Ethernet interfaces of your computer and M!DGE.
b. If not yet enabled, please enable the Dynamic Host Configuration Protocol (DHCP) so that your
computer can lease an IP address from M!DGE. Wait a moment until your PC has received the
parameters (IP address, subnet mask, default gateway, DNS server).
Alternative: Instead of using the DHCP, configure a static IP address on your PC (e.g.
192.168.1.10 mask 255.255.255.0) so that it is operating in the same subnet as the M!DGE.
The default IP address is 192.168.1.1 for all Eth interfaces (Eth1 - Eth4), the default subnet mask
is 255.255.255.0 for all interfaces.
Default DHCP range 192.168.1.100 to 192.168.1.199
c. Start a Web Browser on your PC. Type the M!DGE IP address in the address bar:
http://192.168.1.1
d. Please set a password for the admin user account. Choose something that is both easy to remember
and a strong password (such as one that contains numbers, letters and punctuation). The password
must have a minimum length of 6 characters. It must contain a minimum of 2 numbers and 2 letters.
Note
For security reasons, there is no default password.
e. Agree to the terms and conditions. The user is now obliged to accept our end user license agreement
during the initial M!DGE setup.
f.You might check the "Configure automatic mobile data connection" for automatic WWAN configur-
ation. Manual changes are usually required afterwards. Note that Firewall is also enabled with
predefined WAN administration ports.
5.4. Basic setup
The M!DGE Web Manager can always be reached via the Ethernet interface. After successful setup,
Web Manager can also be accessed via the mobile interface. Any up to date web browser can be used.
Any web browser supporting JavaScript can be used. By default, the IP address of the 1st Ethernet
interface is 192.168.1.1, the web server runs on port 80.
The minimum configuration steps include:
1. Defining the admin password
2. Entering the PIN code for the SIM card
3. Configuring the Access Point Name (APN)
4. Starting the mobile connection
Note
Router M!DGE can be safely turned off by unplugging the power supply.
M!DGE Wireless Router is designed for a DIN rail mounting or on a panel using flat bracket. Please
consider the safety instructions in Section 6.1, “Mounting”.
6.2. Antenna mounting
M!DGE Wireless Routers will only operate reliably over the cellular network if there is a strong signal.
For many applications the flexible stub antenna provided would be suitable but in some circumstances
it may be necessary to use a remote antenna with an extended cable to allow the antenna itself to be
positioned so as to provide the best possible signal reception.
Beware of the deflective effects caused by large metal surfaces (elevators, machine housings, etc.),
close meshed iron constructions and choose the antenna location accordingly. Fit the antenna or
connect the antenna cable to the ANT connector.
In external antennas the surge protection of coaxial connection would be required.
Note
Be sure that the antenna was installed according to the recommendation by the antenna producer and all parts of the antenna and antenna holder are properly fastened.
6.3. Power supply
M!DGE can be powered with an external power source capable of voltages from 9.6 to 28.8 Volts DC.
M!DGE should be powered using a certified (CSA or equivalent) power supply, which must have a
limited and SELV circuit output.
This page gives you a system overview. It helps you when initially setting up the device and also
functions as a dashboard during normal operation.
The highest priority link which has been established successfully will become the so-called hotlink
which holds the default route for outgoing packets.
Detailed information about status of each WAN interface is available in a separate window.
Details for all physical connections are given in Section 4.2, “Connectors”.
7.2.1. WAN
Link Management
Each available item in the WAN Link Manager matches with the particular WAN interface. Depending
on your hardware model, WAN links can be made up of either Wireless Wide Area Network (WWAN),
Wireless LAN (WLAN), Ethernet or PPP over Ethernet (PPPoE) connections. Please note that each
WAN link has to be configured and enabled in order to appear on this page.
In case a WAN link goes down, the system will automatically switch over to the next link in order of
priority (the priorities can be changed using the arrows on the right side of the window). A link can be
either established when the switch occurs or permanently to minimize link downtime.
1st priority:This link will be used whenever possible.
Links are being triggered periodically and put to sleep in case it was not possible to establish them
within a certain amount of time. Hence it might happen that permanent links will be dialed in background
and replace links with lower priority again as soon as they got established. In case of interfering links
sharing the same resources (for instance in dual-SIM operation) you may define a switch-back interval
after which an active hotlink is forced to go down in order to let the higher-prio link getting dialed again.
Bridge interface:If WAN is configured as WLAN client, the LAN interface to which the WAN
link should be bridged.
Outgoing traffic can also be distributed over multiple links on a per IP session basis. Choose the option
"distributed" as an Operation Mode with the appropriate Weight.
In the following example, the outgoing traffic will be distributed between LAN2 (80 %) and WWAN1
(20 %) links.
Note
This option is general and applies to all outgoing traffic. See Section 7.3.3, “Multipath Routes”
for more detailed configuration.
We recommend using the permanent option for WAN links. However, in case of time-limited mobile
tariffs, the switchover option should be used.
After clicking on the WWAN "Edit" button, you can additionally set the "IP passthrough" option for the
selected LAN interface. The result is that the connected device over the selected LAN port will obtain
M!DGE's mobile IP address via DHCP. In another words, M!DGE will be transparent for the connected
device and will only serve for the mobile connectivity. Typically, such connected device (e.g. firewall)
will not need any special configuration facing M!DGE, it will just use its mobile IP address (usually the
public IP address).
Once established, a small subnet containing the cellular IP is created, by default the netmask is
255.255.255.248. This small subnet consists of a network and broadcast address as a regular subnet.
In some situations it may lead to unreachability of several remote hosts due to IP address overlapping.
If this is the case, user can manually configure the APN network, e.g. 10.203.0.0/255.255.128.0.
In any case, the M!DGE unit is reachable via the default gateway automatically obtained from M!DGE
by DHCP. The gateway IP address is set as the first available IP address after the specified APN address
range. If not specified, it is the first usable IP within the /29 subnet.
Note
We recommend to define the APN network/netmask manually. There might be situations in
which the default /29 disables the communication. E.g. WWAN IP is 10.10.10.6. The connected
device obtaines this IP via DHCP and sets the default gateway to 10.10.10.7 - but this IP is a
broadcast IP within /29 subnet and the communication is not possible. If you configure subnet
10.10.10.0/29 manually, a default gateway would be 10.10.10.8 in newly created local /28
subnet.
Example: If the APN network is 10.203.0.0/17, the default gateway is set to 10.203.128.0. The web
interface is reachable via this IP address over the selected LAN interface. The connected device's
network mask is /16 (1 bit wider), otherwise the default gateway would not be usable.
Note
This option is configurable within WWAN links only. Remember that LAN1 cannot be used
•
as the port for the IP passthrough functionality.
• LAN10 is not usable within M!DGE routers. Do not select it.
Network outage detection can be used for switching between available WAN links and can be performed
by sending pings on each link to authoritative hosts. A link will be declared as down if all trials have
failed. The link will be considered up again if at least one host is reachable.
You may further specify an emergency action if no uplink can be established at all.
Link:The WAN link to be monitored (can be ANY for all configured links).
Mode:Specifies whether the link is monitored during the connection estab-
lishment or only when it is already up.
Primary host:Reference host one which will be used for checking IP connectivity
(via ICMP pings).
Secondary host:Reference host two which will be used for checking IP connectivity
(via ICMP pings). The test is considered successful if either the
primary or the secondary host answers.
Ping timeout:Time for which the system is waiting for the ping response. With
mobile networks the response time can be quite long (several
seconds) in special cases. You can check the typical response using
SYSTEM – Troubleshooting – Network Debugging – Ping. The first
response typically takes a longer time than the following ones in
cellular networks, the Ping timeout should be set to the longer time
than with the first response.
Ping interval:Time to wait before sending the next probe.
Retry interval (if ping failed):If the first trial fails, ping hosts in this modified interval until the ping
is successful or the maximum number of failed trials is reached.
Max. number of failed trials:The maximum number of failed ping trials until the ping check will
be declared as failed.
Emergency action:Configure the Emergency action which should be taken after the
maximum downtime is reached. Using "reboot" performs the system
reboot. The option "restart services" restarts all link-related applications including the modem reset. No action is done if the "none"
option is set. Configure the maximum amount of downtime in minutes
for which the link could not be established.
Settings
The maximum segment size defines the largest amount of data of TCP packets (usually MTU minus
40). You may decrease the value in case of fragmentation issues or link-based limits.
MSS adjustmentEnable or disable MSS adjustment on WAN interfaces.
Maximum segment sizeMaximum number of bytes in a TCP data segment.
7.2.2. Ethernet
M!DGE routers ship with 4 dedicated Ethernet ports (ETH1 to ETH4) which can be linked via RJ45
connectors.
ETH1 usually forms the LAN1 interface which should be used for LAN purposes. Other interfaces can
be used to connect other LAN segments or for configuring a WAN link. The LAN10 interface will be
available as soon as a pre-configured USB Ethernet device has been plugged in (e.g. XA Ethernet/USB
adapter).
Port Setup - Port Assignment
This menu can be used to individual assigning of Ethernet ports to LAN interfaces if you want to have
different subnets per port or to use one port as the WAN inteface.
If it is desired to have both ports in the same LAN you may assign them to the same interface. Please
note that the ports will be bridged by software and operated by running the Spanning Tree Protocol.
Link negotiation can be set for each Ethernet port individually. Most devices support auto negotiation
which will configure the link speed automatically to comply with other devices in the network. In case
of negotiation problems, you may assign the modes manually but it has to be ensured that all devices
in the network utilize the same settings then.
M!DGE routers support Virtual LAN according to IEEE 802.1Q which can be used to create virtual interfaces on top of the Ethernet interface. The VLAN protocol inserts an additional header to Ethernet
frames carrying a VLAN Identifier (VLAN ID) which is used for distributing the packets to the associated
virtual interface. Any untagged packets, as well as packets with an unassigned ID, will be distributed
to the native interface. In order to form a distinctive subnet, the network interface of a remote LAN host
must be configured with the same VLAN ID as defined on the router. Further, 802.1P introduces a priority field which influences packet scheduling in the TCP/IP stack.
The following priority levels (from the lowest to the highest) exist:
VLAN Priority LevelsParameter
Background0
Best Effort1
Excellent Effort2
Critical Applications3
Video (< 100 ms latency and jitter)4
Voice (< 10 ms latency and jitter)5
Internetwork Control6
Network Control7
IP Settings
Two individual tabs will be used when different LANs are set in the Port settings menu. Each of them
can be configured either in the LAN mode or in the WAN mode.
Static configuration of M!DGE's own IP address and Subnet mask is available for the LAN mode. The
Alias IP address enables configuring the LAN interface with a second IP address/subnet.
MTUConfigure MTU of a given Ethernet interface.
Note
Setting of the IP address is interconnected with the DHCP Server (if enabled) - menu the
SERVICES - DHCP Server menu.
This page lists all available WWAN modems. They can be disabled on demand.
Query
This page allows you to send Hayes AT commands to the modem. Besides the 3GPP-conforming AT
command-set, further modem-specific commands can be applied (can be provided on demand). Some
modems also support running Unstructured Supplementary Service Data (USSD) requests, e.g. for
querying the available balance of a prepaid account.
SIMs
The SIM page gives an overview about the available SIM cards, their assigned modems and the current
state. Once a SIM card has been inserted, assigned to a modem and successfully unlocked, the card
should remain in state ready and the network registration status should have turned to registered. If
not, please double-check your PIN.
Please keep in mind that registering to a network usually takes some time and depends on signal
strength and possible radio interferences. You may hit the Update button at any time in order to restart
PIN unlocking and trigger another network registration attempt.
Under some circumstances (e.g. in case the modem flaps between base stations) it might be necessary
to set a specific service type or assign a fixed operator. The list of operators around can be obtained
by initiating a network scan (may take up to 60 seconds). Further details can be retrieved by querying
the modem directly, a set of suitable commands can be provided on request.
Configuration
A SIM card is generally assigned to a default modem but this may switch, for instance if you set up two
WWAN interfaces with one modem but different SIM cards. Close attention has to be paid when other
services (such as SMS or Voice) are operating on that modem as a SIM switch will affect their operation.
PIN protectionDepending on the used card, it can be necessary to unlock the SIM with a
PIN code. Please check the account details associated with your SIM
whether the PIN protection is enabled.
PIN codeThe PIN code for unlocking the SIM card
PUK codeThe PUK code for unlocking the SIM card if the card was blocked due to
several wrong PIN attempts.
Default modemThe default modem assigned to this SIM card.
BandsThe list of allowed bands to which the unit can connect. Current ublox module
does not support manual band selection.
Preferred serviceThe preferred service type to be used with this SIM card. Remember that the
link manager might change this in case of different settings. The default option
is "automatic", in areas with interfering base stations you can force a specific
type (e.g. 3G-only) in order to prevent any flapping between the stations
around.
Registration modeThe default option is set to "all networks". You can limit the modem registration
to "packet-switched only" (e.g. no Dial-in Server) or "circuit-switched only"
option, which can be for example used for the Dial-in Server so one can use
PPP over the Circuit-Switched Networks (analog modem style).
Network selectionLAI is a globally unique number that identifies the country, network provider
and LAC of any given location area. It can be used to force the modem to
register to a particular mobile cell in case of competing stations.
You may further initiate mobile network scan for getting networks in range
and assign a LAI manually.
This page can be used to manage your WWAN interfaces. The resulting link will pop up automatically
on the WAN Link Management page once an interface has been added. The Mobile LED will be
blinking during the connection establishment process and goes on as soon as the connection is up.
Refer to the troubleshooting section or log files in case the connection did not come up.
The following mobile settings are required:
ModemThe modem to be used for this WWAN interface
SIMThe SIM card to be used for this WWAN interface
Preferred serviceThe preferred service type
Please note that these settings supersede the general SIM based settings as soon as the link is being
dialed.
Generally, the connection settings are derived automatically as soon as the modem has been registered
and the network provider has been found in our database. Otherwise, it will be required to configure
the following settings:
Phone numberThe phone number to be dialed, for 3G+ connections this commonly refers
to be *99***1#. For circuit switched 2G connections you can enter the fixed
phone number to be dialed in the international format (e.g. +420xx).
Access point nameThe access point name (APN) being used
Enable or disable the USB administration. If enabled, any supported USB converter can be attached
and configured for example as another serial link (RS232, see Section 7.2.6, “Serial Port”).
Note
Supported modules are pl2303, ch341, ftdi (quad-channel adapter), asix, pegasus and rndis.
Following parameter can be configured:
• Enable hotplug (always enabled)
Click on the Refresh button in the tab Devices for displaying connected USB devices and add them
with by clicking on the plus sign.
Autorun
This feature can be used to automatically perform a software/config update as soon as an USB storage
stick has been plugged in. Following files must exist in the root directory of a FAT16/32 formatted stick:
• For authentication: autorun.key
• For a software update: sw-update.img
• For a configuration update: cfg-<SERIALNO>.zip or cfg.zip
Administrative statusEnable or disable autorun feature.
Only allow enabled devicesCheck this if only enabled devices are allowed to proceed with
autorun.
The autorun.key file must hold valid access keys to perform any actions when the storage device
is plugged in. The keys are made up of your admin password (SHA256). They can be generated and
downloaded. You may also define multiple keys in this file (line-after-line) in case your admin password
differs if applied to multiple M!DGE routers.
For new devices with an empty password the hash key
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 can be used.
The hash keys can be generated by running the command
echo -n "<admin-password>" | sha256sum on a Linux system or an Internet hash key generator (search
for "sha-256 hash calculator").
7.2.6. Serial Port
The serial protocol can function in various ways, configure it using the Edit button on the right. If the
USB Administration is enabled, an extra SERIAL2 (USB) is available.
Modem emulator enables replacement for legacy dial-in / dial-out connections based on analog or
GSM modems. M!DGE supports the Hayes AT Command set on the serial interface and behaves like
a regular router.
You can easily replace your old Modem with M!DGE. There is also no need to configure the attached
device as you can prepare the M!DGE accordingly.
Physical protocolRS232
Baud rateSpecifies the baud rate of the RS232 port.
Hardware flow controlWhile 3 wired connection is used with M!DGE hardware flow control is not
available.
PortAny incoming connection will be received on the Port configured. This Port
needs to be allowed, keep this in mind for Firewall configurations.
The Phonebook configuration will keep the aliases of any Phone numbers so that you do not need to
reconfigure your device and can use the original addressing scheme.
NumberRemote phone number.
IP addressRemote IP address.
PortRemote port number.
Note
More details in the Serial SCADA Protocols1application note.
The port settings configuration is the same as with the Device Server - the section called “Device
Server” except the Advanced settings called MTU and Idle size.
MTU
An incoming frame is closed at this size even if the stream of bytes continues. Consequently, a permanent data stream coming to the serial interface results in a sequence of MTU-sized frames sent over
the network. The default value is set to 1400 bytes.
Idle size
Received frames on COM are closed when the gap between bytes is longer than the Idle value. This
parameter defines the maximum gap (in milliseconds) in the received data stream. If the gap exceeds
this value, the link is considered idle, the received frame is closed and forwarded to the network.
The default Idle size differs based on the serial baud rate configuration. Remember that the default
Idle sizes are set to the minimal possible values:
Each SCADA protocol like Modbus, DNP3, IEC101, DF1 etc. has its unique message format, most
importantly its unique way of addressing the remote units. The following text is valid for all M!DGE/RipEX
units (further in this the section called “Protocol Server” referred to as a "Unit") - the special properties
for mobile cellular networks (e.g. limitation of broadcasting) are mentioned here. The basic task for the
protocol server is to check whether a received frame is within the protocol format and is not corrupted.
Most of the SCADA protocols are using some type of Error Detection Code (Checksum, CRC, LRC,
BCC, etc.) for data integrity control, so each Unit calculates this code and checks it against the received
one.
Cellular mobile network operates in IP environment, so the basic task for the Protocol server is to
convert SCADA serial packets to UDP datagrams. The Address translation settings are used to define
the destination IP address and UDP port. Then these UDP datagrams are sent to the M!DGE router,
processed there and are forwarded as unicasts through the mobile network to their destination. When
the gateway defined in the Routing table belongs to the Ethernet LAN, UDP datagrams are instead
forwarded to the Ethernet interface. After reaching the gateway, the datagram is forwarded according
to the Routing table.
When the UDP datagram reaches its final IP destination, it should be in a M!DGE or RipEX router
again. It is processed further according to its UDP port. It can be delivered to the Protocol server where
where the datagram is decapsulated and the data received on the serial interface of the source unit
are forwarded to COM. The UDP port can also be that of a Terminal server (RipEX) or any other special
protocol daemon on Ethernet like Modbus TCP etc. The datagram is then processed according to the
respective settings.
Note
All timeouts in the parameters described below are derived from the time when the packet is
sent into the COM driver, i.e. it includes the transfer time of the packet. Take this into account
especially when there is a low Baud rate set in the COM settings.
If configuring the Protocol server together with VPN tunnels the "Poll response control" protocol
specific parameter must be turned off.
Common parameters
Web Configuration
For any SCADA protocol, the Transport protocol and the specific port can be chosen. The default values
is UDP port 8882. The unit listens on this port for incoming messages and forwards them to the Protocol
server itself.
Note
Only UDP protocol is currently implemented.
The parameters described in this section are typical of most protocols.
There is only a link to them in description of the respective Protocol.
Mode of Connected device
List box: Master, Slave
Default = Master
The typical SCADA application follows the Master–Slave scheme where the structure of the message
is different for the Master and Slave SCADA units. Because of that, it is necessary to set which type
of SCADA unit is connected to the Unit.
Important
For the SCADA Master, set Master, for the SCADA Slave, set Slave.
• Master
The SCADA Master always sends addressed messages to Slaves. Addressing is different for each
SCADA protocol, so this is one of the main reasons why an individual Protocol server in each Unit
for each SCADA protocol has to be used.
○ Broadcast
List box: On, Off
Default = Off
Some Master SCADA units send broadcast messages to all Slave units. SCADA applications
typically use a specific address for such messages. RipEX (Protocol utility) converts such messages
into a customized IP broadcast and broadcasts it to all RipEX units resp. to all SCADA units within
the network.
Note
Broadcasts in the cellular network are not possible, thus setting of broadcast functionality
is not allowed with M!DGE units.
If On, the address for broadcast packets in the SCADA protocol has to be defined:
■ Broadcast address format - List box Hex, Dec - format in which the broadcast address is
defined.
■ Broadcast address - address in the defined format (Hex, Dec)
○ Address translation
List box: Table, Mask
Default = Mask
In a SCADA protocol, each SCADA unit has a unique address, a "Protocol address". In a cellular
mobile network, each SCADA unit is represented by an IP address (typically that of the ETH interface) and a UDP port (that of the protocol daemon or the COM port server to which the SCADA
device is connected via serial interface).
A translation between the "Protocol address" and the IP address & UDP port pair has to be done.
It can be done either via Table or Mask.
Hence, a SCADA message received from the serial interface is encapsulated into a UDP/IP datagram, where the destination IP address and the destination UDP port are defined according to the
settings of the Address translation.
■ Mask
Translation using the Mask is simpler to set, however it has some limitations:
− all IP addresses used have to be within the same network, which is defined by this Mask
−the same UDP port is used for all the SCADA units, which results in the following:
− SCADA devices on all sites have to be connected to the same interface
− only one SCADA device can be connected to one COM port
• Base IP
Default = IP address of the ETH interface
When creating the IP destination address of UDP datagram, in which the serial SCADA
message received from COM is encapsulated, this is created, this Base IP is taken as the
basis and only the part defined by the Mask is replaced by the 'Protocol address'.
• Mask
Default = 255.255.255.0
A part of the Base IP address defined by this Mask is replaced by the 'Protocol address'. The
SCADA protocol address is typically 1 byte, so Mask 255.255.255.0 is most frequently used.
• UDP port (Interface)
List box: COM, Manual
This UDP port is used as the destination UDP port in the UDP datagram in which the serial
SCADA packet received from COM1 is encapsulated. The default UDP port for COM can be
used or the UDP port can be set manually. If the destination IP address belongs to a Unit and
the UDP port is not assigned to COM (COM1(2) or to a Terminal server in case of RipEX) or
to any special daemon running in the destination address, the packet is discarded.
Note
M!DGE use UDP port 8882 for its COM port.
■ Table
The Address translation is defined in a table. There are no limitations such as when the Mask
translation is used. If there are more SCADA units on the RS485 (e.g. with RipEX COM2) their
interface, their “Protocol addresses” should be translated to the same IP address and UDP port
pair, where the multiple SCADA units are connected. There are 3 possibilities how to fill in the
line in the table:
− One "Protocol address" to one "IP address" (e.g.: 56 −−> 192.168.20.20)
− Range of "Protocol addresses" to one "IP address" (e.g.: 56 – 62 ===> 192.168.20.20)
− Range of "Protocol addresses" to range of "IP addresses" (e.g.: 56 – 62 ===> 192.168.20.20
– 26). One option is to write only the start IP and a dash, the system will add the end address
itself.
• Protocol address
This is the address which is used by the SCADA protocol. It may be set either in Hexadecimal
or Decimal format according to the List box value.
Protocol address length can be 1 byte, but for the DNP3 and UNI protocols support 2 bytes
addresses.
• IP
The IP address to which Protocol address will be translated. This IP address is used as the
destination IP address in the UDP datagram in which serial SCADA packet received from
COM is encapsulated.
• UDP port (Interface)
This is the UDP port number which is used as the destination UDP port in the UDP datagram
in which the serial SCADA message, received from COM, is encapsulated.
• Note
You may add a note to each address up to 16 characters long for your convenience. (E.g.
“Remote unit #1”).
• Active
You may tick/un-tick each translation line in order to make it active/not active.
• Modify
Edit, Delete Add buttons allow to edit or to add or to delete a line. The lines can be sorted
using up and down arrows.
• Slave
The SCADA Slave typically only responds to Master requests, however in some SCADA protocols
it can communicate spontaneously.
Messages from the serial interface are processed in a similar way as the Master site, i.e. they are
encapsulated in UDP datagrams, processed by the router inside the M!DGE unit and forwarded to
the respective interface, typically to the mobile network.
○ Broadcast accept
List box: On, Off
Default = Off
If On, broadcast messages from the Master SCADA device to all Slave units are accepted and
sent to connected Slave SCADA unit.
Broadcasting is not supported with mobile networks.
PROTOCOLS IMPLEMENTED:
Within several protocols, parameter "Poll response control" can be set. Turn it off if using any kind of
port forwarding or VPN tunnels. Otherwise, it can be set to "On". More details about this parameter
can be found at UNI protocol description.
None
All received frames from the COM port as well as from the network are discarded.
Async link
The async link creates asynchronous link between two COM ports on different Units. Received frames
from COM are sent without any processing transparently to the mobile network to set the IP destination
and UDP port. Received frames from the mobile network are sent to the respective COM according to
the UDP port setting.
• Parameters
○ Destination IP
This is the IP address of the destination Unit.
○ UDP port (Interface)
This is the UDP port number which is used as the destination UDP port in the UDP datagram in
which the packet received from COM is encapsulated.
C24
C24 is a serial polling-type communication protocol used in Master–Slave applications.
Multiple C24 Masters can be used within one network and one Slave can be polled by more than one
Master.
Italicised parameters are described in Common parameters.
Mode of Connected device
Master
Address translation
Table
Mask
Slave
• Protocol frames
List box: 1C, 2C, 3C, 4C
Default = 1C
One of the possible C24 Protocol frames can be selected.
• Frames format
List box: Format1, Format2, Format3, Format4, Format5
Default = Format1
One of the possible C24 Frames formats can be selected. According to the C24 protocol specification,
it is possible to set Frames formats 1–4 for Protocol frames 1C–3C and formats 1–5 for 4C.
Important
The Unit accepts only the set Protocol frames and Frames format combination. All other
combinations frames are discarded by the Unit and not passed to the application.
• Local ACK
List box: Off, On
Default = Off
Available for Protocol frame 1C only. When On, ACK on COM is send locally from this unit, not over
the mobile network.
Cactus
Cactus is a serial polling-type communication protocol used in Master–Slave applications.
Multiple Cactus Masters can be used within one network and one Slave can be polled by more than
one Master.
Italicised parameters are described in Common parameters.
Mode of Connected device
Master
Broadcast
Note: There is no the possibility to set Broadcast address, since
Cactus broadcast messages always have the address 0x00. Hence
when the Broadcast is On, packets with this destination are handled
as broadcasts. Broadcasting is not supported with mobile networks.
Address translation
Table
Mask
Slave
Broadcast accept
• Max gap timeout [ms]
Default = 30
The longest time gap for which a frame can be interrupted and still received successfully as one
frame. It should not be set below 10ms, while 15–40 ms should be OK for a typical Cactus protocol
device.
Comli
Comli is a serial polling-type communication protocol used by Master–Slave applications.
More Comli Masters can be used within one network and one Slave can be polled by more Masters.
Broadcasts packets are not used, so the configuration is using only some parameters described in
Only the full-duplex mode of DF1 is supported. Each frame in the Allen-Bradley DF1 protocol contains
the source and destination addresses in its header, so there is no difference between Master and Slave
in the full-duplex mode in terms of Unit configuration.
• Block control mode
List box: BCC, CRC
Default = BCC
According to the DF1 specification, either BCC or CRC for Block control mode (data integrity) can
be used.
• Broadcast
According to the DF1 specification, packets for the destination address 0xFF are considered broadcasts. Broadcasts are not supported with the mobile network.
Address translation
Table
Mask
• Advanced parameters
○ ACK Locally
List box: Off, On
Default = On
If "On", ACK frames (0x1006) are not transferred over-the-air.
When the Unit receives a data frame from the connected device, it generates the ACK frame
(0x1006) locally. When the Unit receives the data frame from the mobile network, it sends the
frame to the connected device and waits for the ACK. If the ACK is not received within 1 sec.
timeout, Unit sends ENQ (0x1005). ENQ and ACK are not generated for broadcast packets.
DNP3
Each frame in the DNP3 protocol contains the source and destination addresses in its header, so there
is no difference between Master and Slave in terms of the M!DGE configuration. The DNP3 allows both
Master–Slave polling as well as spontaneous communication from remote units.
• Broadcast - Note: There is not the option to set the Broadcast address, since DNP3 broadcast
messages always have addresses in the range 0xFFFD – 0xFFFF. Broadcasting is not supported
by mobile networks, thus it is not possible to set the broadcast to On..
IEC 870-5-101 is a serial polling-type communication protocol used by Master–Slave application.
More IEC 870-5-101 Masters can be used within one network and one Slave can be polled by more
Masters.
IEC 870-5-101 protocol configuration is using all parameters described in Common parameters.
Mode of Connected device
Master
Broadcast - only On, Off. Protocol broadcast address is not configurable, it is defined
by Address mode in Advance parameter (default 0xFF), but broadcasting is not allowed within mobile networks.
Address translation
Table
Mask
Slave
Broadcast accept
• Advanced parameters
○ Address mode
Even if IEC 870-5-101 is the standard, there are some users who have customized this standard
according to their needs. If addressed byte has been moved, M!DGE/RipEX has to read it at the
correct frame position.
■ IEC101
Address byte location according to IEC 870-5-101 standard.
Broadcast from Master station is generated when address byte is 0xFF.
■ 2B ADDR
Two byte address (IEC 870-5-101 standard is 1 byte). The frame is 1 byte longer than the
standard one. There is the Intel sequence of bytes: low byte, high byte. Mask Address translation
has to be used, because Table one is limited to just one byte address length.
The Master station broadcast is generated when the low address byte is 0xFF and high address
byte is also 0xFF.
■ TELEGYR
The Control byte in the standard IEC packet is omitted. The frame is 1 byte shorter than a
standard one. This is typically used in the Telegyr 805/809 protocol.
Broadcast from Master station broadcast is generated when the address byte is 0x00.
■ SINAUT
The sequence of Address byte and Control byte in the frame is swapped-over.
Master station broadcast is generated when the address byte is 0x00.
ITT Flygt
ITT Flygt is a serial polling-type communication protocol used in Master–Slave applications.
ITT Flygt protocol configuration uses all parameters described in Common parameters.
Note: There is no possibility to set the Broadcast address, since ITT Flygt
broadcast messages always have the address 0xFFFF. Hence when the
Broadcast is On, packets with this destination are handled as broadcasts.
Broadcasting is not available with mobile cellular networks.
• First Slave Address
Default = 1
Slave addresses are not defined in the ITT Flygt protocol. However Slave
addresses have to be defined in the Unit network. This is the First Slave
address in decimal format.
• Number of Slaves
Default = 1
Since the ITT Flygt protocol Master (centre) polls the Slaves (remotes)
one by one without any addressing, the number of Slaves has to be
defined.
Address translation
Slave
Table
Mask
Broadcast accept
• Wait timeout [ms]
Default = 5000
An ITT Flygt Slave sometimes sends the WAIT COMMAND (0x13) to its Master. The Unit does not
accept the next WAIT COMMAND (discards it), till the Wait timeout expires. The Recommended
value is in the 1–10 seconds range.
Modbus
Modbus RTU is a serial polling-type communication protocol used by Master–Slave application.
More Modbus Masters can be used within one network and one Slave can be polled by more Masters.
Modbus protocol configuration uses all parameters described in Common parameters.
Mode of Connected device
Master
Broadcast
Address translation
Table
Mask
Slave
Broadcast accept
Profibus
RipEX supports Profibus DP (Process Field Bus, Decentralized Periphery) the widest-spread version
of Profibus. The Profibus DP is supported even by M!DGE, but it will work satisfactorily only with mobile
networks with very short transport delays, like LTE or UMTS. The Profibus protocol configuration uses
all parameters described in Common parameters.
RP570 is a serial polling-type communication protocol used in Master–Slave applications.
Multiple RP570 Masters can be used within one network and one Slave can be polled by more than
one Master.
Italicised parameters are described in Common parameters.
Mode of Connected device
Master
• Local simulation RB
List box: Off, On
Default = Off
The RP570 protocol Master very often transmits the RB packets (hold packets) solely to check
whether Slaves are connected. In order to minimize the mobile network payload, the Unit can be
configured to respond to these packets locally and not to transmit them to the Slaves over the mobile
network.
If On, the Unit responds to RB packets received from the RP 570 master locally over the COM interface. However from time to time (RB period) the RB packets are transferred over the network in order
to check whether the respective Slave is still on. When the RB response from the Slave to this RB
packet is not received over the mobile network within the set RB timeout, i.e. the respective Slave
is out of order, the central Unit stops local answering to RB packets from the master for the respective
Slave.
• RB Net period [s]
Default = 10
The M!DGE/RipEX responds to the RB packets locally and in the set RB period the RB packets are
transferred over the network.
• RB Net timeout [s]
Default = 10 (maximum=8190)
Whenever an RB packet is sent over the network, the set RB Net timeout starts. When the RB response from the remote unit (Slave) is not received within the timeout, i.e. the respective Slave is
out of order, the central Unit stops the local answering to RB packets from the master for the respective
Slave.
• Local simulation RB
List box: Off, On
Default = Off
The RP570 Slave expects to receive RB packets from the Master. When the Local simulation RB
on the Master is On, the RB packets are transferred over the mobile network only in the RB Net
period (see the Master settings). The Local simulation RB has to be set the same (On or Off) on all
sites in the network, i.e. on the master as well as all Slaves.
If On, the Unit generates RB packets locally and transmits them over the COM interface in the RB
Request period and expects the RB response for each RB packet from the RP570 Slave within the
RB Response timeout. When the Unit does not receive the response(s) from the RP570 Slave, the
Unit does not respond to the RB packet from the Master, which it receives over the mobile networks.
• RB Request period [ms]
Default = 200 (maximum=8190)
M!DGE/RipEX sends locally RB packets to the connected RTU in the set period.
• RB Response timeout [ms]
Default = 500 (maximum=8190)
The Unit expects a response to the RB packet within the set timeout. If it is not received, the Unit
does not respond to RB packets from the Master received over the mobile network.
• RTU address (Hex)
Default = 01
Active only when the Local simulation RB is On. The connected RTU’s address is supposed to be
filled in. This address (0x00-0xFF) is used in the RB packets generated locally in the M!DGE/RipEX
and transmitted over the COM.
Siemens 3964(R)
The 3964 protocol is utilized by the Siemens Company as a Point-to-Point connection between two
controllers. Meanwhile it has become an industry standard that can be found on many devices as a
universal communications interface. 3964R is the same as 3964, in addition it only uses BCC (Block
Check Character). 3964(R) handle only the link layer (L2 in OSI model), hence Unit uses a similar way
to read “SCADA address” as in UNI protocol.
There is a handshake STX(0x02) – DLE(Ox10) at the start of communication and DLE+ETX – DLE at
the end. This handshake is performed by M!DGE/RipEX locally, it is not transferred over the network.
Communication goes as follows:
LocalRTU→STX→LocalRipex
LocalRipex→DLE→LocalRTU
LocalRTU→DATA+DLE+ETX+BCC→LocalRipex
LocalRipex→DATA→RemoteRipex*
LocalRipex→DLE→LocalRTU
RemoteRipex→STX→RemoteRTU
RemoteRTU→DLE→RemoteRipex
RemoteRipex→DATA+DLE+ETX+BCC→RemoteRTU
RemoteRTU→DLE→RemoteRipex
* only this packet is transferred over the RipEX network, all the other ones are handled locally.
Italicised parameters are described in Common parameters.
Mode of Connected device
Master
• Address mode
List box: Binary (1 B), Binary (2B LSB first). Binary (2B MSB first).
Default = Binary (1 B)
M!DGE/RipEX reads the Protocol address in the format and length set
(in bytes).
• Address position
Specify the sequence number of the byte, where the Protocol address
starts.
Note 1: 3964(R) protocol uses an escape sequence (control sequence)
for DLE (0x10), i.e. when 0x10 is in user data, 0x1010 is sent instead.
When the address position is calculated, the bytes added by the escape
sequence algorithm are not taken into account.
Note 2: The first byte in the packet has the sequence number 1, not 0.
M!DGE/RipEX expects a response (DLE) from the connected device (RTU) within the set timeout.
If it is not received, the Unit repeats the frame according to the “Retries” setting.
• Retries [No]
Default = 3 (min. 0, max. 7)
When DLE timeout is „On“, and the DLE packet is not received from the connected device (RTU)
within the set DLE timeout, the Unit retransmits the frame. The number of possible retries is specified.
• Priority
List box: Low, High
Default = Low
When the equipment sends STX and receives STX instead of DLE, there is a collision, both devices
want to start communication. In such a case, one unit has to have priority. If the Priority is High, the
Unit waits for DLE. When it is Low, the Unit send DLE.
Note: Obviously, two devices which are communicating together must be set so that one has High
priority and the other has Low.
BCC (Block Check Character) is a control byte used for data integrity control, it makes the reliability
higher. BCC is used by 3964R, 3964 does not use it.
The unit checks (calculates itself) this byte while receiving a packet on COM. Unit transmits DLE
(accepts the frame) only when the check result is OK. The BCC byte is not transferred over the network, it is calculated locally in the end Unit and appended to the received data.
UNI
UNI is the "Universal" protocol utility designed by RACOM. It is supposed to be used when the application protocol is not in the Unit list. The key condition is that messages generated by the Master application device always contain the respective Slave address and that address (or its relevant part) position,
relative to the beginning of the message (packet, frame), is always the same (Address position).
Generally two communication modes are typical for the UNI protocol: In the first one, communication
always has to be initiated by the Master and only one response to a request is supported; in the second
mode, Master-Master communication or combination of UNI protocol with ASYNC LINK protocol and
spontaneous packet generation on remote sites are possible.
The UNI protocol is fully transparent, i.e. all messages are transported and delivered in full, without
any modifications.
Italicised parameters are described in Common parameters.
Mode of Connected device
Master
• Address mode
List box: Binary (1 B), ASCII (2 B), Binary (2B LSB first). Binary (2B MSB
first).
Default = Binary (1 B)
M!DGE/RipEX reads the Protocol address in the format and length set
(in bytes).
The ASCII 2-byte format is read as 2-character hexadecimal representation of one-byte value. E.g. ASCII characters AB are read as 0xAB hex
(10101011 binary, 171 decimal) value.
• Address position
Specify the sequence number of the byte, where the Protocol address
starts. Note that the first byte in the packet has the sequence number 1,
not 0.
• Address mask (Hex)
When the Address mode is Binary 2 bytes, a 16-bit value is read from
the SCADA protocol message according to the Address mode setting
(either the MSB or the LSB first), The resulting value is then bit-masked
by the Address mask and used as the input value for SCADA to IP address translation (e.g. via a table). The default value of the Address mask
is 0xFFFF, hence the full 16-bit value is used by default.
The Address mode is set to Binary (2B LSB first), the Address mask is
set to 7FF0 and the Address position is set to 2. The SCADA message
starts with bytes (in hex) 02 DA 92 C3 .. The 2-byte address is read as
0x92DA (note the LSB came first in the message), Then 0x7FF0 mask
is applied and the resulting value 0x12D0 (0x92DA & 0x7FF0) is used
as the input for the translation.
• Poll response control
List box: On, Off
Default = On
On – The Master accepts only one response per request and it must
come from the specific remote to which the request was sent. All other
packets are discarded. This applies to the Master–Slave communication
scheme.
Note: It may happen, that a response from a Slave (No.1) is delivered
after the respective timeout expired and the Master generates the request
for the next Slave (No.2) in the meantime. In such a case the delayed
response from No.1 would have been considered as the response from
No.2. When Poll response control is On, the delayed response from the
Slave No.1 is discarded and the Master stays ready for the response
from No.2.
Web Configuration
Off – The Master does not check packets incoming from the mobile
network - all packets are passed to the application. That allows e.g.
spontaneous packets to be generated at remote sites. This mode is
suitable for the Master–Master communication scheme or a combination
of the UNI and ASYNC LINK protocols.
The Digital I/O page displays the current status of the I/O ports and can be used to turn output ports
on or off.
You can apply the following settings:
Besides on and off you may keep the status after reboot at default which corresponds to the default
state as the hardware will be initialized at power-up.
The digital inputs and outputs can also be monitored and controlled by SDK scripts.
Azimuth framesThe azimuth (rotation around the vertical axis) in degrees as stated
in GPGSV
SNRThe SNR (Signal to Noise Ratio), often referred as signal strength
Note
Please note that the values are shown as calculated by the daemon, their accuracy might be
suggestive.
Administration
The GNSS page lets you enable or disable the GNSS modules present in the system and can be used
to configure the daemon that can be used to share access to receivers without contention or loss of
data and to respond to queries with a format that is substantially easier to parse than the NMEA 0183
emitted directly by the GNSS device.
We are currently running the Berlios GPS daemon (version 3.15), supporting the new JSON format.
Please navigate to http://www.catb.org/gpsd/ for getting more information about how to connect any
clients to the daemon remotely. The position values can also be queried by the CLI and used in SDK
scripts.
GNSS Module Configuration
Administrative statusEnable or disable the GNSS module
Operation modeThe mode of operation, either standalone or
assisted (for AGPS)
Antenna typeThe type of the connected GPS antenna,
Fix frame intervalThe amount of time to wait between 1x at-
tempts
GNSS Server Configuration
Server portThe TCP port on which the daemon is listening for incoming connections
Allow clients fromSpecifies where clients can connect from, can be either everywhere or from
a specific network
Clients start modeSpecifies how data transferal is accomplished when a client connects. You
can specify on request which typically requires an R to be sent. Data will be
sent instantly in case of raw mode which will provide NMEA frames or superraw which includes the original data of the GPS receiver. If the client supports
the JSON format (i.e. newer libgps is used) the json mode can be specified.
Note
Please consider to restrict access to the server port, either by a specifying a dedicated client
network or by using a firewall rule.
Administrative statusEnable or disable GNSS supervision
ModeSpecifies whether to monitor the NMEA stream or GPS fixes
Max. downtimeThe period of time without valid NMEA stream or GPS 1x after which
an emergency action shall be taken
Emergency actionThe corresponding emergency action. You can either let just restart the
server, which will also re-initialize the GPS function on the module, or
reset the module in severe cases. Please note that this may have effects
on any running WWAN/SMS services.
7.3. ROUTING
7.3.1. Static Routes
This menu shows all routing entries of the system, which can consist of active and configured ones.
(Netmasks can be specified in CIDR notation, e.g. 24 expands to 255.255.255.0).
ActiveThe route is considered active, it might be inactive if the interface
for this route is not yet up
PersistentThe route is persistent, which means it is a configured route,
otherwise it corresponds to an interface route
HostThe route is a host route, typically the netmask is set to
255.255.255.255.
NetworkThe route is a network route, consisting of an address and net-
mask which forms the subnet to be addressed
Default RouteThe route is a default route, address and netmask are set to
0.0.0.0, thus matching any packet
You can check the corresponding routing via the "Route lookup" functionality. Just fill in the desired IP
address and click on the "Lookup" button. The detailed information about the chosen route will be displayed.
The maximum number of manual static routes is 10. This number can be increased to 30 with
a SERVER licence.
7.3.2. Extended Routes
Extended routes can be used to perform policy-based routing, they generally precede static routes.
Extended routes can be made up not only of a destination address/netmask but also a source address/netmask, incoming interface and the type of service (TOS) of packets.
Incoming interfaceThe interface on which the packet enters the system
M!DGE routers ship with two different MCR daemons to select from, depending on your dependencies:
IGMP proxyForwarding of multicast messages that are dynamically detected on a given interface
to another interface.
Static routesList of MCR rules to forward messages of dedicated source and group from a given
interface to another.
DisabledDisable routing of multicast messages.
IGMP proxy
IGMP proxy which is able to maintain multicast groups on a particular interface and distribute incoming
multicast packets towards the downstream interfaces on which hosts have joined the groups.
Administrative statusSpecifies whether multicast routing is active.
Incoming interfaceThe upstream interface on which multicast groups are joined and on
which multicast packets come in.
Distribute toSpecifies the downstream interfaces to which multicast packets will be
Redistribute OSPF routesRedistribute routes learned via the OSPF routing protocol.
Disable when redundancy backupDisables the BGP protocol when the router is set to slave mode by
the VRRP redundancy protocol.
The neighbors tab is used to configure all the BGP routers to peer with.
IP addressIP address of the peer router.
As numberAutonomous system number of the peer router (available range 1 - 4294967295).
PasswordPassword for authentication with the peer router. If left blank authentication is disabled.
MultihopAllow multiple hops between this router and the peer router instead of requiring the
peer to be directly connected.
The Networks tab allows to add IP network prefixes that shall be distributed via BGP in addition to the
networks that are redistributed from other sources as defined on the general tab.
PrefixPrefix of the network to be distributed.
Prefix lengthLength of the prefix to be distributed.
The OSPF tab allows the M!DGE router to be added to a network of OSPF routers.
OSPF statusSpecifies whether the OSPF routing protocol is active.
Redistribute connected routesRedistribute routes to networks which are directly connected to the
M!DGE router.
Redistribute local routesRedistribute routes from the M!DGE router’s own routing table.
Redistribute BGP routesRedistribute routes learned via the BGP routing protocol.
Redistribute default routeRedistribute the routers default route.
Disable when redundancy backupDisables the OSPF protocol when the router is set to slave mode
by the VRRP redundancy protocol.
The interfaces tab is used to define OSPF specific settings for the IP interfaces of the router. If no
settings are defined for a specific interface, default settings will be used.
InterfaceThe name of the interface for which settings shall be defined.
AuthenticationThe authentication protocol to be used on the interface to authenticate OSPF
packets.
KeyThe key to be used for authentication.
Key IDThe ID of the key to be used for authentication (1-255).
CostThe cost for sending packets via this interface. If not specified or set to 0, OSPF
defaults are used.
PassiveDo not send out OSPF packets on this interface.
The networks tab defines the IP networks to be handled in OSPF as well as to which routing area they
belong.
PrefixPrefix of the network.
Prefix lengthLength of the prefix.
AreaRouting area to which this interface belongs (0-65535, 0 means backbone).
7.3.7. Mobile IP
Mobile IP (MIP) can be used to enable a seamless switch between different WAN technologies.
It boasts with very small outages during switchover while keeping all IP sessions alive which is being
accomplished by communicating with the static public IP address of a home agent which will encapsulate
the packets and send them further to the router. Switching works by telling the home agent that the
hotlink address has changed, the agent will then re-route (that means encapsulate the packets with
the new target address) the packets transparently down to the box.
Our implementation supports RFC 3344, 5177, 3024 and 3519 and interoperability with Cisco has been
verified. However, M!DGE routers can run as node and home agent which makes them able to replace
expensive kits in the backbone for smaller scenarios.
If MIP is run as home agent, you will have to set up a home address and netmask first and configure
various nodes afterwards which are made up of the following settings:
SPIThe home address of the network
Authentication typeThe mask for the home network.
Shared secretThe shared secret used for the mobile node authentication at the home
agent. This can be either a 128-bit hexadecimal value or a random length
ASCII string.
M!DGE routers are able to prioritize and shape certain kinds of IP traffic. This is currently limited on
egress, which means that only outgoing traffic can be stipulated. The current QoS solution is using
Stochastic Fairness Queueing (SFQ) classes in combination with Hierarchy Token Bucket (HTB) qdiscs.
Its principle of operation can be summarized as ceiling the max. throughput per link and shaping traffic
by reflecting the specified queue priorities. In general, the lowest priority number of a queue gets most
out of the available bandwidth.
In case of demands for other class or qdisc algorithms please contact our support team in order to
evaluate the best approach for your application.
QoS Administration
The administration page can be used to enable and disable QoS.
QoS Classification
The classification section can be used to define the WAN interfaces on which QoS should be active.
Interface:The WAN interface on which QoS should be active.
Bandwidth congestion:The bandwidth congestion method. In case of the auto option, the
system will try to apply limits in a best-effort way. However, it is suggested to set fixed bandwidth limits as they also offer a way of tuning
the QoS behaviour.
Upstream bandwidth:The available bandwidth for outgoing traffic.
IP to ping (primary)An IP, which answers ICMP echo requests to determine the bandwidth
of the link.
IP to ping (secondary)An IP, which answers ICMP echo requests to determine the bandwidth
of the link.
When defining limits, you should consider bandwidth limits which are at least possible as most shaping
and queues algorithms will not work correctly if the specified limits cannot be achieved. In particular,
any WWAN interfaces operating in a mobile environment are suffering variable bandwidths, thus rather
lower values should be used.
In case an interface has been activated, the system will automatically create the following queues:
high:A high priority queue which may hold any latency-critical services (such as VoIP).
default:A default queue which will handle all other services.
low:A low priority queue which may hold less-critical services for which shaping is intended.
Each queue can be configured as follows:
Name:The name of the QoS queue.
Priority:A numerical priority for the queue, lower values indicate higher priorities.
This router uses Linux’s netfilter/iptables firewall framework (see http://www.netfilter.org for more information). It is set up of a range of rules which control each packet’s permission to pass the router.
Packets, not matching any of the rules, are allowed by default.
7.4.1. Firewall
Administration
The administration page can be used to enable and disable firewalling. When turning it on, a shortcut
can be used to generate a predefined set of rules which allow administration (over HTTP, HTTPS, SSH
or TELNET) by default but block any other packets coming from the WAN interface. Please note that
the specified rules are processed by order, that means, traversing the list from top to bottom until a
matching rule is found. If there is no matching rule found, the packet is allowed.
Administrative status:Enable or disable packet filtering.
Allow WAN administration:This option will predefine the rules for services on the WAN link as
follows (TCP ports 80, 443, 22 and 23):
Address / Port Groups
This menu can be used to form address or port groups which can be later used for firewall rules in order
to reduce the number of rules.
M!DGE can be configured with its Ethernet interfaces being bridged. In this case, the transparent firewall
functionality can be configured to limit reachability of individual hosts connected to M!DGE based on
their MAC addresses, i.e. units connected to ETH1 cannot communicate to units connected to ETH2.
7.4.2. NAPT
This page allows setting of the options for Network Address and Port Translation (NAPT). NAPT
translates IP addresses or TCP/UDP ports and enables communication between hosts on a private
network and hosts on a public network. It generally allows a single public IP address to be used by
many hosts from the private LAN network.
Administration
The administration page lets you specify the interfaces on which masquerading will be performed. NAT
will hereby use the address of the selected interface and choose a random source port for outgoing
connections and thus enables communication between hosts from a private local area network towards
hosts on the public network.
InterfaceThe outgoing interface on which connections will be masqueraded.
Source addressThe source address or network from which matching packets are masqueraded.
Inbound rules can be used to modify the target section of IP packets and, for instance, forward a service
or port to an internal host. By doing so, you can expose that service and make it available from the Internet. You may also establish 1:1 NAT mapping for a single host using additional outbound rules.
Note
The rules are processed by order, that means, traversing the list from top to bottom until a
matching rule is found. If there is no matching rule found, the packet will pass as is.
Description:A meaningful rule description
Incoming interface:Interface from which matching packets are received
SourceThe source address or network from which matching packets are received.
Map:Choosing whether the rule applies to the host or to the network.
Target address:Destination address of matching packets (optional)
Target port(s):Used UDP/TCP port range of matching packets
Redirect to:Address to which matching packets will be redirected
Redirect port:Port to which matching packets will be targeted
Outbound Rules
Outbound rules will modify the source section of IP packets and can be used to establish 1:1 NAT
mappings but also to redirect packets to a specific service.
Description:A meaningful description of this rule
Map:Choosing whether the rule applies to the host or to the network.
Outgoing interface:Outgoing interface on which matching packets are leaving the router
TargetThe target address or network to which matching packets are
destined.
Source address/ports:Source address/ports of matching packets (if Map is set to "host")
Source network/netmask:Source network/netmask of matching packets (if Map is set to
"network")
Rewrite to address/port:Address/port to which the source address/port of matching packets
will be rewritten to
Rewrite to network/netmask:Network/netmask to which the source network/netmask of matching
If enabled, OpenVPN client configurations will be started whenever a WAN link has been established.
Server configuration will be started immediately after the bootup.
Tunnel Configuration
The router supports a single server tunnel and up to 4 client tunnels. You can specify tunnel parameters
in standard configuration or upload an expert mode file which has been created in advance. Refer to
section the section called “Client Management” to learn more about how to manage clients and generate
the files.
Operation mode:Choose the client or server mode for this tunnel
Note
M!DGE can be running up to 4 OpenVPN tunnels in the Client mode, but only one tunnel in
the Server mode.
Peer selection:Specifies how the remote peer shall be selected, besides a single server you
may configure multiple servers which can , in case of failures, either be selected sequentially (i.e. failover) or randomly (i.e. load balancing).
ServerThe remote server address or hostname
PortThe remote server port (1194 by default)
Interface type:The VPN device type which can be either TUN (typically used for routed
connections) or TAP (used for bridged networks)
Protocol:The OpenVPN tunnel protocol to be used.
Network mode:Defines how the packets should be forwarded, can be routed or bridged from
or to a particular interface. You can also set the MTU for the tunnel.
Authentication:You can choose between credential-based (where you have to specify a
username and password) and certificate-based options. Note that keys/certificates have to be created in the SYSTEM -> Keys & Certificates menu. You
may also upload files which you have generated on your host system.
HMAC digest:HMAC is commonly used message authentication algorithm (MAC) that uses
a data string, a secure algorithm, and a key, to produce a digital signature.
OpenVPN's HMAC usage is to first encrypt a packet, then HMAC the resulting
cipher text. If OpenVPN receives a packet with a bad HMAC, it drops this
packet. HMAC usually adds 16 or 20 Bytes per packet.
Encryption:Required cipher mechanism used for encryption.
Use compression:Enable or disable OpenVPN compression.
Use keepalive:Can be used to send a periodic keep alive packet in order to keep the tunnel
up despite inactivity.
Redirect gateway:By redirecting the gateway, all packets will be directed to the VPN tunnel.
Please ensure that essential services (such as DNS or NTP servers) can be
reached via the network behind the tunnel. If in doubt, create an extra static
route pointing to the correct interface.
Negotiate DNSIf enabled, the system will use the nameservers which have been negotiated
over the tunnel.
Allow duplicatesAllow multiple clients with the same common name to concurrently connect.
Verify certsCheck peer certificate against local CRL.
Server Mode
A server tunnel typically requires the following files:
• a directory (with default name “ccd”) containing client-specific configuration files.
Important
OpenVPN tunnels require a correct system time. Please ensure that all NTP servers are
reachable. When using host names, a working DNS server is required as well.
Client Management
Once you have successfully set up an OpenVPN server tunnel, you can manage and enable clients
connecting to your service. Currently connected clients can be seen on this page, including the connect
time and IP address. You may kick connected clients by disabling them.
In the Networking section you can specify a fixed tunnel endpoint address for each client. Please note
that, if you intend to use a fixed address for a particular client, you would have to apply fixed addresses
to the other ones as well.
You may specify the network behind the clients as well as the routes to be pushed to each client. This
can be useful for routing purposes, e.g. in case you want to redirect traffic for particular networks towards
the server. Routing between the clients is generally not allowed but you can enable it if desired.
Finally, you can generate and download all expert mode files for enabled clients which can be used to
easily populate each client.
Operating in server mode with certificates, it is possible to block a specific client by revoking a possibly
stolen client certificate (see Keys & Certificates).
Note
The downloaded expert mode file needs to be unzipped and then individual client expert files
can be uploaded to the respective routers.
Note
See the OpenVPN configuration2example in our Application notes.
IPsec is a protocol suite for securing IP communications by authenticating and encrypting each packet
of a communication session and thus establishing a secure virtual private network.
IPsec includes various cryptographic protocols and ciphers for key exchange and data encryption and
can be seen as one of the strongest VPN technologies in terms of security.
It uses the following mechanisms:
AHAuthentication Headers (AH) provide connectionless integrity and data origin authentication for
IP datagrams and ensure protection against replay attacks.
ESPEncapsulating Security Payloads (ESP) provide confidentiality, data-origin authentication, con-
nectionless integrity, an anti-replay service and limited traffic-flow confidentiality.
SASecurity Associations (SA) provide a secure channel and a bundle of algorithms that provide the
parameters necessary to operate the AH and/or ESP operations. The Internet Security Association
Key Management Protocol (ISAKMP) provides a framework for authenticated key exchange.
Negotiating keys for encryption and authentication is generally done by the Internet Key Exchange
protocol (IKE) which consists of two phases:
IKE phase 1IKE authenticates the peer during this phase for setting up an ISAKMP secure asso-
ciation. This can be carried out by either using main or aggressive mode. The main
mode approach utilizes the Diffie-Hellman key exchange and authentication is always
encrypted with the negotiated key. The aggressive mode just uses hashes of the preshared key and therefore represents a less secure mechanism which should generally
be avoided as it is prone to dictionary attacks.
IKE phase 2IKE finally negotiates IPSec SA parameters and keys and sets up matching IPSec
SAs in the peers which is required for AH/ESP later on.
Administration
IPsec administrative status:Enable or disable IPsec
Propose NAT Traversal:NAT-Traversal is mainly used for connections which traverse a path
where a router modifies the IP address/port of packets. It encapsulates packets in UDP and therefore requires a slight overhead which
has to be taken into account when running over smallsized MTU
interfaces.
Restart on link change:If checked, the tunnel is restarted whenever any link changes the
status.
Note
Running NAT-Traversal makes IKE using UDP port 4500 rather than 500 which has to be
taken into account when setting up firewall rules.
Configuration
General
Remote peer address:The IPsec peer/responder/server IP address or host name
Administrative status:Enable or disable Dead Peer Detection. DPD will detect any broken
IPSec connection, in particular the ISAKMP tunnel, and refresh the
corresponding SAs (Security Associations) and SPIs (Security Payload
Identifiers) for a faster tunnel re-establishment.
Detection cycle:Set the delay (in seconds) between Dead Peer Detection (RFC 3706)
keepalives (R_U_THERE, R_U_THERE_ACK) that are sent for this
connection (default 30 seconds)
Failure threshold:The number of unanswered DPD R_U_THERE requests until the IPsec
peer is considered dead (the router will then try to re-establish a dead
connection automatically)
Action:The action when a DPD enabled peer is declared dead. Hold (default)
means the eroute is put into the hold status, while clear means the
eroute and SA will both be cleared. Restart means that the SA will be
immediately renegotiated.
RACOM routers support IKEv1 or IKEv2 authentication via the pre-shared keys (PSK) or certificates
within a public key infrastructure.
Using PSK requires the following settings:
PSK:The pre-shared key used
Local ID Type:The identification type for the local router which can be FQDN, username@FQDN
or IP address
Local ID:The local ID value
Peer ID type:The identification type for the remote router
Peer ID:The peer ID value
Note
When using certificates you would need to specify the Operation mode. When run as the PKI
client you can create a Certificate Signing Request (CSR) in the certificates section which
needs to be submitted at your Certificate Authority and imported to the router afterwards. In
the PKI server mode the router represents the Certificate Authority and issues the certificates
for remote peers.
Negotiation mode:Choose the negotiation mode (main, aggressive). The aggressive
mode has to be used when dealing with dynamic endpoint addresses, but it is referred to be less secure compared to the main
mode as it reveals your identity to an eavesdropper.
Encryption algorithm:The IKE encryption method (3DES, AES128, AES192, AES256)
Authentication algorithm:The IKE authentication method (MD5, SHA1, SHA2-256)
IKE Diffie-Hellman group:The IKE Diffie-Hellman group (2, 5 and 16-21)
of the key-exchange protocol and prevents compromising the keys
negotiated earlier.
Using Public Key Infrastructure requires similar settings, but the Operation mode must be configured.
Operation mode
Mode can be set either to "server" or "client". As a "server" and once you have successfully set up an
IPsec tunnel, you can manage and enable clients connecting to your service. It is possible to generate
and download expert mode files for enabled clients which can be used to easily populate each client.
IPsec Proposal
Encapsulation mode:Only the tunnel encapsulation mode is enabled
IPsec protocol:Only the ESP IPsec protocol is enabled
Encryption algorithm:The IKE encryption method (3DES, AES128, AES192, AES256,
Authentication algorithm:The IKE authentication method (MD5, SHA1, SHA256, SHA384,
SHA512)
SA life time:The Security Association lifetime in seconds
Perfect forward secrecy (PFS)Specifies whether Perfect Forward Secrecy (PFS) should be used.
This feature increases security as PFS avoids penetration of the
key-exchange protocol and prevents compromization of previous
keys.
Force encapsulation:Force UDP encapsulation for ESP packets even if no NAT situation
is detected.
Networks
When creating Security Associations, IPsec keeps track of routed networks within the tunnel. Packets
are only transmitted when a valid SA with the matching source and destination network is present.
Therefore, you may need to specify the networks behind the endpoints by applying the following settings:
Local network address:The address of your Local Area Network (LAN)
Local network mask:The netmask of your LAN
Peer network address:The address of the remote network behind the peer
Peer network mask:The netmask of the remote network behind the peer
NAT address:Optionally, you can apply NAT (masquerading) for packets coming
from a different local network. The NAT address must reside in the
network previously specified as the local network.
Note
Since the firmware 3.7.40.103, the maximum number of networks for individual IPsec tunnels
has increased from 4 to 10.
If IPSec is used as default gateway (Remote Network 0.0.0.0/0), this option can be used to exclude
some subnet/network. I.e. IPsec is not used for this particular subnet/network.
Note
See the IPsec configuration example3in our Application notes.
7.5.3. PPTP
The Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks
between two hosts. PPTP is easy to configure and widely deployed amongst Microsoft Dial-up networking
servers. However, due to its weak encryption algorithms, it is nowadays considered insecure but it still
provides a straightforward way for establishing tunnels. When setting up a PPTP tunnel, you would
need to choose between server or client.
Listen address:Specifies on which IP address should be listened for incoming client
connections
Server address:The server address within the tunnel
Client address range:Specifies a range of IP addresses assigned to each client