Application notes. M!DGE/MG102i. version 2.1 4/11/2014 RACOM s.r.o. Mirova1283 59231 Nove MestonaMorave CzechRepublic Tel.: +420565659 511 Fax: +420565659 512 E-mail: racom@racom.eu www.racom.eu
Table of Contents 1. SCADA serial protocols over GPRS routers... 5 1.1. Static Addressing with M!DGE/MG102i router in the centre... 6 1.2. Static addressing with a IP gateway to mobile operator centre... 12 1.3. Dynamic addressing... 13 1.4. Hybrid GSM/Radio networks... 33 2. M!DGE/MG102i CENTRE... 35 2.1. A standalone M!DGE in the centre... 35 2.2. A leased line to GSM/UMTS network centre... 38 2.3. Backup of WAN by UMTS/HSPA... 42 2.4. Serial port SCADA protocols implementation... 42 2.5. GPRS and VHF/UHF radio data network combination... 44 3. Backup of WAN by UMTS/HSPA... 45 3.1. Basic M!DGE configuration... 45 3.2. Practical Test... 49 A. Revision History... 50 RACOM s.r.o. M!DGE/MG102i 3
4
1. SCADA serial protocols over GPRS routers How to handle SCADA applications which use serial interface over a GPRS/EDGE/UMTS mobile network, employing M!DGE/MG102i routers. In recent years, world of communication is ruled by the Internet Protocol stack and RS232 based interfaces are generally considered obsolete. Typical SCADA device life cycle is nevertheless long enough to guarantee demand for good old serial interfaces for several years from now. Common RS232 to TCP (UDP) converters can help in some cases by creating the required number of transparent peerto-peer connections from all remote serial ports to the corresponding (physical or virtual) ports in the data centre. However such solution requires a special routing arrangement in the centre, hence it is not always feasible. A typical SCADA Front End Processor (the central interface of the application to the communication network) uses a proprietary protocol over a single RS232 interface. Each message coming out from the FEP is addressed and should be delivered to the designated remote serial port. Certainly a transparent broadcasting to all remotes could do the job, making the service provider happy (assuming the resulting bills are paid). Obviously the proper solution is to transmitt the message to the destination addresss only. A SCADA serial protocol typically uses simple 8 or 16 bit addressing. The mobile network address scheme is an IP network, where the 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 the SCADA and the IP addresses is required. To make things worse, IP addresses may be assigned to GPRS (EDGE, UMTS, etc.) devices dynamically upon each connection. This application note describes how to efficiently solve this problem using RACOM made routers. Three basic situations are described: a. The mobile network uses static IP addressing and the interfacing device to the SCADA centre is a GPRS router. Such scenario is suitable for small networks with tens of remote stations. b. The mobile network uses static IP addressing and the SCADA centre is connected to the network through a special IP gateway. This model can be used for networks with tens to hundreds remotes. c. The mobile network uses dynamic addressing for remote locations and a static address in the centre. Typically an IP gateway to mobile network is used in the centre and VPN tunnelling is employed. This design can be used for network of any size and it should be always used for large networks with hundreds or more remotes. All three scenarios require a special device in the centre to do the address translation for outgoing messages (the SCADA protocol address to the IP address/port pair). RACOM RipEX radio modem is used in the following examples, as it is the straightforward and most economical choice for the task. Moreover it opens the possibility to combine GPRS and private radios in one SCADA network (see Section 1.4, Hybrid GSM/Radio networks ). RACOM s.r.o. M!DGE/MG102i 5
1.1. Static Addressing with M!DGE/MG102i router in the centre Fig. 1.1: Typical layout of a GSM/UMTS network with static addresses 1.1.1. Setting the RipEX (address translating router) The RipEX router in the centre wraps the complete incoming RS232 message into a UDP datagram, while reading the destination SCADA address and determining the respective IP address/udp port pair. The minimal required setting for this task is as follows: 6 M!DGE/MG102i RACOM s.r.o.
Menu Settings The following values have to be changed from the factory settings (the red framed fields in the picture above): The IP address and Mask of the Ethernet interface of RipEX - the address has to be in the same LAN with the connected M!DGE/MG102i router. COM 1 (or COM 2) interface. The setting of Baud rate, Data bits, Parity and Stop bits has to match the setting of the SCADA centre. Protocol at the respective COM has to be set according to the SCADA protocol used. Many SCADA protocols can be handled by the universal "UNI" protocol (see the Application Note UNI protocol). Setting of Protocol parameters The following is a typical example where the Modbus serial protocol is used: RACOM s.r.o. M!DGE/MG102i 7
Master mode of the protocol has to be always used in the centre. In a small network, a table will be typically used for translation between protocol and IP addresses. Fill in the Dec (or Hex) format of all SCADA addresses (one per line) and the corresponding IP addresses (static IP addresses of SIM cards used at the respective remote MG102i/M!DGEs). Each UDP port has to be the same as the Local UDP port set at the COM server at the respective remote M!DGE/MG102i router. Menu Routing The Gateway for the IP address range of all remote MG102i/M!DGEs has to be set to the IP address of the central M!DGE/MG102i (and it has to fall within the range assigned to the ETH Interface). 8 M!DGE/MG102i RACOM s.r.o.
1.1.2. Setting of the central M!DGE/MG102i router Seting of NAPT All incoming UDP datagrams from the mobile network (originated at the remote MG102i/M!DGEs) have to be sent to the IP address of RipEX router in the centre, to the UDP port number corresponding with the serial port where the SCADA centre is connected it normally is 8881 for COM 1 or 8882 for COM 2. The External port range has to contain all remote UDP ports set in the respective COM servers of remote MG102i/M!DGEs. RACOM s.r.o. M!DGE/MG102i 9
Setting of routing The Default GW (Destination 0.0.0.0, Netmask 0.0.0.0 and Gateway 0.0.0.0) has to be assigned to the WWAN1 Interface. 1.1.3. Setting of remote M!DGE/MG102i routers Setting of the serial interface The setting of the Serial port has to match the respective RTU serial port setting. 10 M!DGE/MG102i RACOM s.r.o.
Setting of the Device server The UDP raw protocol on the IP port shall be used. The Local UDP port has to correspond with the respective port number set in the address translation table in the central RipEX (see the section called Seting of NAPT.). The mobile interface IP address of the central M!DGE/MG102i shall be filled in the Remote IP field, the Remote Port shall be 8881 when COM 1 is used at the central RipEX, 8882 when it is COM 2. RACOM s.r.o. M!DGE/MG102i 11
Setting of the routing The Default GW (Destination 0.0.0.0, Netmask 0.0.0.0 and Gateway 0.0.0.0) has to be assigned to the WWAN1 Interface. 1.2. Static addressing with a IP gateway to mobile operator centre Fig. 1.2: Typical layout with IP gateway to a mobile operator centre 12 M!DGE/MG102i RACOM s.r.o.
1.2.1. Setting the RipEX (address translating router) The setting of the central RipEX is the same as described in the Section 1.1.1, Setting the RipEX (address translating router) chapter above. The only difference comes in the Routing menu, where the IP gateway address has to be set as the gateway for the IP address range of all remote MG102i/M!DGEs, instead of the central MG102i/M!DGE router address (there is no such central GPRS router in this layout). See Section 1.1.1, Setting the RipEX (address translating router) for details. 1.2.2. Requirements on the IP gateway provided by the mobile operator Some settings have to be done by the mobile operator. The necessary minimum has to meet the following two requirements: all UDP datagrams outgoing from the RipEX IP address have to be delivered to the IP addresses and the respective UDP ports of remote M!DGE/MG102i routers all UDP datagrams from the remote M!DGE/MG102i addresses have to be delivered to the IP address of the RipEX in the centre (with UDP ports 8881 or 8882) 1.2.3. Settings required for Remote M!DGE/MG102i routers The settings are the same as described in the chapter Section 1.1.3, Setting of remote M!DGE/MG102i routers. The only difference is in the Remote IP field in the COM server setting (see Section 1.3.2, Setting the Ripex (address translating router).), where the IP address of the central RipEX shall be filled in. 1.3. Dynamic addressing When the IP addresses are assigned to remote M!DGE/MG102i routers dynamically, the simple static routing can not be used. Whenever a remote router establishes the connection to the GSM network, it receives a new IP address. In order to faciliate two way communication between remote and central serial ports, the M!DGE/MG102i routers support two standard types of VPN tunnels (http://en.wikipedia.org/wiki/virtual_private_network) - IPsec (http://en.wikipedia.org/wiki/ipsec) and OpenVPN (http://en.wikipedia.org/wiki/openvpn). Upon every connection to the network, a remote router creates a tunnel to the VPN concentrator in the centre (remeber a static IP address in the centre is always required). Every time a tunnel is established, the routes to IP addresses/networks connected through it are added to the routing tables in the centre. The additional advantage of VPN tunnels is higher security of data transfered through the public network. The VPN concetrator in small networks with several remotes can run in the central GSM/UMTS router (with static IP address assigned), in large networks a specialized IP router (e.g. Cisco) is needed and a leased line connection to the operator's gateway is used (similarly to the arrangement described in the paragraph Section 1.2, Static addressing with a IP gateway to mobile operator centre above). RACOM s.r.o. M!DGE/MG102i 13
Fig. 1.3: Typical layout of a GSM/UMTS network with VPN tunnels 1.3.1. VPN concentrator OpenVPN Since OpenVPN is based on universal network protocols (TCP and UDP), it is desirable alternative to IPsec when the operator's firewall blocks specific VPN protocols. OpenVPN works in multiclient-server arrangement a short description of configuration of an OpenVPN tunnel with M!DGE/MG102i follows. OpenVPN Server in M!DGE/MG102i A M!DGE/MG102i router can act as a VPN server for networks with up to 10 OpenVPN tunnel connections (up to 25 with Server Extension SW key); for larger networks a Linux or Windows based server should be used. 14 M!DGE/MG102i RACOM s.r.o.
Fig. 1.4: Typical layout of a small network The first step is enabling OpenVPN administration: Setting the Server of Tunnel 1: RACOM s.r.o. M!DGE/MG102i 15
Default values can be used. When root and server certicates are missing they have to be generated in the Keys & Certificates window; Manage keys and certificates link can be used as a shortcut. Use the Create button to generate the server certificates and keys. 16 M!DGE/MG102i RACOM s.r.o.
Important Time synchronisation of server and all clients is required - without the time synchronisation the OpenVPN tunnel cannot be established. You can use the central M!DGE as an NTP server - before establishing of tunnel only the static IP address of the central M!DGE is reachable. When there is a time server available within the GSM/GPRS network, it can be alternatively used. After successful generation you can check the certificates using the View link. You can also continue with setting of the OpenVPN using the Configure link. The available clients for the server are displayed at the bottom of the window. RACOM s.r.o. M!DGE/MG102i 17
In the Client Management window you can prepare configuration, certificates and keys for several clients. In the Networking menu, you can define the clients' networks or leave it empty. Each client can have its own network/mask. 18 M!DGE/MG102i RACOM s.r.o.
In the Routes menu, you can add networks which will be pushed into all clients' Routing menu so that matching packets will be routed back to the server. Routing between the clients can be enabled too. Expert mode files can be downloaded for all clients. Fill in the VPN server's IP address or a hostname. The downloaded zip file contains all configured clients' expert files. RACOM s.r.o. M!DGE/MG102i 19
20 M!DGE/MG102i RACOM s.r.o.
OpenVPN Client in M!DGE/MG102i The next step is setting the clients. First you need to set all the standard Ethernet settings (IP address, mask) and mobile connection. Configuring an OpenVPN client is straightforward. Enable the OpenVPN first: Then you can use expert mode of OpenVPN configuration upload the respective file generated by the server: Alternatively you can proceed step by step using standard configuration. Make sure that the respective settings of Server and Client match. RACOM s.r.o. M!DGE/MG102i 21
You can manualy upload client keys and certificates generated by server. 22 M!DGE/MG102i RACOM s.r.o.
Finally you can set any other route to the central LAN to the respective interface if you did not set it during the OpenVPN configuration process (e.g. TUN1 as in our example): RACOM s.r.o. M!DGE/MG102i 23
When the server and all clients are configured, the OpenVPN tunnels are ready. IPsec IPsec can be used in a network of any size. A dedicated router (or several routers) serve(s) as the VPN concentrator. The choice of vendor and type depends on the SLA requirements and the size of the network - RACOM has positive experience with Cisco routers (IOS or ASA based), however routers from other vendors (e.g. Juniper, Netgear, WatchGuard or others) can certainly be used. The following routers were used as IPsec VPN concentrators: M!DGE/MG102i - up to 4 tunnels Cisco 871-K9 up to 10 tunnels Cisco 1841-HSEC/ K9 up to 800 tunnels Please follow the instruction in the user manual of the specific router for IPsec tunnel settings. RACOM support team can assist you with basic settings for Cisco routers. A short description of the IPsec tunnel configuration in M!DGE/MG102i follows. 24 M!DGE/MG102i RACOM s.r.o.
IPsec configuration Fig. 1.5: Typical layout of a small network Both remote M!DGE/MG102i units in the example have dynamic mobile IP addresses. With IPsec, you have two possible configuration options: set the Center's Remote peer IP address to 0.0.0.0, or set the dynamic DNS service on every remote M!DGE/MG102i unit. Configuring remote M!DGE/MG102i units In case that you choose using the dynamic DNS functionality, read the following section how to configure it correctly. Thanks to the dynamic DNS, you can refer to the units by a hostname, which is always the same no matter what the current IP address is. Dynamic DNS Many dynamic DNS services are supported and some of them are paid and others are free. In our example, we created an account on the no-ip.com service. RACOM s.r.o. M!DGE/MG102i 25
After configuring it, enable DynDNS service in M!DGE/MG102i and wait for the service negotiation. Now you can reach a remote M!DGE/MG102i unit either via a dynamic IP address 10.23.116.206 or via the hostname racom36.no-ip.biz. You should check this in the SYSTEM Troubleshooting Network debugging Ping menu. 26 M!DGE/MG102i RACOM s.r.o.
Now you have a working dynamic DNS and the units are reachable. Proceed with the IPsec configuration. IPsec configuration Go to the VPN IPsec Tunnel Configuration menu and create a new tunnel by pressing the + sign. In the General tab, fill in the IP address of Central M!DGE/MG102i and apply the changes. In the next tab IKE Proposal, choose the type pre-shared key and fill in this key into the PSK field. One possible option is to set Local and Remote ID via FQDN as on the example below. Other parameters can stay in defaults or change them accordingly. RACOM s.r.o. M!DGE/MG102i 27
In the third tab, you can stay with default values. In the last tab, configure the local and remote networks which you want to be interconnected via the IPsec tunnel. 28 M!DGE/MG102i RACOM s.r.o.
Return to the IPsec Administration menu and enable the IPsec tunnel. If you already configured the central M!DGE/MG102i, the tunnel will be established. If not, continue with the central M!DGE/MG102i settings. Configuring the central M!DGE/MG102i Central M!DGE/MG102i configuration is almost the same as the remote ones. Again add a new tunnel and configure the tunnel accordingly. All the parameters need to be same on both ends of the tunnel. In case you are using the dynamic DNS option on the remote M!DGE/MG102i units, fill in the particular hostname as the Remote Peer instead of the IP address. RACOM s.r.o. M!DGE/MG102i 29
If you are not using dynamic DNS feature, fill in the Remote Peer IP address with 0.0.0.0. The IKE Proposal menu should be the same as in the client's configuration, only switch the Local and Remote IDs. 30 M!DGE/MG102i RACOM s.r.o.
You also need to switch the Local and Peer networks in the Networks tab. RACOM s.r.o. M!DGE/MG102i 31
Now you are done with IPsec configuration and you can enable it in the Administration menu. Note During the IPsec configuration, you will be prompted to decrease the MSS to 1360 Bytes. IPsec adds some overhead to each packet and this feature should be enabled. 32 M!DGE/MG102i RACOM s.r.o.
Connectivity test You have the desired connectivity now, you can test it in the SYSTEM Troubleshooting Network debugging Ping menu. Note If you need to add additional routing rules, you need to add it in the IPsec configuration. IPsec does not create a new interface (as OpenVPN) and so the basic static routing cannot be used. 1.3.2. Setting the Ripex (address translating router) Setting of the central follows the same steps as described in the chapter Section 1.1.1, Setting the RipEX (address translating router). The destination IP addresses in the translation table have to be the Eth interface addresses of the respective remote M!DGE/MG102i routers. 1.3.3. Setting a remote M!DGE/MG102i router Besides setting of the OpenVPN tunnel, the RS232 and COM server parameters have to be properly configured. The tunnel interface is the route to the central application. Please follow the instructions in chapters Section 1.1.2, Setting of the central M!DGE/MG102i router and Section 1.1.3, Setting of remote M!DGE/MG102i routers. 1.4. Hybrid GSM/Radio networks The RipEX in the position of the address translation centre can be simultaneously used as the central radio modem in a standard UHF/VHF network. RACOM s.r.o. M!DGE/MG102i 33
Router mode should be used. All SCADA protocol addresses are translated to the respective IP address/udp port pairs and the IP routing table in the RipEX decides whether the UDP datagram enters the GSM or UHF/VHF radio network. Please check the RipEX manual for detailed information on the configuration. 34 M!DGE/MG102i RACOM s.r.o.
M!DGE/MG102i CENTRE 2. M!DGE/MG102i CENTRE This document is intended to be a support material for RACOM sales department. A detailed Application Note shall be written to provide assistance with a concrete technical solution; do not hesitate to ask RACOM TS for help with a specific solution of a project :-) Please note that while terms SCADA CENTRE and RTU are used in following pictures, the arrangements described apply to any application devices (like ATMs, lottery terminals, surveillance cameras,...) with the same type of interface (Eth or serial). Since the serial connection is discussed in the application note Chapter 1, SCADA serial protocols over GPRS routers, we concentrate on Eth-based applications in this document. 2.1. A standalone M!DGE in the centre This simple and easy solution is feasible for small networks with up to about 20 M!DGEs. Note that the centre reliability in this arrangement is limited by the reliability of the GPRS/UMTS service in the central location. 2.1.1. Central M!DGE static addresses Static IP addresses are required for all SIM cards. RACOM s.r.o. M!DGE/MG102i 35
M!DGE/MG102i CENTRE 2.1.2. Central M!DGE VPN tunnels Static IP address is necessary for Central SIM card only - all others may use dynamic IP addresses. VPN Tunnels have to be initialised from remotes to the centre. The Midge in the centre is capable to simultaneously handle maximum 10 OpenVPN tunnels and 4 IPsec tunnels. I.e. max. 10 remotes for one application and another 4 for the 2 nd application. When a higher number of tunnels (i.e. a higher number of remote units) are required, a VPN concentrator has to be added - a special router (e.g. CISCO) for IPsec tunnels, an ordinary PC (Linux or Windows) for OpenVPN tunnels. 36 M!DGE/MG102i RACOM s.r.o.
M!DGE/MG102i CENTRE 2.1.3. Redundant M!DGE in centre VPN tunnels only Two M!DGEs with virtual router protocol (VRRP) can be used. The VRRP (one virtual IP) is active for local LAN, Two independent static SIM IPs (one for each Midge) are used for GPRS network. OpenVPN (not the IPsec) is recommended for this scenario. RACOM s.r.o. M!DGE/MG102i 37
M!DGE/MG102i CENTRE This solution increases the reliability of centre in terms of HW. A redundant VPN concentrator (cluster) solution may be used to further improve the reliability. However a leased line to the GSM operator centre is more reliable solution and it is recommended whenever the reliability of the network really matters. (see Section 2.2, A leased line to GSM/UMTS network centre ) 2.2. A leased line to GSM/UMTS network centre This scenario is feasible for networks with any number of remote sites. A leased line normally provides a better reliability than a wireless GPRS/UMTS connection and its capacity is not limited by the GSM technology available at the centre location. The leased line connects the SCADA centre directly to the operator's CORE WAN. Sometimes it can be substituted by an Internet connection between the SCADA centre and the operator's centre. 2.2.1. Leased line connection static addresses Static IP addresses for all SIM cards are required. 38 M!DGE/MG102i RACOM s.r.o.
M!DGE/MG102i CENTRE 2.2.2. Leased line connection VPN tunnels The static IP address in the centre is used, the SIM cards in remote M!DGEs may have static or dynamic IP addresses. A VPN concentrator has to be used - a special router (e.g. CISCO) for IPsec tunnels, an ordinary PC (Linux or Windows) for OpenVPN tunnels. The redundant VPN concentrator (cluster) solution may be used for higher reliability. 2.2.3. Redundant connection of remotes using two different GSM providers Dual SIM MG102i When the primary provider network fails, traffic is automatically switched to the second provider. Even with a single provider, two independent Access Point Names can be used to improve overall reliability. RACOM s.r.o. M!DGE/MG102i 39
M!DGE/MG102i CENTRE The fully redundant solution of the centre is possible as follows: Remote redundancy with two M!DGEs with VRRP - this solution can handle both the network service failure and the M!DGE router (+ antenna installation) HW fault(s). 40 M!DGE/MG102i RACOM s.r.o.
M!DGE/MG102i CENTRE A fully redundant solution for both the centre and remote locations is certainly possible. RACOM s.r.o. M!DGE/MG102i 41
M!DGE/MG102i CENTRE 2.3. Backup of WAN by UMTS/HSPA Under normal circumstances, VPN tunnels between remote and central M!DGEs are established over the WAN network. When the WAN fails, the traffic from/to the respective remote M!DGE is automatically redirected to the mobile network. 2.4. Serial port SCADA protocols implementation 2.4.1. Point to multipoint communication SCADA protocols on serial interface use proprietary addressing. Since IP addresses have to be used in the GPRS network, a translation between the SCADA addresses on serial port and IP addresses is required. Additional equipment (e.g. a RipEX) is therefore needed in the centre. The RipEX in the centre wraps serial data into UDP datagrams and sends them to the respective IP destination addresses according to the rules set for the SCADA to IP address translation. The remote M!DGEs receive these datagrams, unwrap the serial data and send it to their respective serial interfaces. Remote units use the Com server and send all data from serial interface, wrapped in UDP datagrams, to the central static IP address (VPN tunnels can be used). The central RipEX receives these datagrams, unwraps the serial data and sends it to the SCADA centre. Note that the arrangements described in Section 2.1, A standalone M!DGE in the centre and Section 2.2, A leased line to GSM/UMTS network centre apply also to the serial SCADA protocols. 42 M!DGE/MG102i RACOM s.r.o.
M!DGE/MG102i CENTRE For detail information se Section 1.1, Static Addressing with M!DGE/MG102i router in the centre. 2.4.2. Point to point communication When a simple point-to-point link between two serial port SCADA devices is needed, no extra equipment (RipEX) is necessary. M!DGE routers at both ends of the link use the same configuration as the remote ones in point-to-multipoint scenario above. The Com servers are used for serial data to UDP datagram conversion. At least one of the M!DGEs has to have a static IP address, while the other can have a dynamically assigned one - a VPN tunnel has to be used then Section 2.1.2, Central M!DGE VPN tunnels. RACOM s.r.o. M!DGE/MG102i 43
M!DGE/MG102i CENTRE 2.5. GPRS and VHF/UHF radio data network combination The picture above describes an arrangement, where part of the remote sites is connected over a private UHF/VHF radio network (e.g. sites requiring 99.9% availability) and the remaining sites are connected over a GPRS public network (e.g. distant, isolated locations where it would be uneconomical to extend the radio coverage to). The M!DGE part functionality and settings are the same as described in the Section 2.4.1, Point to multipoint communication. Then the RipEX serving as the master of the radio part interfaces the SCADA centre, performs the serial data conversion (when needed) and then decides whether a UDP datagram enters the GSM or the UHF/VHF radio network. Please check the RipEX manual for detailed information about the radio network settings. 44 M!DGE/MG102i RACOM s.r.o.
Backup of WAN by UMTS/HSPA 3. Backup of WAN by UMTS/HSPA Under typical circumstances, VPN tunnels between central M!DGE and other routers are established over the WAN network. When the WAN fails, traffic to/from the respective remote router is automatically redirected to the cellular network. Fig. 3.1: Typical topology diagram 3.1. Basic M!DGE configuration RACOM s.r.o. M!DGE/MG102i 45
Backup of WAN by UMTS/HSPA M!DGE is connected via the WAN network using its LAN2 interface. The WWAN1 link (cellular network) is down and the IPsec VPN connection is already established. To achieve this, several steps must be performed. 3.1.1. Ethernet Ports In the example, the first port (LAN1) is used for the local subnet 192.168.36.0/24 and the WAN port (LAN2) is configured with an IP address 192.168.131.230/24. See the following pictures for the details. 46 M!DGE/MG102i RACOM s.r.o.
Backup of WAN by UMTS/HSPA 3.1.2. Cellular Network Note See the M!DGE manual 1 for configuration details. 3.1.3. VPN Tunnel Configure and enable the IPsec (or OpenVPN) tunnel to the remote peer. In the example, the local network is 192.168.36.0/24 and remote networks are 192.168.30.0/24 and 192.168.40.0/24. 3.1.4. WAN Configuration In the Link Management menu, configure the LAN2 interface as the permanent and primary option. Set the WWAN interface as its backup. The Establishment mode can be either set to on switchover (to be connected only when the permanent link is not active) or permanent (to be connected all the time it is used for the quicker link switching). 1 http://www.racom.eu/eng/products/m/midge1/index.html RACOM s.r.o. M!DGE/MG102i 47
Backup of WAN by UMTS/HSPA Another step is configuring the Supervision feature. The Supervision enables M!DGE to control the link switching procedure. In our example, M!DGE checks the connection by executing the ping packets to the host on the IP address 8.8.8.8, which should be reachable via Internet. If five consecutive ping packets are unsuccessful, the link is considered down and is switched. If there is no connectivity for 30 minutes, the unit is rebooted as a result of the Emergency action. 48 M!DGE/MG102i RACOM s.r.o.
Backup of WAN by UMTS/HSPA 3.2. Practical Test Now you should be connected via the primary WAN link (LAN2). The easiest way to test the switching is to unplug the ETH cable from the LAN2 interface. M!DGE almost immediately recognizes the unplugged cable and it switches to the cellular network. The VPN tunnel should also be reestablished. Note You can test the connectivity by issuing a ping to any desired IP address (e.g. behind the VPN tunnel) in the SYSTEM Troubleshooting Network debugging menu. Plug the cable back into the LAN2 interface and wait a moment for the M!DGE to reestablish the primary connection again. You can also check the Supervision feature. Example 3.1. Cellular connection Fill in both host IP addresses in the Supervision menu. One needs to be reachable only via the cellular network and the other one only via the WAN network. Turn off the server with an IP address reachable via the WAN network. The active connection should be changed to the cellular network. Turn on the server again and see the link switch back to the primary one. RACOM s.r.o. M!DGE/MG102i 49
Revision History Appendix A. Revision History Revision 1.0 First issue 2011-12-15 Revision 2.0 2013-05-21 Added Chapter 2, M!DGE/MG102i CENTRE Revision 3.0 2013-07-18 Added Chapter 3, Backup of WAN by UMTS/HSPA Revision 2.1 2013-06-04 Updated according to M!DGE/MG102i FW 50 M!DGE/MG102i RACOM s.r.o.