Power Grids

RTU500 series - Remote Terminal Units

Part 9: Interfaces and networks
Function Description Release 12
Revision

Document identity: 1KGT 150 948 V005 1

Revision: Date: Changes:
0 07/2016 Initial version
1 06/2017 Chapter 'Supported Features' has been updated (PR#2092)
Chapter 'Denial-of-Service' has been updated (PR#29386)
2 12/2017 Updated chapter 'Configuring COM speed' of PPP server connec-
tion (PR#32535)
02/2018 Updated chapter 'Ethernet interfaces: Configuration and Rout-
ing' (PR#36633)
04/2018 New Layout
3 06/2018 Updated chapter 'Virtual Private Network' (PR#37656)
07/2018 Updated chapter 'Configuration string in CPTT' (PR#38694)
09/2018 Introduced new chapter 'Supervision of the PPP connec-
tion' (PR#38567)
10/2018 Updated chapter 'Protocol logging for communication inter-
faces' (PR#37285)
Logging of unencrypted traffic tunneled through a VPN connec-
tion (PR#20110)
4 02/2019 Updated chapter 'Denial-of-Service' (PR#30967)
03/2019 Updated chapter VPN 'Certificates' (PR#40758)
5 06/2019 Chapter 'Serial Communication' updated (PR#42571)
Contents

Contents

1 Introduction..............................................................................................................................3
1.1 About the RTU500 series Function Description............................................................ 3
1.2 Preface.................................................................................................................................... 3
1.3 References.............................................................................................................................. 3

2 Interfaces.................................................................................................................................. 5
2.1 Interface configuration....................................................................................................... 5
2.1.1 Interfaces.............................................................................................................. 5
2.1.2 Interface Configuration Rules and Restrictions........................................... 7
2.2 Serial interfaces: Duplex communication........................................................................8
2.2.1 Direct link (TxD/RxD only)................................................................................ 8
2.2.2 WT link full duplex (no handshake).................................................................9
2.2.3 Dial up (external modem DCD handshake)................................................. 10
2.3 Serial interfaces: Half-duplex communication..............................................................12
2.3.1 WT link half duplex (RTS/CTS handshake)...................................................12
2.3.2 WT link half duplex (RTS/DCD handshake)..................................................13
2.4 Serial interfaces: Point-to-Point Protocol (PPP)...........................................................14
2.4.1 Setting up a PPP client connection............................................................... 15
2.4.2 Setting up a PPP server connection..............................................................19
2.5 Serial interfaces: Additional communication modes..................................................23
2.5.1 Loop switch unit (DSTC 3002)....................................................................... 23
2.5.2 Link with collision avoidance (DCD handshake).........................................24
2.6 Ethernet interfaces: Configuration and Routing.........................................................24
2.7 USB RNDIS interface.......................................................................................................... 27
2.7.1 Introduction........................................................................................................27
2.7.2 Configuration..................................................................................................... 27
2.8 Protocol logging for communication interfaces......................................................... 28
2.8.1 Host communication protocols..................................................................... 28
2.8.2 Sub-device communication protocols..........................................................29
2.8.3 Configuration in CPTT..................................................................................... 29
2.8.4 Configuration string in CPTT.........................................................................30
2.8.5 Examples............................................................................................................. 31

3 Networks.................................................................................................................................33
3.1 Network configuration......................................................................................................33
3.2 Network configuration rules and restrictions..............................................................33
3.2.1 Denial of Service............................................................................................... 33
3.3 Virtual Private Network (VPN).........................................................................................34
3.3.1 Overview............................................................................................................. 34
3.3.2 Supported Features..........................................................................................35
3.3.3 Pre-Shared Key (PSK)....................................................................................... 36
3.3.4 Certificates.........................................................................................................36
3.3.5 Perfect Forward Secrecy (PFS).......................................................................37
3.3.6 Dead Peer Detection........................................................................................ 37
3.3.7 UDP Encapsulation and NAT-Traversal.........................................................38

1KGT 150 948 V005 1 I

 Contents

3.3.8 VPN connection set up.................................................................................... 38

3.3.9 VPN configuration............................................................................................ 38
3.4 VPN Configuration with Sophos UTM........................................................................... 44
3.4.1 Preliminaries...................................................................................................... 45
3.4.2 Create certificates............................................................................................ 47
3.4.3 Configure VPN Router..................................................................................... 49
3.4.4 Configure RTU................................................................................................... 52
3.4.5 Download X509 certificate @RTU.................................................................55
3.4.6 Establish communication............................................................................... 56
3.5 Templates.............................................................................................................................56
3.5.1 VPN IPSec encryption template.....................................................................56
3.5.2 CIDR List............................................................................................................. 59
3.5.3 APN List for Germany...................................................................................... 60
3.6 Parallel Redundancy Protocol (PRP)...............................................................................60
3.6.1 Overview............................................................................................................. 60
3.6.2 PRP in RTU500 series.......................................................................................61
3.6.3 PRP configuration............................................................................................. 62
3.6.4 PRP supervision................................................................................................ 64
3.7 IEEE 802.1X Port-based Network Access Control........................................................65
3.7.1 Technology Overview....................................................................................... 65
3.7.2 EAP (Extensible Authentication Protocol)................................................... 65
3.7.3 RTUtil500 configuration..................................................................................66
3.7.4 Certificate upload via the RTU500 Web server.......................................... 67

4 Glossary.................................................................................................................................. 69

II 1KGT 150 948 V005 1

Introduction About the RTU500 series Function Description

1 Introduction

1.1 About the RTU500 series Function Description

The Function Description consists of several parts:

Document identity Part name Explanation

1KGT 150 940 Part 1: Overview Overview of the RTU500 series and
system architecture
1KGT 150 941 Part 2: Rack mounted solu- Description of the RTU500 series
tions rack solutions
1KGT 150 942 Part 3: DIN rail solutions Description of the RTU500 series
DIN rail solutions
1KGT 150 943 Part 4: Hardware modules Overview of the RTU500 series rack
and DIN rail modules
1KGT 150 944 Part 5: SCADA functions Description of the RTU500 series
SCADA functions
1KGT 150 945 Part 6: RTU500 functions Description of the RTU500 series
functions
1KGT 150 946 Part 7: Archive functions Description of the RTU500 series
Archive functions
1KGT 150 947 Part 8: Integrated HMI Description of the RTU500 series
Integrated HMI interface
1KGT 150 948 Part 9: Interfaces and Net- Description of the RTU500 series
works Interface and Network functions
Table 1: Parts of the Function Description

1.2 Preface
Part 9: Interfaces and Networks contains information about:
• Interfaces of the CMU modules
• Network functionality of the RTU500 series

1.3 References
[1] 1KGT 150 950 RTUtil500 Users Describes the usage of engineering tool
Guide RTUtil500 of the RTU500 series
[2] Individual Ident RTU500 series Description of the Sub and Host
Communication Protocols
Protocol
Descriptions
[3] 1KGT 150 939 Interfaces and Description of the relationship of
Protocols interfaces and protocols
[4] RFC1157 A Simple Network
Management
Protocol (SNMP)
[5] RFC1213 Management
Information Base
for Network

1KGT 150 948 V005 1 3

References Introduction

Management of TCP/
IP-based internets:
MIB-II (second
version)
[6] 1KGT 150 924 RTU500 series Web
Server User's Guide
[7] IEC 62439-3 Industrial Part 3: Parallel Redundancy Protocol
Communication (PRP) and High-availability Seamless
Networks - Redundancy (HSR)
High Availability
Automation
Networks

4 1KGT 150 948 V005 1

Interfaces Interface configuration

2 Interfaces

2.1 Interface configuration

2.1.1 Interfaces
2.1.1.1 Serial interfaces CP1... CPn

The following communication units are available for the interfaces CP1... CPn:
• 560CMU05
• 560CMR01
• 560CMR02
• 540CMD01
• 540CID01
• 520CMD01
The following parameters are available for the interfaces CP1... CPn:

Parameter name Default Parameter location

Interface type RS232C CMU - serial interfaces

Type of physical interface.
Select from list.
Value range: RS232C, RS485 or fix if selection is not supported
Baud rate 9600 bits/sec CMU - serial interfaces
Value range:  200, 300, 600, 1200, 1500, 2400, 4800, 9600, 19200, 38400 bits/sec;
Modem control Direct link (TxD/RxD CMU - serial interfaces
only)

Value range:
• Direct link (TxD/RxD only)
• WT link full duplex (no handshake)
• WT link half duplex (RTS/CTS handshake)
• WT link half duplex (RTS/DCD handshake)
• Dial up (external modem DCD handshake)
• Loop switch unit (DSTC 3002), RP570/71 Host interface only
• Link with collision avoidance (DCD handshake), DNP 3 only
Usage of the controls for this interface.
Direct Link: No modem controls.
Loop Switch Unit: RP570/71 Host Interface only.
Collision Avoidance: DNP3.0 Host/Sub-Interface only
Transmit delay time disabled CMU - serial interfaces
If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

2.1.1.2 Serial interfaces CPA, (CPB)

The following communication units are available for the interfaces CPA, CPB:
• 560CMU05
The following parameters are available for the interfaces CPA, CPB:

Parameter name Default Parameter location

Interface type RS232C CMU - serial interfaces

1KGT 150 948 V005 1 5

Interface configuration Interfaces

Parameter name Default Parameter location

Type of physical interface.

Select from list.
Value range: RS232C, RS485 or fix if selection is not supported
Baud rate 9600 bits/sec CMU - serial interfaces
Value range:  200, 300, 600, 1200, 1500, 2400, 4800, 9600, 19200, 38400 bits/sec;
Modem control Direct link (TxD/RxD CMU - serial interfaces
only)

Value range:
• Direct link (TxD/RxD only)
• WT link full duplex (no handshake)
• WT link half duplex (RTS/CTS handshake)
• WT link half duplex (RTS/DCD handshake)
• Dial up (external modem DCD handshake)
• Loop switch unit (DSTC 3002), RP570/71 Host interface only
• Link with collision avoidance (DCD handshake), DNP 3 only
Usage of the controls for this interface.
Direct Link: No modem controls.
Loop Switch Unit: RP570/71 Host Interface only.
Collision Avoidance: DNP3.0 Host/Sub-Interface only
Transmit delay time disabled CMU - serial interfaces
If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

2.1.1.3 Ethernet interfaces

The following communication units are available for Ethernet interfaces:

• 560CMU05
• 560CMR01
• 560CMR02
• 540CID01
• 540CMD01
• 520CMD01
The following parameters are available for Ethernet interfaces:

Parameter name Default Parameter location

Interface mode Auto-negotiation CMU - Network Interfaces

Transmisssion rate and duplex modes.

Possible values are:
- 100BaseTx halfduplex
- 100BaseTx fullduplex
- 10BaseT halfduplex
- 10BaseT fullduplex
- Autonegotiation
Default value: Autonegotiation
Node name none CMU - Network Interfaces
Node name of RTU at this ethernet interface
IP Address 0.0.0.0 CMU - Network Interfaces
IP Address of this RTU interface
Subnet mask 0.0.0.0 CMU - Network Interfaces
Subnet mask of IP address
Default gatewayDefault Gateway IP 0.0.0.0 CMU - Network Interfaces

6 1KGT 150 948 V005 1

Interfaces Interface configuration

Parameter name Default Parameter location

IP address of default gateway

The communication units use the Ethernet interface for downloading configuration data
and for diagnostic purposes. The default IP address of the Ethernet interface is 192.168.0.1.
It is enabled and can be temporarily set to a different value using an onboard jumper (not
available on CMU modules with USB interface).

2.1.1.4 USB interfaces

The following communication units are available with USB interfaces:

• 560CMR01
• 560CMR02
• 540CID01
• 540CMD01
• 520CMD01
These communication units work as USB RNDIS target device. RNDIS host is a Windows XP or
Windows 7 computer. RNDIS interface’s IP address on the RTU is 169.254.0.10. The USB RNDIS
Device running on Windows host can get IP settings assigned automatically from the "link
local" block 169.254.0.0/16.

2.1.2 Interface Configuration Rules and Restrictions

The assignment of UART host protocols to serial interfaces is completely at the user's
disposal. There are no dependencies between different protocols run on a CMU.

Special protocols run only on the following devices:

• 560CMU05 R0002
• CP1 or CP2 of the 560CMU05
The SLC can run only in one of the following modes:
• I/O bus
• Bit protocols
• UART protocols
Mode types cannot be mixed. For instance, CPA cannot run in I/O bus mode while CPB runs in
Bit protocol mode.

Ethernet and TCP/IP-based protocols can be used with the Ethernet interface on all CMUss.

The Parallel Redundancy Protocol (PRP) can be used on CMUss with two Ethernet interfaces
only (e.g. 560CMR01).

The USB interfaces can only be used to access the RTU500 series Web-Server

For more information, refer to [3].

1KGT 150 948 V005 1 7

Serial interfaces: Duplex communication Interfaces

2.2 Serial interfaces: Duplex communication

WT Duplex
4 Wire

NCC

WT

Tx Tx
RTU500
WT

Rx Rx

Figure 1: Duplex communication

2.2.1 Direct link (TxD/RxD only)

For direct link communication, RTU500 series uses TxD and RxD via separate lines (duplex
transmission).

No control signals are used. CTS and DCD are not analyzed.

The RTU and its communication partner device are linked via a direct connection. A
communication partner device may be a PC, another RTU, a PC modem, or a CS.

Parameter name Default Parameter location

Modem CMU - serial interfaces

control:
Direct link (TxD/RxD only)

The following parameters are used for transmission control:

Parameter name Default Parameter location

Transmit delay time disabled CMU - serial interfaces

If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

Transmission delay time can be used to slow down messages.

8 1KGT 150 948 V005 1

Interfaces Serial interfaces: Duplex communication

DTR

DSR Not used

DCD No effect on transmit

RTS

CTS No effect on transmit

TxD

RxD

Figure 2: Transmission control in direct link communication

2.2.2 WT link full duplex (no handshake)

To communicate with WT modems of the type 23WT25 via 4-wire links or 2 channels, RTU500
series uses full-duplex communication.

To communicate with WT modems of the type 23WT23 via 4-wire links, RTU500 series uses
full-duplex communication.

As with No hardware handshake, RTU500 uses full-duplex communication with TxD and RxD.

DTR and RTS are set to continuous ON. This switches the modem's carrier signal to ON state.

DSR, DCD and CTS are ignored, or at least not analyzed.

Parameter name Default Parameter location

Modem CMU - serial interfaces

control:
WT link full duplex (no handshake)

The following parameters are used for transmission control:

Parameter name Default Parameter location

Transmit delay time disabled CMU - serial interfaces

If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

Transmission delay time can be used to slow down messages.

The following diagram shows transmission control in WT full-duplex communication:

1KGT 150 948 V005 1 9

Serial interfaces: Duplex communication Interfaces

DTR

DSR Not used

DCD Not used

RTS

CTS Not used

TxD

RxD

Figure 3: Transmission control in WT duplex communication

2.2.3 Dial up (external modem DCD handshake)

For dial-up communication through an external modem, RTU500 series uses TxD and RxD via
separate lines (duplex transmission).

The DTR / DSR, RTS / CTS, and DCD control signals are used for flow control. This works only
in RS232 mode.

The RTU and its communication partner device are linked via a direct connection. A
communication partner device may be a PC, another RTU, a PC modem, or a CS.

Parameter name Default Parameter location

Modem CMU - serial interfaces

control:
Dial up (external modem DCD handshake)
Dial up enabled: enabled CMU - serial interfaces
If enabled:
This interface is using a dial-up connection
to the sub devices or the host interfaces.
Note: Not all protocols are supporting 'dial-up'.
Available only, if 'Dial up' is selected

The following parameters are used for transmission control:

Parameter name Default Parameter location

Transmit delay time disabled CMU - serial interfaces

If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

Transmission delay time can be used to slow down messages.

10 1KGT 150 948 V005 1

Interfaces Serial interfaces: Duplex communication

DTR

DSR Not used

DCD No effect on transmit

RTS

CTS No effect on transmit

TxD

RxD

Figure 4: Transmission control in direct link or modem link communication

RTU500 NCC NCC

Hayes Modem

Hayes Modem Hayes Modem Hayes Modem

RTU500 RTU500 RTU500

Figure 5: Dial-up configuration (example)

1KGT 150 948 V005 1 11

Serial interfaces: Half-duplex communication Interfaces

2.3 Serial interfaces: Half-duplex communication

WT Half Duplex WT Half Duplex
4 Wire 2 Wire

NCC NCC

WT WT

RTU500

RTU500
Tx Tx Tx

Rx WT Rx WT Rx
RTU500

RTU500
Tx Tx Tx

Rx WT Rx WT Rx

Figure 6: Half-duplex communication

2.3.1 WT link half duplex (RTS/CTS handshake)

To communicate with WT modems of the type 23WT23 and 23WT25 via 2-wire links, RTU500
series uses half-duplex communication. The control signals are used to control the carrier on
the transmission line.

Parameter name Default Parameter location

Modem CMU - serial interfaces

control:
WT link half duplex (RTS/CTS handshake)

The following parameters are used for transmission control:

Parameter name Default Parameter location

Transmit delay time disabled CMU - serial interfaces

If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

Transmission delay time can be used to slow down messages.

Parameter name Default Parameter location

Carrier trailing time disabled CMU - serial interfaces

If 'Carrier Trailing Time' is enabled:
Trailing time in Milliseconds. Value range: 1 to 10000 msec.
Recommended value for WT modems in half-duplex mode:
30 msec

12 1KGT 150 948 V005 1

Interfaces Serial interfaces: Half-duplex communication

DTR

DSR Not used for 23WT21, 23WT22 and 23WT25

DCD Maybe active in Half Duplex

RTS Switch carrier on

CTS Carrier is on

TxD End of last stop bit

RxD

Figure 7: WT mode, half-duplex communication, with RTS or CTS handshake

From an RTU point of view, the following limitations have to be observed:
• Receive: RTS is reset, DCD set. DSR and CTS are not analyzed.
• Send: RTS is set and transmission delay time is awaited. When CTS is set, data is sent, the
carrier trailing time is awaited before RTS is reset. Reception is released again upon reset
of RTS.

2.3.2 WT link half duplex (RTS/DCD handshake)

To communicate with WT modems of the type 23WT23 and 23WT25 via 2-wire links, RTU500
series uses half-duplex communication. The control signals are used to control the carrier on
the transmission line.

Parameter name Default Parameter location

Modem CMU - serial interfaces

control:
WT link half duplex (RTS/DCD handshake)

The following parameters are used for transmission control:

Parameter name Default Parameter location

Transmit delay time disabled CMU - serial interfaces

If 'Transmit Delay Time' is enabled:
Delay time in Milliseconds. Value range: 1 to 10000 ms.
Recommended value for WT modems in half-duplex mode: 30 ms

Transmission delay time can be used to slow down messages.

Parameter name Default Parameter location

Carrier trailing time disabled CMU - serial interfaces

If 'Carrier Trailing Time' is enabled:
Trailing time in Milliseconds. Value range: 1 to 10000 msec.
Recommended value for WT modems in half-duplex mode:
30 msec

1KGT 150 948 V005 1 13

Serial interfaces: Point-to-Point Protocol (PPP) Interfaces

DTR

DSR
1) Transmit Delay Time

DCD 2) Carrier Trailing Time Delay

RTS

CTS *1) *2)

TxD

RxD

Figure 8: WT mode, half-duplex communication, no RTS or CTS handshake

From an RTU point of view, the following limitations have to be observed:
• Receive: RTS is reset, DCD set. DSR and CTS are not analyzed.
• Send: When RTS is set, CSTD (Carrier Setup Time Delay) is awaited (only with SCI IEC 101).
Then data is sent and CTTD (Carrier Trailing Time Delay) is awaited before RTS is reset.
Reception is released again upon reset of RTS.

2.4 Serial interfaces: Point-to-Point Protocol (PPP)

The RTU500 series Point-to-Point Protocol (PPP) implementation provides a standard method
for transporting IP datagrams over point-to-point links.

PPP is comprised of three main components:

• A standard method for encapsulating IP datagrams (Network Layer protocol information)

• A Link Control Protocol (LCP) for establishing, configuring and testing the data-link
connection
• The IP Control Protocol (IPCP) for establishing and configuring the network-layer protocol
(IP over the PPP link)
The RTU500 series supports a version of the PPP that complies with the standard for that
protocol, RFC 1661. The RTU is designed for links which transport packets between two peers.
These links provide full-duplex, simultaneous, bi-directional operation.

For each serial interface of the RTU, the type of peer used on either end of the PPP link can be
configured in one of the following ways:

• as an RTU PPP client to a remote network host over a dial-up line connection using a GSM/
GPRS modem
• as an RTU PPP server to a Microsoft® Windows® client connection over a null modem cable
Every serial interface of an RTU can be configured either as a PPP client or as a PPP server.

PPP is basically responsible for encapsulating and carrying IP datagrams across two
endpoints of a serial connection. PPP communication starts after a physical serial connection
has been established. However, before PPP can start carrying data, numerous negotiations
take place between the peers to configure, establish and monitor the connection.

14 1KGT 150 948 V005 1

Interfaces Serial interfaces: Point-to-Point Protocol (PPP)

2.4.1 Setting up a PPP client connection

2.4.1.1 Overview

The PPP Link Control Protocol is used to connect an RTU to a control system via the Internet
over any distance.

In order to use this feature, you need to equip the RTU with an external GSM/GPRS modem
connected to a serial port.

An Internet Service Provider (ISP) supporting network connections between a GPRS modem
and the Internet is required

Once a PPP connection has been established, the RTU can be accessed by a control system
using the IP address assigned by the ISP. All IP-based protocols (IEC 60870-5-104, DNP3,
Modbus, etc.) can be used with this connection.

With a PPP connection, the RTU can be configured and monitored remotely using a Web
browser.

2.4.1.2 Configuration

The following section describes the steps required to set up a PPP client connection.

2.4.1.2.1 Enabling PPP client link at a serial interface

On a CMU module select a serial interface tab and check Enable PPP box.

Select Client from the upcoming PPP mode dropdown list.

Figure 9: Enable PPP client at serial interface

The RTU supports the PPP Client configuration on all serial interfaces (CP1 - CP6, CPA, CPB)
with the following exceptions: On 560CMU05 the PPP Client link configuration is supported
on CP1 and CP2, but not on CPA or CPB.

1KGT 150 948 V005 1 15

Serial interfaces: Point-to-Point Protocol (PPP) Interfaces

2.4.1.2.2 Configuring COM speed

For other external GSM/GPRS modems (e.g. INSYS) select the required baud rate from COM
speed dropdown list. The default value is 19200 bits/sec.

2.4.1.2.3 Configuring Modem control

For other external GSM/GPRS modems (e.g. INSYS) select Dial-up (external modem DCD
handshake) from the Modem control dropdown list.

2.4.1.2.4 Configuring Dial up parameters (other modems)

Activate the Dial up enabled option and click the Dial up parameters button to open the
Modem parameters configuration dialog.

Configure the AT commands and command responses as required, using suitable values for
the modem used. The configuration settings are usually similar to the specification according
to V.25ter.

The configured AT commands are sent to the modem during initialization time.

16 1KGT 150 948 V005 1

Interfaces Serial interfaces: Point-to-Point Protocol (PPP)

Some ISPs use PIN protection to protect their SIM cards from unauthorized access. This
protection requires the user to provide a secret numeric password as an authentication
before being able to access the system. If your ISP uses this function enable the option PIN
Configuration string for GSM modem. In the text field to the right, enter the full AT command
for sending the PIN. Quotation marks around the PIN are mandatory, e.g. AT+CPIN=”9178”. If
no PIN protection is used, this option can be disabled.

The Service Configuration string for GSM modem is sent to the modem immediately before
the configured telephone number is called. The string usually contains the name of the
provider and the service offered.

Example:

In the above figure, the internal modem AirPrime WISMO228 is used. More information can be
found on: http://www.sierrawireless.com.

The configuration of external modems, e.g., INSYS GSM/GPRS, is similar. More information
can be found on: http://www.insys-tec.de/en/en/insys-gsm.

1KGT 150 948 V005 1 17

Serial interfaces: Point-to-Point Protocol (PPP) Interfaces

Under Service configuration string for GSM modem, the AT command AT+CGDCONT=<PDP
(Packet Data Protocol) context> is used to specify the service. The configuration string in the
following example uses the provider mdex.

Example: AT+CGDCONT= 1,”IP”,”mdex.ic.t-mobile”

The following table outlines the parameters used in the configuration string.

Parameter Explanation
1 PDP context id (definition stored in non-
volatile memory)
”IP” PDP type – Internet Protocol1
”mdex.ic.t-mobile” APN (Access Point Name)1
Table 2: Explanation of AT command example – String parameters

1 Quotation marks are mandatory.

2.4.1.2.5 Configuring contract specific parameters

The ISP usually provides contract-specific data, which need to be provided as part of the PPP
client link.

The following contract-specific parameters can be configured:

• Send local IP address to provider: This option is usually disabled, because the local IP
address is assigned automatically from the provider during connection setup. Attention:
If this option will be enabled in very rare cases the local IP address will be sent to the peer
and has to be acknowledged positive from the provider during connection setup.
• User name
• Password
• Telephone number

Figure 10: PPP dialog for contract-specific data

18 1KGT 150 948 V005 1

Interfaces Serial interfaces: Point-to-Point Protocol (PPP)

Enable routing setting for the PPP client interface. Use the remote network address (provided
by your provider). Define network and netmask. Gateway is handled automatically according
to the dial-in server of your provider.

Figure 11: IPv4 Routing dialog

2.4.1.2.6 Supervision of the PPP Connection

There are two supervision methods selectable from a dropdown list in RTUtil500:

a) Packets received
This is the default value (also for migration from older RTUtil500 versions).
Supervise received packets on PPP interface. If no packets will be received the PPP
interface will be restarted.
b) PING
Cyclic test if the configured host is reachable. If not the PPP interface will be restarted.
If PING is selected the following IP address field will be activated. This is the IP address of
the remote host to ping. Note: Has to be a host that is always reachable.
The default value '8.8.8.8' (primary DNS server) is reachable if connected to the public
internet.
Some providers offer a private ping-server only reachable inside their network e.g. mdex
(46.16.216.16).

2.4.1.2.7 Establishing a connection

When powering on the RTU, the AT commands configured for initialization are sent to the
modem. If these commands are answered correctly, the RTU starts a call to the telephone
number specified in the configuration data.

Once a connection is established, the connection string received, and the DCD signal
activated, control is handed over to the PPP Link Control Protocol (LCP). Note that the RTU
does not provide an IP address. The remote peer has to determine both addresses. The
network address specified in the above figure is used only for expansion of the internal
routing table and should match the address provided by the remote peer.

2.4.2 Setting up a PPP server connection

2.4.2.1 Overview

PPP is a symmetric peer-to-peer protocol. Each endpoint interacts with its peer in an identical
manner. The designations client and server are used only in the context of establishing a

1KGT 150 948 V005 1 19

Serial interfaces: Point-to-Point Protocol (PPP) Interfaces

connection to distinguish the endpoint initiating the connection (client) from the endpoint
answering that request (server). Once a physical serial connection has been established, this
distinction is no longer relevant.

The RTU500 series provides a common solution for connections between an RTU PPP server
and Windows clients. The RTU's's PPP server functionality provides a remote access server
that is able to answer connection requests from PPP clients. Microsoft® Windows® remote
access software is compliant with the PPP standard and can therefore be used to access
the RTU over the network. The RTU's's PPP server also provides advanced features, such as
authentication (optional), network address compression, and control field compression.

2.4.2.2 Configuration

The following section describes the basic configuration steps required to set up an RTU's's
PPP server and a Microsoft® Windows® PPP client.

2.4.2.2.1 Enabling a PPP Server link at a serial interface

On a CMU module select a serial interface tab and check Enable PPP box.

Select Server from the upcoming PPP mode dropdown list.

Figure 12: Enable PPP server at a serial interface

The RTU supports the PPP Server link configuration on all serial interfaces (CP1 - CP6, CPA,
CPB) with the following exceptions: On 560CMU05 the PPP Server link configuration is
supported on CP1 and CP2, but not on CPA or CPB.

2.4.2.2.2 Configuring IP addresses

In RTUtil500, the IP addresses of the local system (server) and the remote system (client) are
mandatory.

20 1KGT 150 948 V005 1

Interfaces Serial interfaces: Point-to-Point Protocol (PPP)

To configure the IP addresses, proceed as follows:

1. In the Local IP address field, enter the IP address of the PPP server in dotted decimal
format.
2. In the Remote IP address field, enter the IP address of the PPP client in dotted decimal
format.

Figure 13: Configuring IP addresses in RTUtil500

2.4.2.2.3 Configuring authentication

You can configure the PPP server with or without authentication. By default, authentication is
disabled, as displayed in the figure above.

To configure authentication for the PPP link, proceed as follows:

1. Enable the Authentication option.

2. Enter the User name and Password of the client user, as displayed in the figure below.

Figure 14: Configuring authentication in RTUtil500

The RTU supports a version of the CHAP (Challenge Handshake Authentication Protocol)
that complies with the standard for that protocol, RFC 1994. This protocol issues a random
challenge. The challenge is matched against a cryptographically hashed response generated

1KGT 150 948 V005 1 21

Serial interfaces: Point-to-Point Protocol (PPP) Interfaces

from the challenge and a secret key. Only a recipient of the challenge who also is in
possession of the key can reliably generate a valid response.

If the Authentication checkbox is enabled, the server expects the client to authenticate
before being granted access. As the server requires CHAP as its authentication method, the
client must encrypt the user name and password. The server verifies the user name and the
password provided by the client against its configured acceptable user name and password.
If the provided name and password cannot be verified, access is denied. If an authentication
failure occurs while trying to open a link, the link is closed and the client application that
attempted to open the link is notified of this event.

2.4.2.2.4 Configuring COM speed

To configure the COM speed, proceed as follows:

1. Configure both ends of the PPP link with the same connection speed used by the serial I/
O adapter. The default value of 38400 bits/s is usually an ideal match to the COM speed of
the peer and no additional configuration is necessary.

Figure 15: COM speed configuration in RTUtil500

2. Verify the PPP connection. A Microsoft® Windows® client is required for the second end
point of the connection. For a detailed description of the configuration of a standard
PPP client – as installed on Microsoft® Windows® platforms by default – refer to [6]. The
Web Server Users Manual contains additional instructions for PPP server configuration on
Windows® operating systems.
3. If the RTU's's PPP server is configured with authentication, enable the following settings in
the configuration dialogs on the Microsoft® Windows® machine.
4. From the Microsoft® Windows® Control Panel, select Network Connections.
5. Right-click on PPP-RTU560 to open the Properties dialog.
6. On the Security tab, select the custom settings according following figure.

22 1KGT 150 948 V005 1

Interfaces Serial interfaces: Additional communication modes

Figure 16: Security options

7. Enable the Challenge Handshake Authentication Protocol (CHAP) checkbox.

8. Use the same values for Maximum speed (bps) (e.g., 38400) on the Microsoft® Windows®
PPP client and for the COM speed of the PPP server in RTUtil500, as shown in the figures
COM speed configuration in RTUtil500 above and Modem Configuration dialog below.

Figure 17: Modem Configuration dialog

2.5 Serial interfaces: Additional communication

modes
2.5.1 Loop switch unit (DSTC 3002)

The communication loop switch unit DSTC 3002 for redundant communication lines is
supported only by the RP570/71 host communication interface.

1KGT 150 948 V005 1 23

Serial interfaces: Additional communication modes Interfaces

2.5.2 Link with collision avoidance (DCD handshake)

Collision avoidance is supported only by host and subdevice communication interfaces

supporting the DNP3 protocol. If a collision is detected on the communication link, the
interface will wait a random time before continuing transmission.

Parameter name Default Parameter location

Fixed delay 100 msec CMU - serial interfaces

If 'Collision Avoidance' is enabled:
Fixed delay time, if line is busy (DCD).
Value range: 0 to 2000 msec
0 <= Delay Master < Delay Slave
Maximum of random delay 100 msec CMU - serial interfaces
If 'Collision Avoidance' is enabled:
Max. time for additional random delay.
Value range: 0 to 2000 ms

2.6 Ethernet interfaces: Configuration and Routing

The CMU module selected in RTUtil500 contains a tab "E1" and if the CMU has two Ethernet
interfaces, a tab "E2". The interface parameters are configured on this tabs. There are the
following parameters:

• Interface mode (transmission rate and duplex mode)

• Node name
• IP address
• Subnet mask
• Default Gateway IP. The value indicates the next-hop intermediary through which packets
should be routed.
If there are both ethernet interfaces 'E1' and 'E2' present on selected CMU module the
following additional options are available:

Parameter name Default Parameter location

Dedicated default gateway for E2 interface disabled CMU - Network Interfaces

If enabled: A separate default gateway for E2 must be entered.
Allow IP address of interfaces in the same disabled CMU - Network Interfaces
subnet
If enabled,
both ethernet interfaces must be in the same physical Network
to use the IP addresses in the same subnet.

Deactivated by default to avoid routing problems.

There are restrictions when enabling the option 'Allow IP address of interfaces in the same
subnet':

If the ethernet interfaces E1 and E2 are configured in the same subnet and one of the link
in is down the RTU can be reached via the other ethernet interface. This works in case of
communication of host interfaces. But if a sub interface is defined and the IED is configured
with two IP ports and same IP address for both ports, then the RTU can communicate from
E1 and from E2 to the IED, but only one communication line (one socket) can be active. One
link is online (communication is up) and the redundant link cannot be connected. A “connect”
must not be done and test link cannot be send on redundant line. That means only one socket
with port 2404 can be active. If this will work is depending from IED. IED needs to ignore a
connection from redundant link as long the active link is online.

24 1KGT 150 948 V005 1

Interfaces Ethernet interfaces: Configuration and Routing

Figure 18: Ethernet interface configuration E1

Figure 19: Ethernet interface configuration E2

The RTU offers routing support for up to 10 destination networks. It is possible to configure
network routes on ethernet interfaces (E1 and if present E2) including netmask of routing
destination and interface.

The content of the internal routing table is configured on the 'IPv4 Routing' tab. There are the
following parameters:

• Network (The destination to be routed in.)

• Netmask (The value is used for specifying subnet masks.)
• Gateway (The value indicates the next-hop intermediary through which packets should be
routed.)
• Interface: The drop-down list offers the possibility to specify the type of next-hop:
Gateway or Interface based routing (E1, E2 or PPP). If Gateway is selected, the IP address
of the gateway could be entered into the textbox before. If interface based routing
is configured, the Gateway textbox is disabled, because in that case the gateway is
automatically the IP address of the selected interface. In the case of a CMU with a two
ethernet interfaces it is possible to add IPv4 network routes on a specified interface (E1 or
E2). Interface based routing via E1 or E2 is possible only, if check box 'Allow IP address of
interface in same subnet' is enabled (consistency check in RTUtil500).

1KGT 150 948 V005 1 25

Ethernet interfaces: Configuration and Routing Interfaces

Figure 20: IPv4 Routing configuration

Routing to destination networks is allowed also with breaking the IANA rules by explicit
entering the netmask for each routing configuration.

For IPv4, a destination network is identified by an IPv4 address and a netmask value. The
netmask is normally contiguous makes it possible to specify as a prefix as well. For example,
the mask 255.255.255.0is equivalent to the prefix /24 since the 24 first bits (counting from
left) are set. The netmask is selected using a dropdown list:

Figure 21: Netmask selection dropdown list

26 1KGT 150 948 V005 1

Interfaces USB RNDIS interface

2.7 USB RNDIS interface

2.7.1 Introduction

The Remote Network Driver Interface Specification (RNDIS) is a Microsoft® Windows®

proprietary protocol. It provides a virtual Ethernet link to most versions of the Microsoft®
Windows® operating systems. A partial RNDIS specification is available from Microsoft®.
The protocol is tightly bound to programming interfaces and models from Microsoft®, most
notably the Network Driver Interface Specification (NDIS).

RNDIS is a specification for network devices on dynamic Plug-and-Play I/O buses, such as
USB. It includes two components: a bus-independent message set, and a description of how
this message set is conveyed across a specific I/O bus on which it is supported.

Some communication unit of the RTU500 series embeds a USB device port that is compliant
with the Universal Serial Bus (USB) V2.0 full-speed device specification (12 Mbit/s). The RNDIS
protocol is used on top of USB, providing a virtual Ethernet link to a Microsoft® Windows® XP
or Microsoft® Windows® 7 operating system. The result is the same as creating two network
devices and assigning one to the 511CIM01 and the other one to the Microsoft® Windows®
machine. After installing and configuring the required RNDIS driver on the Microsoft®
Windows® system, the connection could be used for web server diagnostics, and for the
download of configuration data and firmware.

The USB V2.0 full-speed protocol provides communication services between Microsoft®
Windows® host and an attached USB device. The protocol provides a collection of
communication flows (pipes), each one associated to an endpoint, to the USB device.
Software on the Microsoft® Windows® host communicates with the USB device through a set
of communication flows.

Endpoint Transfer Direction Value

0 Control transfer Bidirectional 64 bytes
1 Bulk transfer Unidirectional 64 bytes
2 Bulk transfer Unidirectional 64 bytes
3 Interrupt transfer Unidirectional 8 bytes
Table 3: Endpoints

The RTU communication unit provides the USB device used to transfer data with a Microsoft®
Windows® XP/7 USB host. The USB device is able to emulate a single Ethernet device as if it
were attached to a single USB host. The Ethernet device will be found both on the host side
and the target side, enabling the host, and the target, to communicate with each other using
the TCP/IP network protocol.

2.7.2 Configuration

The RTU500 series communication unit works as a USB RNDIS target device. A Microsoft®
Windows® XP/7 computer is used as the RNDIS host.

To configure RNDIS communication, proceed as follows:

1KGT 150 948 V005 1 27

Protocol logging for communication interfaces Interfaces

1. RNDIS interface on the RTU is automatically set to 169.254.0.10.

2. The USB RNDIS device running on Windows Microsoft® Windows® XP/7 host can
get IP settings assigned automatically from the "link local" block 169.254.0.0/16
(APIPA - Automatic Private IP Addressing). As described in RFC3927, it is allocated for
communication between hosts on a single link. The Windows host can obtain this address
by auto-configuration.
3. Microsoft® Windows® XP/7 computer, customize the firewall settings to allow
communication via the RNDIS interface.
4. Subnet mask is 255.255.0.0.

After connecting the 520CMD01 communication unit and the Microsoft® Windows® XP/7
machine via USB cable for the first time, the Microsoft® Windows® machine detects the new
USB RNDIS device, and prompts to install it.

This USB interface is used for web server access via the following URL: http://169.254.0.10.
For detailed information on installing and configuring the USB RNDIS driver on Microsoft®
Windows® XP/7, see the RTU500 series Web Server User's Guide.

2.8 Protocol logging for communication interfaces

For the diagnosis of communication protocols, the RTU500 series provides functions to
capture serial and Ethernet-based communication protocols without modifications to the
hardware connections. All telegram traffic that is received and sent can be logged on request
in parallel to the RTUss’ normal processing. Simulation of subordinate devices or control
centers is not possible.

This functionality is available on every CMU and called RIO server. The logged traffic is
displayed in CPTT, the communication protocol testing tool, which is provided by Real
Thoughts (www.realthoughts.com).

Protocol logging is possible for direct serial links, Ethernet links, TCP/IP communication via
PPP protocol and network communication through VPN tunnels.

For monitoring purposes, a network connection to the card used for serial or network
communication is required. Monitoring via backplane routing is not possible.

The following chapters describe the communication protocols supported by the RTU500
series, and the configuration options available in CPTT.

ADVICE
Protocol logging is not possible on Ethernet port E2, if 'Dedicated default gateway for E2
interface' or 'Allow IP address of interfaces in the same subnet' or both is selected.

2.8.1 Host communication protocols

The following host communication protocols are available:

• IEC 60870-5-101
• IEC 60870-5-104
• DNP3
• DNP3 LAN/WAN
• Modbus TCP
• Modbus ASCII/RTU

28 1KGT 150 948 V005 1

Interfaces Protocol logging for communication interfaces

2.8.2 Sub-device communication protocols

The following sub-device communication protocols are available:

• IEC 60870-5-101
• IEC 60870-5-103
• IEC 60870-5-104
• DNP3
• DNP3 LAN/WAN
• SPAbus
• Modbus TCP
• Modbus ASCII/RTU

2.8.3 Configuration in CPTT

1. In the Protocol profile menu, configure all settings for the selected protocol in the usual
manner.
2. Ensure that the settings comply with the configuration of your system, and that the
settings correspond to a master or slave simulation.
3. In the General Preferences dialog, in the Address field of the Remote I/O Server section,
enter the IP address of the CMU to be monitored.

The default value for the network port (1793) must not be changed. An example is shown in
the following figure:

Figure 22: General Preferences dialog

To prevent unintended filtering use default masks in the protocol profile dialog for Ethernet
protocols. An example is shown in the following figure:

1KGT 150 948 V005 1 29

Protocol logging for communication interfaces Interfaces

Figure 23: Protocol Profile dialog

2.8.4 Configuration string in CPTT

In the General Preferences dialog, in the Configuration string field in the Remote I/O Server
section, enter a string that specifies the interface, or line, to be monitored.

The format of the configuration string is described below. The format excludes certain
characters from being used in the configuration string. The configuration string is case
sensitive.

Some special characters are reserved for syntax representation, and must not be used in the
configuration string:

Syntax characters Explanation

{} Selection of input options
| "or" linkage of input options
[] optional part of the string
<> configuration value (described below)
Table 4: Syntax characters

The names of interfaces to be used in the configuration string depend on the communication
unit for which the configuration string is defined:

Communication unit Serial inter- Ethernet inter- PPP links VPN tunnel
face names face names
560CMU05 cp1, cp2, cpA, cpB E1, E2, PRP PPP1, PPP2 VPN1, VPN2
560CMR01 cp1, cp2 E1, E2, PRP PPP1, PPP2 VPN1, VPN2
560CMR02 cp1, cp2, cp3, cp4, E1, E2, PRP PPP1, PPP2, PPP3, VPN1, VPN2
cp5, cp6 PPP4, PPP5, PPP6
540CID01, 540CMD01 cp1, cp2, cp3, cp4 E1, E2, PRP PPP1, PPP2, PPP3, VPN1, VPN2
PPP4
520CMD01 cp1, cp2, cp3 E1 PPP1 VPN1
Table 5: CPTT – Interface naming

2.8.4.1 Serial Communication

ABBRTU560-srl:{cpA | cpB | cp1 | cp2 | cp3 | cp4 | cp5 | cp6}

30 1KGT 150 948 V005 1

Interfaces Protocol logging for communication interfaces

Parameter Explanation
<Interface name> Serial interface name
Table 6: Serial communication variables

2.8.4.2 Network communication

ABBRTU560-net:{E1 | E2 | PRP | PPP1 | PPP2 | PPP3 | PPP4 | PPP5 | PPP6 | VPN1 | VPN2}[:{iec104
| dnp | modbus | <port number>}];remote:<IP address>[/<metric>][:{iec104 | dnp | modbus |
<port number>}][;protocol:{tcp | udp}]

Parameter Explanation
<Port number> Network port of the protocol to monitor
<IP address> IP address of the communication partner
device
<Metric> Number of relevant bits of the IP address (left
to right).

Range: 8 to 32

Default value: 32
Table 7: Network communication variables

2.8.4.3 Details concerning the network string

Note the following detail information regarding the network string:

• The first list of protocols (iec104 | dnp | modbus) defines host communication protocols
• The second list of protocols (iec104 | dnp | modbus ) describe the sub-device
communication protocol
• A port number or protocol type needs to be specified, using either the local interface or
the remote IP address.
• A port number or protocol type using the local interface refers to a host interface.
• A port number or protocol type using the remote IP address refers to a subdevice
interface.
• The default network protocol type is tcp.
• If using the parallel redundancy protocol PRP the network interface name {PRP} has to be
used.
• Using the prefix ABBRTU560- eliminates the need of a CPTT Remote I/O Client license. If
the prefix is not included in the configuration string, CPTT will output an error message.
• For logging of VPN network communication, VPN tunnel number of local CMU has to be
used.

2.8.5 Examples

1 ABBRTU560-srl:cp2
Serial interface CP2
2 ABBRTU560-srl:cpA
Serial interface CPA on CMU01, CMU02 or CMU10
3 ABBRTU560-net:E1:iec104;remote:192.168.1.100
Network interface E1, IEC 60870-5-104 host communication line, host IP address
192.168.1.100
4 ABBRTU560-net:E1:iec104;remote:192.168.1.100/24
Network interface E1, IEC 60870-5-104 host communication line, all host IP addresses are
part of the network 192.168.1.0

1KGT 150 948 V005 1 31

Protocol logging for communication interfaces Interfaces

5 ABBRTU560-net:E2;remote:192.168.1.100:dnp
Network interface E2, DNP3 LAN/WAN subdevice communication line, IED IP address
192.168.1.100, network protocol TCP
6 ABBRTU560-net:E2;remote:192.168.1.100:dnp;protocol:udp
Network interface E2, DNP3 LAN/WAN subdevice communication line, IED IP address
192.168.1.100, network protocol UDP
7 ABBRTU560-net:E1:1234;remote:192.168.1.100;protocol:tcp
Network interface E1, host communication line with network port 1234, host IP address
192.168.1.100, network protocol TCP address
8 ABBRTU560-net:E1;remote:192.168.1.100:1234;protocol:udp
Network interface E1, subdevice communication line with network port 1234, IED IP
address 192.168.1.100, network protocol UDP
9 ABBRTU560-net:PRP:iec104;remote:192.168.1.100
Redundant PRP network interface PRP, IEC 60870-5-104 host communication line, host IP
address 192.168.1.100
10 ABBRTU560-net:PPP1:iec104;remote:192.21.89.38
IEC 60870-5-104 host communication line via PPP on interface PPP1, host IP address
192.21.89.38
11 ABBRTU560-net:VPN1:iec104;remote:192.168.1.100/24
IEC 60870-5-104 host communication line via VPN tunnel 1, all host IP addresses are part of
network 192.168.1.0.
12 ABBRTU560-net:VPN1:dnp;protocol:udp
DNP3 LAN/WAN host communication line via VPN tunnel 1, all host IP addresses, network
protocol UDP

32 1KGT 150 948 V005 1

Networks Network configuration

3 Networks

3.1 Network configuration

Figure 24: RTU network with interfaces

The entire station network, including router RTUss, sub-RTUss, and IEDs, is configured in
the RTUtil500 software. Configuration of the station network topology is configured in the
Network Tree of RTUtil500. The starting point in this tree is the router RTU of the station
network. For detailed information on how to build the Network Tree, refer to [1].

3.2 Network configuration rules and restrictions

The configuration of a sub-RTU network is subject to various restrictions with regard to
definitions, physical limitations, address ranges, etc. The following restrictions apply:

• Max. 64 physical serial interfaces available (including SPB)

• Max. 16 host lines
• Max. 32 sublines
• Max. 32 substations (RTUss and IEDs) per line
• Max 150 substations in total
The actual restrictions may differ depending on the communication speed of the station
network, the communication protocols used and the amount of process data points
connected to an RTU.

3.2.1 Denial of Service

The denial of service function is designed to limit the CPU load that can be produced by
the Ethernet network traffic to the RTU. The communication facilities must not be allowed
to compromise the primary functionality of the RTU. All inbound network traffic is quota
controlled, so that a too heavy network load can be controlled. Heavy network load might for
instance be the result of malfunctioning equipment connected to the network. In case the
limit is exceeding external rate limiters shall be used.

The denial of service function measures the traffic from an Ethernet port and, if necessary,
limits it from jeopardizing the RTU's's functionality due to a high CPU load.

1KGT 150 948 V005 1 33

Virtual Private Network (VPN) Networks

Following limits are applicable:

• 560CMU02/05: 425 frames/s

• 560CMR01/2: 3000 frames/s
• 540CIG10, 540CMG10, 540CID11, 540CMD11: 425 frames/s
• 540CID01, 540CMD01: 3000 frames/s
• 520CMD01: 575 frames/s
The function has the following outputs:

• Following internal message is displayed in the RTU system diagnosis if the limit is exceed:
CMU x: Rate monitor interface Exchange to polling mode (Count=n)
• Following internal message is displayed in the RTU system diagnosis the traffic is again
below the limit: CMU x: Rate monitor interface Exchange to interrupt mode (Count=n)
How does the function create the diagnosis message:

• If the state is different than 2 seconds before, the function creates 1 diagnosis message
indicating the state change. Any additional state changes in the last 2 seconds are not
indicated.
• If the state is the same as 2 seconds before but has changed in between, the function
creates 2 diagnosis messages indicating the back and forth state change. In this case both
messages get the same time stamp.
• The last diagnosis message shows the actual state. If there are no further messages the
rate monitor remains in the last indicated state.

3.3 Virtual Private Network (VPN)

The RTU500 Virtual Private Network Protocol implementation provides a standard method for
transporting IP datagrams over a secured communication channel, called VPN tunnel.

The VPN tunnel provides confidentiality, integrity and authenticity.

Confidentiality is keeping the data secret from the unintended listeners on the network.

Integrity is ensuring that the received data is the data was actually sent.

Authenticity is providing the identity of the endpoint to ensure that the end point is the
intended entity to communicate with.

3.3.1 Overview

With the help of VPN a RTU can be connected to control system via the public internet. The
data exchange is secured via the VPN connection. From the user point of view it looks like the
RTU resides within the NCC network.

Network control center

NCC
RTU560 Internet
Network
IP sec router

RTU540

Figure 25: Typical configuration for VPN connections

34 1KGT 150 948 V005 1

Networks Virtual Private Network (VPN)

The RTU establishes a VPN connection to the IPsec Router. The VPN tunnel (red line) connects
the virtual RTU network with the NCC network. Therefore a network-to-network connection is
established. This connection is transparent and secured.

If a connection is established, the RTU can be accessed by a control system using the internal
virtual IP address. All IP based protocols can run on this connection.

The RTU can be remote configured and supervised using a web browser.

3.3.2 Supported Features

The Internet Key Exchange (IKE) is implemented according to the requirements of:
• RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP
• RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 2409: The Internet Key Exchange Protocol (IKE)
• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3947: Negotiation of NAT-Traversal in the IKE
• RFC 4306: Internet Key Exchange (IKEv2) Protocol
The Internet Security Protocol (IPsec) is implemented according to the requirements of:
• RFC 2401: Security Architecture for the Internet Protocol
• RFC 2406: IP Encapsulation Security Payload (ESP)
For Phase 1, the IKE supports the following cryptographic algorithms:
• 3DES 168 CBC
• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• BLOWFISH
• DES 56 CBC
For Phase 1, the IKE supports the following hash algorithms (integrity protection and
authenticity):
• AES128
• MD5
• SHA1
• SHA256
• SHA384
• SHA512
For Phase 1, the IKE supports the following Diffie-Hellmann groups:
• MODP group 1 (768 bit)
• MODP group 2 (1024 bit)
• MODP group 5 (1536 bit)
• MODP group 14 (2048 bit)
• MODP group 15 (3072 bit)
• MODP group 16 (4096 bit)
• MODP group 17 (6144 bit)
• MODP group 18 (8192 bit)
For Phase 2 (IPsec), the IKE supports the following cryptographic algorithms:
• 3DES 168 CBC
• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• BLOWFISH
• DES 56 CBC
• NULL

1KGT 150 948 V005 1 35

Virtual Private Network (VPN) Networks

For Phase 2 (IPsec), the IKE supports the following cryptographic algorithms (integrity
protection and authenticity):
• AES128
• MD5
• SHA1
• SHA256
• SHA384
• SHA512
For Phase 2 (IPsec), the IKE supports the following Diffie-Hellmann groups:
• MODP group 1 (768 bit)
• MODP group 2 (1024 bit)
• MODP group 5 (1536 bit)
• MODP group 14 (2048 bit)
• MODP group 15 (3072 bit)
• MODP group 16 (4096 bit)
• MODP group 17 (6144 bit)
• MODP group 18 (8192 bit)
If Perfect Forward Secrecy (PFS) is enabled, Phase 2 performs a new Diffie-Hellman
computation of key material using the same Diffie-Hellman group as configured for Phase 1.
If Perfect Forward Secrecy (PFS) is not enabled, Phase 2 uses the key material generated in
Phase 1 to establish keys for the transforms to be used by IPsec.

For peer authentication Pre-Shared Key (PSK) and certificates are supported.

Protocol versions IKEv1 and IKEv2 are supported. IKEv2, the second version of the IKE
protocol, uses the same techniques as IKEv1, but improves upon IKEv1 in the following ways:
• simpler message exchange
• fewer cryptographic mechanisms
• greater reliability through state management
• better resistance to denial-of-service attacks
The maximum number of supported VPN tunnels per CMU is one. A VPN tunnel could be
established also in redundant configurations.

Only ESP tunnel mode is supported.

3.3.3 Pre-Shared Key (PSK)

The RTU supports authentication method Pre-shared key. Network peers can establish trust
in each other through the use of a pre-shared key (also called a pre-shared secret). At the
start of negotiation, the peers compare their stored key values. If the keys do not match,
authentication and negotiation fail.

Maximum PSK length is 64 characters.

3.3.4 Certificates

The RTU supports authentication method Certificates. Network peers can establish trust in
each other through the exchange of X.509 certificates. A certificate binds a peer’s public key
to the peer’s identity. In order to be trusted, the certificate must itself be signed by a trusted
Certificate Authority (CA) or by a member of a chain of trust that ends at such an authority.

Using the certificate management page of the RTU500 series web server, the certificate for
VPN functionality has to be uploaded. A private key certificate of the following characteristics
is required. The certificate contains an end-entity certificate with public/private key pair and

36 1KGT 150 948 V005 1

Networks Virtual Private Network (VPN)

the whole certificate chain. For the upload the passphrase of the private key is required. The
private key certificate must in PKCS#12 format and the file extension must be "*.p12".

3.3.5 Perfect Forward Secrecy (PFS)

The RTU supports Perfect Forward Secrecy. RFC 2409: The Internet Key Exchange (IKE), states
the principle of PFS: the key used to protect a transmission of data must not be used to
derive any additional keys, and if the key used to protect a transmission of data was derived
from some other keying material, that material must not be used to derive any more keys.

If PFS is enabled, Phase 2 performs a new Diffie-Hellman computation of key material. This
operation significantly slows down the exchange but ensures that the Phase 2 traffic will still
be protected even if an attacker breaks the Phase 1 exchange. If PFS is not enabled, Phase 2
uses the key material generated in Phase 1 to establish keys for the transforms to be used by
IPsec.

Parameter name Default Parameter location

Perfect forward secrecy enabled CMU - Network Interfaces

Use Perfect Forward Secrecy.
This feature increases security as with PFS, penetration of the key-exchange protocol does not compromise keys negotiated
earlier.

3.3.6 Dead Peer Detection

To detect dead peers a two different mechanisms are supported:

• DPD (Dead Peer Detection)

• PING (ICMP)
RTU IKE implementation supports dead peer detection, based upon RFC 3706: A Traffic-
Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.

When two peers communicate using IPsec and IKE, a situation may arise in which connectivity
between the two goes down unexpectedly; for example, because of routing problems or if
one of the hosts reboots. In such cases, there is often no way for IPsec and IKE to detect
the loss of connectivity. SAs may remain in existence (until their lifetimes naturally expire),
resulting in a “black hole” situation where packets are tunneled to oblivion. It is desirable to
recognize black holes as soon as possible so that a host can quickly fail over to a different
peer. Likewise, detecting black holes enables the recovery of lost resources.

There is an alternative feature to detect dead peers with ping utility. That alternative
requires a host IP address and an interval time to be configured. The RTU sends a ping to
the configured Host IP address when the Interval time expires. The RTU waits 5 seconds
for a ping answer. The RTU repeats this up to five times. The connection is broken if no
answer received. The VPN connection is torn down and a new connection is established. The
configured Host IP address must reside within the remote network IP address range.

Parameter name Default Parameter location

Dead peer detection - Keep alive method DPD CMU - Network Interfaces
Ping: Enable the Ping Dead peer detection. The keep alive daemon sends a ping message to the configured host IP every
configured ping interval to check if the connection is still available.
DPD: Enable the Dead peer detection of IKE protocol. The IKE daemon initiates DPD if no packets have been received since the
last poll of the IPsec SA and the time since the last received packets is greater than or equal to the liveness parameter.

1KGT 150 948 V005 1 37

Virtual Private Network (VPN) Networks

Parameter name Default Parameter location

Value range:
• DPD
• PING
Dead peer detection - Host IP address 0.0.0.0 CMU - Network Interfaces
IP address of the host used for sending keep alive messages.
Dead peer detection - Interval time 30 sec CMU - Network Interfaces
Time between the two tests to detect if the peer is reachable or not.
Value range: 10.. 3600 sec
Dead peer detection - Liveness time 30 sec CMU - Network Interfaces
Time with an absence of incoming traffic the IKE SA accepts before sending a DPD message. The IKE SAs are checked every 10
seconds. Therefore this is the interval to detect the absence of incoming traffic.
Value range: 10.. 3600 sec

3.3.7 UDP Encapsulation and NAT-Traversal

The RTU supports NAT-Traversal. IPsec NAT-T introduces support for crypto peers to travel
through NAT or PAT devices in the network by encapsulating crypto packets in a UDP wrapper,
which allows packets to traverse NAT device. NAT-T is auto-negotiated between the two
crypto peers during ISAKMP negotiation with a destination UDP port 4500 instead of 500.
NAT-T is defined in RFC 3947: Negotiation of NAT-Traversal in the IKE.

3.3.8 VPN connection set up

The IPsec connection setup is divided in two phases. IPsec connections are based on Security
Associations (SA). The SAs are created from the IKE protocol during connection setup.

Setting up an IPsec connection starts with IKE Phase 1 and is the initial negotiation of a bi-
directional connection between two crypto peers, referred to as main mode. IKE Phase 1
begins with an authentication in which each crypto peer verifies their identity with each
other (Certificates or PSK). When authenticated, the crypto peers agree upon the encryption
algorithm, hash method and other parameters (e.g. IKE SA lifetime). The negotiated SA
information is stored locally in the SA database of each crypto peer.

In IKE Phase 2, the IPsec SAs are negotiated by the IKE process using the bi-directional SA,
referred as quick mode.

The IPsec SAs are uni-directional in nature, causing separate key exchange for data flowing
in each direction. One of the advantages is to double the amount of work required by an
eavesdropper to successfully recover both sides of a conversation.

During IKE Phase 2 the crypto peers agree upon the encryption algorithm, authentication
(hash) methods and other parameters (e.g. IPsec SA lifetime).

3.3.9 VPN configuration

Step 1: Configure the used IP interface (Ethernet or PPP). Enable VPN on this IP interface.

Parameter name Default Parameter location

Enable VPN disabled CMU - Network Interfaces

If enabled: This interface is used to created a VPN connection to a remote network using IPsec. This interface is used
exclusively for the VPN connection. Establishing connections to the IP address configured for the interface are not possible.

38 1KGT 150 948 V005 1

Networks Virtual Private Network (VPN)

Parameter name Default Parameter location

VPN Tunnel Number 1 CMU - Network Interfaces

VPN Tunnel number.
Value range: 1 to 32.

Figure 26: Configuration of an IP interface

Step 2: Configure the IPsec Peers

The local IP address is taken from the interface configuration and can’t be modified. Set the
Remote IP address (public IP address of the IPsec server).

Parameter name Default Parameter location

Local IP address CMU - Network Interfaces

IP address of the local interface to which IPsec is bound.
This interface is used to communicate with the peer.
Remote IP address 0.0.0.0 CMU - Network Interfaces
The IP address of the IPsec peer / responder / server.

1KGT 150 948 V005 1 39

Virtual Private Network (VPN) Networks

Figure 27: VPN settings

Step 3: Configure the IPsec Networks

First configure the local virtual network. Set the desired Local virtual IP address. This address
can be used to access the RTU from the NCC. Also set the Local virtual network and the Local
virtual netmask. A typical value is 255.255.255.0 because only one IP address of the address
space is used.

Second configure the remote network. Set the Remote network. It is the network reachable
through the VPN tunnel. Also set the network mask of this network.

Parameter name Default Parameter location

Local virtual IP address 0.0.0.0 CMU - Network Interfaces

40 1KGT 150 948 V005 1

Networks Virtual Private Network (VPN)

Parameter name Default Parameter location

IP address of the local virtual loopback interface.

Provide a network in dotted decimal notation. This IP address is used to provide a local virtual network connected with the
peer via the IPsec tunnel. All traffic to this IP address are send via the IPsec tunnel to the peer.
Local virtual network 0.0.0.0 CMU - Network Interfaces
The local virtual network.
Provide a network in dotted decimal notation.
Local virtual netmask 0.0.0.0 CMU - Network Interfaces
IP address of the local virtual loopback interface.
This net mask is used to provide a local virtual network connected with the peer via the IPsec.
Remote network 0.0.0.0 CMU - Network Interfaces
The remote private network.
Provide a network in dotted decimal notation.
Remote network subnet mask 0.0.0.0 CMU - Network Interfaces
The remote peer network mask.
Provide a subnet mask in dotted decimal notation.

Step 4: Configure the IKE version

Select the used IKE protocol version allowed for tunnel negotiation and establishment. IKEv1
and IKEv2 means the RTU tries to connect with v1 and accepts both v1 and v2.

Parameter name Default Parameter location

IKE version IKEv1 CMU - Network Interfaces

Select the used IKE protocol version allowed for tunnel negotiation and establishment.

Value range:
• IKEv1
• IKEv1 and IKEv2
• IKEv2

Step 5: Configure the Authentication method

Select Certificates or Pre-shared key (PSK). The PSK is an ASCII character string up to 64
characters. This key must be the same on the RTU and the IPsec server.

Example: “dh34E2k_iew9j823H&,spwDkd43Hez23”

Authentication using Certificates is explained by means of an example in a separate chapter

below.

Parameter name Default Parameter location

Authentication method Pre-shared key CMU - Network Interfaces

The authentication mode used for the VPN.
Pre-shared keys (PSK) uses a known secure string exchanged in advanced. Certificates use a public and private key to encrypt
the data. Certificates are more secure solution than PSK.

Value range:
• Pre-shared key
• Certificates
Pre-shared key CMU - Network Interfaces
Shared Secret for authentication.
Should be as long as possible and complex. The maximum length are 64 characters.

Step 6: Configure IKE (Phase 1)

1KGT 150 948 V005 1 41

Virtual Private Network (VPN) Networks

Configure the security policies for the IKE authentication. Specify the encryption algorithm,
authentication algorithm and Diffie-Hellmann group.

It is also possible to modify the IKE SA Lifetime. After 75% of this time the SA is renewed. It
isn’t possible until the SA Lifetime expires. In that case, the SA is deleted and the connection
is turned down.

The SA Lifetime may be changed when the server uses the strict policy option. In this case a
connection setup is only successful if the SA lifetimes are the same.

The used values have to be matched the settings of the IPsec server otherwise no connection
can be established.

Parameter name Default Parameter location

Negotiation mode main CMU - Network Interfaces

IKE Negotiation mode.
Actually only main mode is supported.
IKE encryption algorithm AES 256 CBC CMU - Network Interfaces
Encryption algorithm to be used to protect IKE data packets

For Phase 1, the IKE supports the following cryptographic algorithms:

• 3DES 168 CBC
• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• BLOWFISH
• DES 56 CBC
IKE authentication algorithm SHA1 CMU - Network Interfaces
Authentication algorithm to be used to
generate key material for IKE SA negotiation.

For Phase 1, the IKE supports the following hash algorithms (integrity protection and
authenticity):
• AES128
• MD5
• SHA1
• SHA256
• SHA384
• SHA512
IKE Diffie-Hellmann group MODP group 2 (1024 CMU - Network Interfaces
bit)
Group used for Diffie-Hellman negotiations.

For Phase 1, the IKE supports the following Diffie-Hellmann groups:

• MODP group 1 (768 bit)
• MODP group 2 (1024 bit)
• MODP group 5 (1536 bit)
• MODP group 14 (2048 bit)
• MODP group 15 (3072 bit)
• MODP group 16 (4096 bit)
• MODP group 17 (6144 bit)
• MODP group 18 (8192 bit)
IKE SA lifetime 28800 sec CMU - Network Interfaces
Lifetime of the negotiated security association.
The SA is automatically renewed if data are transmitted in the last 25% of the time otherwise the SA is deleted and a new is
negotiated.
Value range: 60... 9999999 sec

42 1KGT 150 948 V005 1

Networks Virtual Private Network (VPN)

Step 7: Configure IPsec (Phase 2)

Configure the security policies for the IPsec connection (Phase 2). These parameters are
typically the same as in IKE Phase 1. But it is also possible to use different values.

For advanced user it is also possible to modify the IPsec SA Lifetime. After 75% of this time
the SA is renewed. It isn’t possible until the SA Lifetime expires. In that case, the SA is deleted
and the connection is turned down.

The SA Lifetime may be changed when the server uses the strict policy option. In this case a
connection setup is only successful if the SA Lifetimes are the same.

Perfect forward secrecy is enabled per default.

Parameter name Default Parameter location

ESP mode tunnel CMU - Network Interfaces

Select the IPsec Encapsulation Mode.
Actually only tunnel mode is supported.
IPsec encryption algorithm AES 128 CBC CMU - Network Interfaces
Encryption algorithm to be used to protect IPsec data packets.

For Phase 2 (IPsec), the IKE supports the following cryptographic algorithms:
• 3DES 168 CBC
• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• BLOWFISH
• DES 56 CBC
• NULL
IPsec integrity algorithm SHA1 CMU - Network Interfaces
Integrity algorithm to be used to protect IPsec data packets.
IKEv1 does not make use of an integrity algorithm for the IKE traffic; IKEv2 does. A configured integrity algorithm in the IKE SA
proposal will be ignored if IKEv1 is used.

For Phase 2 (IPsec), the IKE supports the following cryptographic algorithms (integrity
protection and authenticity):
• AES128
• MD5
• SHA1
• SHA256
• SHA384
• SHA512
IPsec Diffie-Hellmann group MODP group 2 (1024 CMU - Network Interfaces
bit)
Group used for Diffie-Hellman negotiations.

For Phase 2 (IPsec), the IKE supports the following Diffie-Hellmann groups:
• MODP group 1 (768 bit)
• MODP group 2 (1024 bit)
• MODP group 5 (1536 bit)
• MODP group 14 (2048 bit)
• MODP group 15 (3072 bit)
• MODP group 16 (4096 bit)
• MODP group 17 (6144 bit)
• MODP group 18 (8192 bit)
IPsec SA lifetime 28800 sec CMU - Network Interfaces

1KGT 150 948 V005 1 43

VPN Configuration with Sophos UTM Networks

Parameter name Default Parameter location

Lifetime of the negotiated security association.

The SA is automatically renewed if data are transmitted in the last 25% of the time otherwise the SA is deleted and a new is
negotiated.
Value range: 60... 9999999 sec

Parameter name Default Parameter location

Perfect forward secrecy enabled CMU - Network Interfaces

Use Perfect Forward Secrecy.
This feature increases security as with PFS, penetration of the key-exchange protocol does not compromise keys negotiated
earlier.

Step 8: Configure Dead peer detection

To detect a dead VPN connection, select between two methods DPD and PING.

Parameter name Default Parameter location

Dead peer detection - Keep alive method DPD CMU - Network Interfaces
Ping: Enable the Ping Dead peer detection. The keep alive daemon sends a ping message to the configured host IP every
configured ping interval to check if the connection is still available.
DPD: Enable the Dead peer detection of IKE protocol. The IKE daemon initiates DPD if no packets have been received since the
last poll of the IPsec SA and the time since the last received packets is greater than or equal to the liveness parameter.

Value range:
• DPD
• PING
Dead peer detection - Host IP address 0.0.0.0 CMU - Network Interfaces
IP address of the host used for sending keep alive messages.
Dead peer detection - Interval time 30 sec CMU - Network Interfaces
Time between the two tests to detect if the peer is reachable or not.
Value range: 10.. 3600 sec
Dead peer detection - Liveness time 30 sec CMU - Network Interfaces
Time with an absence of incoming traffic the IKE SA accepts before sending a DPD message. The IKE SAs are checked every 10
seconds. Therefore this is the interval to detect the absence of incoming traffic.
Value range: 10.. 3600 sec

3.4 VPN Configuration with Sophos UTM

This chapter describes an example configuration between RTU520 with GPRS Modem and
Sophos UTM using certificate based authentication.

44 1KGT 150 948 V005 1

Networks VPN Configuration with Sophos UTM

3.4.1 Preliminaries

Define local and remote networks.

Definition:

• Local virtual network is on RTU site. This must be different to IP address range for E1
interface. Under this IP address RTU is reachable from control system.
• VPN Remote network is on Control System site.
• Fixed public IP address is on Control System site.
For RTU local virtual network only one IP address for RTU is required. This results in a small
subnet for each VPN connection (/30), with 64 subnets in a range of one class C network.

Here is an example for Local virtual network with starting subnet 192.168.0.0:

RTU Name RTU IP address Network Netmask CIDR-Suffix

1 192.168.0.1 192.168.0.0 255.255.255.252 /30
2 192.168.0.5 192.168.0.4 255.255.255.252 /30
3 192.168.0.9 192.168.0.8 255.255.255.252 /30
4 192.168.0.13 192.168.0.12 255.255.255.252 /30
………
64
65 192.168.1.1 192.168.1.0 255.255.255.252 /30

The VPN remote network needs to be in a different subnet (different to Local virtual network
and E1 network).

Receive GPRS Information from Provider.

Depending on your provider the following information is required:

• APN (if possible APN without NAT, see examples in appendix)

• APN Login (in most cases for username and password any is accepted, in some cases
empty username or password is not allowed)

1KGT 150 948 V005 1 45

VPN Configuration with Sophos UTM Networks

• SIM PIN (if not disabled on SIM card)

• Fixed Public IP address (External (WAN) interface of VPN server)
Define encryption policy for VPN connection between RTUss and VPN server.

With Sophos UTM following configuration has been tested:

IKE Version X IKEv1

IKEv2

IKEv1 and IKEv2

ISAKMP Parameter
IKE encryption algorithm
3DES

AES 128 CBC

AES 256 CBC

IKE authentication algorithm
AES128

MD5

SHA1

SHA256

SHA384

SHA512

IKE DH group
group 5: MODP 1536-bit

X group 2: MODP 1024-bit

group 1
Authentication
Preshared Key

RSA Key
RSA Key RSA key with FQDN:
IKE SA lifetime (Phase 1)
28800 sec

9600 sec

3600 sec
IPsec SA Parameter

46 1KGT 150 948 V005 1

Networks VPN Configuration with Sophos UTM

X ESP
IPSec encryption algorithm
3DES

AES 128

AES 256
IPSec authentication algorithm
AES128

MD5

SHA1

SHA256

SHA384

SHA512

IPSec SA lifetime (Phase 2)

28800 sec

9600 sec

3600 sec
IPSec PFS

IPSec PFS group X group 2: MODP 1024-bit

Compression not supported
Dead peer detection
Keep alive method X DPD

A valid policy @Sophos UTM need to be defined or selected. Naming could be RTU_GPRS

3.4.2 Create certificates

Sophos UTM bring all infrastructure with the device that is required for certificate based
authentication via IPSec VPN.

Here is a step by step description how to do with Sophos UTM Version 8.

1KGT 150 948 V005 1 47

VPN Configuration with Sophos UTM Networks

3.4.2.1 Generate X509 certificate for each RTU via web interface @Sophos UTM

Click on Site-to-site VPN and then

“Certificate Management”

Then click to “New certificate...”

The field Name, VPN ID and Common Name should be the same. In this example
RTU520.RTUName is used. Replace RTU520 with your device and RTUName with the Station
Name of your RTU. The dot in the name is required.

Select as VPN ID Type: Hostname. Fill the other values with your information.

For each VPN connection to a RTU an own certificate is required.

3.4.2.2 Download X509 certificate and define transport password @Sophos UTM

Search created certificate in list and click on download:

48 1KGT 150 948 V005 1

Networks VPN Configuration with Sophos UTM

Export as “PKCS#12” certificate and enter transport password in Export password field,
repeat and click “Download” again.

Save this to your local disc. This certificate is required later on RTU web server. The password
as well.

On this table you can write down your transport passwords:

Certificate Password
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….
RTU-……………….

3.4.3 Configure VPN Router

3.4.3.1 Create “New Remote Gateway” @Sophos UTM

Click on Site-to-site VPN and then “IPSec”

1KGT 150 948 V005 1 49

VPN Configuration with Sophos UTM Networks

Then Click on ”New Remote Gateway...”

Add New Remote Network definition (if not available) via ”+” button:

Fill in name is a good way. E.g. Using geographical identifier like

CS for Control System

N for Network

NG for NetworkGroup

H for Host

HG for Hostgroup

192.168.0.0 for NetworkAddress

192.168.0.1 for IPAddress

Location_N_NetworkAddress
Host_H_IPAddress

Fill in ”Add Remote Gateway” form:

Define a Name with e.g. RTU and Network Information is in.

Gateway type is Respond only, because IP address of RTU via GPRS is always the same.

Authentication type is Local X509 Certificate

Certificate: select created RTU certificate

50 1KGT 150 948 V005 1

Networks VPN Configuration with Sophos UTM

3.4.3.2 Create “New IPSec connection” @Sophos UTM

Click “Connections” Tab

Then Click on ”New IPSec connection...”

Use a useful name, like reuse defined VPN Network information and Station name:

e.g. RTU-Station_192.168.0.0/30===CS_172.16.100.0/24

Fill in ”Edit IPSec connection” form:

1KGT 150 948 V005 1 51

VPN Configuration with Sophos UTM Networks

3.4.4 Configure RTU

Start RTU500 engineering tool (RTUtil500) and open your project.

In the hardware tree select the CMU and switch to the tab where PPPx is enabled.

Fill in User name and Password for GPRS communication.

Click Dial up parameters.

52 1KGT 150 948 V005 1

Networks VPN Configuration with Sophos UTM

Fill in APN and PIN, if required:

Switch to the Ethernet interface tab, enable the VPN checkbox and click Configuration::

VPN settings need to be filled in regarding your definitions in chapter Preliminaries:

1KGT 150 948 V005 1 53

VPN Configuration with Sophos UTM Networks

Enable routing setting for PPP interface. Define network and netmask. Gateway is handled
automatically according to the dial-in server of your provider.

54 1KGT 150 948 V005 1

Networks VPN Configuration with Sophos UTM

3.4.5 Download X509 certificate @RTU

Download X509 certificate to RTU via webserver.

Open Hardware Tree:

And select “Network Interfaces”

Then click “VPN administration” tab:

To upload certificate, click “Browse…” button and select certificate file from your local drive:

1KGT 150 948 V005 1 55

VPN Configuration with Sophos UTM Networks

Enter transport password for certificate in the field: “Certificate file password”. Then click
“Upload certificate” and wait until the following message comes up:

After successful loaded certificate more details about the certificate will be displayed.

3.4.6 Establish communication

To establish communication restart RTU and check that the following System Diagnosis
events are displayed:

CMU x: VPN initialization successfully completed.

VPN: Tunnel 1 to remote network ‘xxx.xxx.xxx.xxx’ setup.

VPN: Tunnel 1 to remote network ‘xxx.xxx.xxx.xxx’ established.

ADVICE
When authentication using exchange of X.509 certificates is configured and authentication
will fail please check the validity period of the certificate, consisting of a not-before date
and a not-after date. The system time on the RTU500 must fall within the validity dates
of that certificate. If required a valid system time on the RTU500 within the period of the
certificate could be set once locally by synchronization using web server.

3.5 Templates
3.5.1 VPN IPSec encryption template

to communicate with VPN administrator:

RTU500 VPN IPSEC

RTU Public IP Address dynamic
RTU local virtual IP address ___.___.___.___
RTU local virtual network ___.___.___.___
RTU local virtual netmask ___.___.___.___ CIDR-Suffix /___
Customer Public IP ___.___.___.___
Address
Customer private (remote) ___.___.___.___
network
Customer private (remote) ___.___.___.___ CIDR-Suffix /___
netmask

56 1KGT 150 948 V005 1

Networks Templates

Policies
IKE Version
IKEv1

IKEv2

IKEv1 and IKEv2

Authentication
Preshared Key

RSA Key (certificates)

RSA Key (certificates) RSA key with FQDN (Fully Qualified Domain Name)

IKE (Phase 1) Parameter

IKE encryption algorithm
3DES 168 CBC

AES 128 CBC

AES 192 CBC

AES 256 CBC

BLOWFISH

DES 56 CBC
IKE authentication algorithm
AES128

MD5

SHA1

SHA256

SHA384

SHA512
IKE DH group
group 1: MODP 768 bit

group 2: MODP 1024 bit

group 5: MODP 1536 bit

group 14: MODP 2048 bit

group 15: MODP 3072 bit

1KGT 150 948 V005 1 57

Templates Networks

IKE (Phase 1) Parameter

group 16: MODP 4096 bit

group 17: MODP 6144 bit

group 18: MODP 8192 bit

IKE SA lifetime (Phase 1)
28800 sec

9600 sec

3600 sec

IPsec (Phase 2) Parameter

X ESP
IPSec encryption algorithm
3DES 168 CBC

AES 128 CBC

AES 192 CBC

AES 256 CBC

BLOWFISH

DES 56 CBC

NULL
IPSec authentication algo-
rithm AES128

MD5

SHA1

SHA256

SHA384

SHA512
IPSec DH group X group 2: MODP 1024 bit
IPSec SA lifetime (Phase 2)
28800 sec

9600 sec

58 1KGT 150 948 V005 1

Networks Templates

IPsec (Phase 2) Parameter

3600 sec
IPSec PFS (perfect forward
secrecy)
Compression not supported

3.5.2 CIDR List

CIDR Netmask IPs in subnet Hosts per subnet Comments

/32 255.255.255.255 1 1
/31 255.255.255.254 2 - Not usable
/30 255.255.255.252 4 2
/29 255.255.255.248 8 6
/28 255.255.255.240 16 14
/27 255.255.255.224 32 30
/26 255.255.255.192 64 62
/25 255.255.255.128 128 126
/24 255.255.255.0 256 254 Class C network
/23 255.255.254.0 512 510
/22 255.255.252.0 1.024 1.022
/21 255.255.248.0 2.048 2.046
/20 255.255.240.0 4.096 4.094
/19 255.255.224.0 8.192 8.190
/18 255.255.192.0 16.384 16.382
/17 255.255.128.0 32.768 32.766
/16 255.255.0.0 65.536 65.534 Class B network
/15 255.254.0.0 131.072 131070
/14 255.252.0.0 262.144 262.142
/13 255.248.0.0 524.288 524.286
/12 255.240.0.0 1.048.576 1.048.574
/11 255.224.0.0 2.097.152 2.097.150
/10 255.192.0.0 4.194.304 4.194.302
/9 255.128.0.0 8.388.608 8.388.606
/8 255.0.0.0 16.777.216 16.777.214 Class A network
/7 254.0.0.0 33.554.432 33.554.430
/6 252.0.0.0 67.108.864 67.108.862
/5 248.0.0.0 134.217.728 134.217.726
/4 240.0.0.0 268.435.456 268.435.454
/3 224.0.0.0 536.870.912 536.870.910
/2 192.0.0.0 1.073.741.824 1.073.741.822
/1 128.0.0.0 2.147.483.648 2.147.483.646
/0 0.0.0.0 all all all

1KGT 150 948 V005 1 59

Templates Networks

3.5.3 APN List for Germany

Provider APN Username Password

T-Mobile Internet.t-d1.de internet t-d1
Vodafone volume.d2gprs.de Internet d2

3.6 Parallel Redundancy Protocol (PRP)

3.6.1 Overview

The Parallel Redundancy Protocol (PRP) provides a standard method to obtain redundancy
in networks, using doubly attached nodes obeying to PRP (DANPss). PRP implements
redundancy functions in the end nodes rather than in network elements.

A doubly attached node DANP is attached to two independent Local Area Networks (LANss)
of similar topology, named LAN_A and LAN_B, which operate in parallel. A source DANP sends
the same frame over both LANss and a destination DANP receives it from both LANss within a
certain time, consumes the first frame and discards the duplicate.

The following figure shows a redundant network consisting of two LANss, each of which can
have any topology, e.g. tree, ring or meshed.

Source
SAN DANP DANP
A1
B- frame
A- frame

B ridge B ridge
Bridged Local Area
Bridged Local Area Network (tree)
Network (ring) LAN_B
LAN_A

B ridge B ridge B ridge B ridge

SAN
A2 RedBox SAN SAN
B1 B2

A- frame B- frame

DANP DANP DANP

SAN SAN
Desnaon R1 R2

Figure 28: PRP network consisting of two LANss with different topology
The two LANss have no connection between them and are assumed to be fail-independent.
Redundancy can be defeated by single points of failure, such as a common power supply or a
direct connection whose failure brings both networks down.

Additional to DANPss the networks can contain singly attached nodes (SANss). These nodes
can be attached in two ways:

60 1KGT 150 948 V005 1

Networks Parallel Redundancy Protocol (PRP)

• SANss can be attached directly to one LAN only. Such SANss can only communicate with
other SANss on the same LAN. For instance, in the figure above, SAN A1 can communicate
with SAN A2, but not with SAN B1 or SAN B2. SANss can communicate (not redundantly)
with all DANPss.
• SANss can be attached over a RedBox (redundancy box) to both LANss, as the figure
shows for SAN R1 and SAN R2. Such SANss can communicate with all DANP and SANss,
for instance SAN A1 and SAN R1 can communicate. These kind of SANss are named virtual
doubly attached node VANP too.
For further, detailed information see PRP standard documentation IEC 62439-3 [7].

3.6.2 PRP in RTU500 series

The RTU500 series supports PRP in different ways. As singly attached node SAN each RTU500
series CMU that provides at least one Ethernet interface can be used. As doubly attached
nodes only RTU500 series CMUss with two Ethernet interfaces can be used. The figure below
shows a simple RTU500 series PRP setup with SCI IEC 61850.

NCC via host protocol Web client to RTU

SCI IEC 61850

RTU560

SNTP Server 1 SNTP Server 2

RedBox RedBox

Ethernet Switch Ethernet Switch LAN B

LAN A

RedBox
RedBox

SAN IED SAN IED

The PRP implementation for the RTU500 series is defined by the following basic points:
• The RTU500 series supports the newer PRP-1 protocol (PRP 2012, IEC 62439-3 (2012)) only.
The older PRP-0 protocol is not supported by the RTU500 series.
• PRP is supported on CMUss with two Ethernet interfaces (e.g. 560CMR01, 540CID01, ...)
only.
• Up to 8 CMUss with PRP configuration are supported within a RTU560 rack system.

1KGT 150 948 V005 1 61

Parallel Redundancy Protocol (PRP) Networks

• The RTU500 series supports communication with other DANPss and SANss according to
the network restrictions.
• All network host and subdevice communication protocols can be used with PRP. There is
no restriction to certain protocols like IEC 61850.
• Other network functionality like web server, HMI or SNTP time synchronization works via
PRP as well. There is no restriction to certain network functionalities.
• The IPv4 routing of the network interfaces is not restricted when using PRP.
• The PRP connection status can be supervised by system events. See chapter “PRP
supervision” for more information.
• Protocol logging via CPTT is possible with PRP. See chapter “Protocol logging for
communication interfaces” for detailed information.
• The RTU500 series CMU redundancy can be used together with PRP. In this case a CMU
switch over is possible when both networks links of a CMU fail.
The following restrictions apply if using PRP on an RTU500 series CMU:
• In PRP configurations the RTU500 series CMU uses the same IP and MAC address on both
Ethernet interfaces. Therefore the connected LAN must have no connection between
them.
• PRP cannot be used together with VPN.
• PRP cannot be used via PPP or USB RNDIS.

3.6.3 PRP configuration

The PRP configuration can be found in RTUtil500 at the ‘E1’ tab of a CMU. The following figure
shows an example for a RTU560 with 560CMR01 and enabled PRP.

Figure 29: CMU parameters - Tab: E1

The main PRP CMU configuration parameters are:

Parameter name Default Parameter location

Enable PRP for Ethernet interfaces E1 and E2 disabled CMU - Network Interfaces
If enabled:
PRP for Ethernet interfaces.
PRP interface number 1 CMU - Network Interfaces
PRP interface number.
Value range: 1 to 8.

The notes below have to be considered for the PRP CMU configuration parameters:
• When enabling PRP a confirmation dialog is shown to acknowledge the usage.

62 1KGT 150 948 V005 1

Networks Parallel Redundancy Protocol (PRP)

• When enabling PRP the network interface tab ‘E2’ will be disabled. Network parameters
like IP address and subnet mask are configured on tab 'E1' for the PRP interface .
Additional to the main, specific PRP parameters are available. These parameters are set in a
separate dialog, shown when selecting the button ‘Configuration’ besides the PRP interface
number. An example is shown in the figure below.

The specific PRP configuration parameters are:

Parameter name Default Parameter location

PRP type PRP-1 CMU - Network Interfaces

PRP type.
Static value: PRP-1.
Node forget time 60 sec CMU - Network Interfaces
A connected PRP node is considered not reachable when the time elapsed since reception of a frame from that node over both
LANss exceeds the node forget time.
Value range: 10 to 320 sec.
Life check interval 10 sec CMU - Network Interfaces
Every life check interval a PRP node sends a supervision frame.
Value range: 2 to 60 sec.
Supervision MAC address 0x00 CMU - Network Interfaces
Every PRP node sends a supervision frame every life check interval to this multicast address. According to the standard, the
first 5 octets of this MAC address must match 01:15:4E:00:01. The last token of the supervision MAC address can be set here.
Value range: 0x00 to 0xfd.
CMU redundancy switch over in case of link disabled CMU - Network Interfaces
failure
Enables CMU switch over in case both PRP links of a CMU fails. Only visible if CMU has redundancy mode active or standby.

The notes below have to be considered for the specific PRP configuration parameters:
• The node forget time must be greater than the life check interval. It shall be set at least
two times the life check interval.
• The parameters supervision MAC address and life check interval must be set to the same
value for every PRP node in the network.
• The life check interval requires receiving and processing of a supervision frame from each
node in the network within the time interval. For performance considerations the interval
time shall not be set below 10 seconds (especially in large PRP configurations).

1KGT 150 948 V005 1 63

Parallel Redundancy Protocol (PRP) Networks

3.6.4 PRP supervision

The PRP connection status of a CMU and the PRP communication status of all connected
DANP nodes (devices) are supervised. The actual status can be derived from system events
provided by the RTU500.

The RTU500 PRP implementation supports the system events summarized in the following
table:

System event Description Shortcut

PRP interface n: Network interface E1 link up Signalize link status of inter- #277 - #284
face 'E1' using PRP interface n
to the next network device (e.g.
switch)
PRP interface n: Network interface E2 link up Signalize link status of inter- #285 - #292
face 'E2' using PRP interface n
to the next network device (e.g.
switch)
Device reachable on redundant line 1 Signalize communication status #180
to the referring subordinated
PRP device (node) via network
interface 'E1'
Device reachable on redundant line 2 Signalize communication status #181
to the referring subordinated
PRP device (node) via network
interface 'E2'

The system events ‘SEV#277 - #292 PRP interface n: Network interface Ex link up’ are located
at the system data interface of the CMU. The system event ‘SEV#180 - #181 Device reachable
on redundant line x’ are located at the system data interface of the subordinated PRP devices.

The meaning of the system event values are as defined in the table below:

System event Value Meaning

PRP interface n: Network interface Ex link up On Link of interface 'Ex' using PRP inter-
face n to the next network device is up
Off Link of interface 'Ex' using PRP inter-
face n to the next network device is
down
Device reachable on redundant line x On Subordinated PRP device reachable via
network interface ‘Ex’
Off Subordinated PRP device not reach-
able via network interface ‘Ex’

The following restrictions apply to the PRP system events:

• In case the system events ‘SEV#277 - #292 PRP interface n: Network interface Ex link up’ are
missing in PRP configurations, the affected system events are written to the configuration
file nevertheless. As result the system events are available in the system diagnosis in any
case.
• The system events ‘Device reachable on redundant line x’ are available only, if a PRP
interfaces is used with a SCI activity.

64 1KGT 150 948 V005 1

Networks IEEE 802.1X Port-based Network Access Control

• The system events ‘Device reachable on redundant line x’ are set by the PRP
implementation independent from the used communication protocol. It doesn’t represent
the connection status of the protocol. The protocol status is signalized by the system
event ‘Device inoperable’. Both system events shall show in normal situations the same
status. But due to different timeouts the status can differ when a device just connects or
disconnects.
• PRP doesn’t provide a supervision of SAN devices (nodes). These devices must be
supervised by other system events like ‘Device inoperable’.

3.7 IEEE 802.1X Port-based Network Access Control

3.7.1 Technology Overview

IEEE 802.1X is a security standard for port-based network access control that secures wired
networks against unauthorized access by requiring authentication with a central server
before network access and data transmission are allowed.

A port is a point of attachment to a network. IEEE 802.1X provides port-based network access
control that allows network access decisions made at the port, on a per-port basis using the
EAPOL (Extensible Authentication Protocol Over LAN). For a wired network, a port could be
where the MAC (Media Access Control) physically attaches to the network, such as a switch
port.

The purpose of IEEE 802.1X is authentication of Ethernet network equipment. Equipment that
is not authenticated will not even receive link. Only equipment that is authenticated should
get network access when connected to an Ethernet switch.

There is a client implementation of IEEE 802.1X in RTU500. That means RTU500 provides IEEE
802.1X supplicant role on Ethernet interface E1 and if present on E2 of a CMU module. The
RTU500 sends authentication information in the form of a X.509 certificate or username/
password to the authenticator and requests access to the network.

The supplicant uses EAPOL that uses data link layer (Layer 2) for communication with the
authenticator. The authenticator is the switch in the substation that controls access to the
network. The authenticator forwards authentication requests from the supplicant to the
authentication server. When the authenticator receives an EAPOL packet from the supplicant
it packets them in a radius format and then forwards them to the authentication server. The
authentication server checks if the supplicant should be allowed network access and reports
this back to the authenticator.

Before the RTU500 has allowed access the authenticator puts the access port in unauthorized
mode. In this mode only EAPOL traffic is allowed on the port. As soon as the RTU500 has
allowed access the port changes to authorized mode and other traffic is allowed.

3.7.2 EAP (Extensible Authentication Protocol)

IEEE 802.1X uses EAP to define how messages used for authentication are sent between
devices. EAP is using layer 2 (data link) and can therefore send information without valid IP
address.

RTU500 supports the following EAP types:

• EAP-TLS (X.509 certificate-based authentication)

• EAP-PEAPv0 with EAP-MSCHAPv2

1KGT 150 948 V005 1 65

IEEE 802.1X Port-based Network Access Control Networks

EAP-TLS (Transport Layer Security) is an IETF (Internet Engineering Task Force) open
standard that uses the TLS protocol, and is well-supported among vendors. RTU500 EAP
complies with the IETF RFC 5216: The EAP-TLS Authentication Protocol. EAP-TLS is an EAP
type that make use of TLS to perform mutual authentication between the client and server.
TLS exploits the properties of asymmetric cryptography by means of certificate exchange
between peers. EAP-TLS requires that both server-side and client-side certificates are
deployed. EAP-TLS uses PKI (Public Key Infrastructure) to secure communication to a RADIUS
(Remote Authentication Dial-In User Service) authentication server.

EAP-PEAPv0 (Protected EAP) uses server-side public key certificates to authenticate the
server. It then creates an encrypted TLS tunnel between the client and the authentication
server. The ensuing exchange of authentication information to authenticate the client is then
encrypted and user credentials are safe from eavesdropping. EAP-MSCHAPv2 (Microsoft-
Challenge-Handshake Authentication Protocol version 2) is tunneled through TLS as inner
authentication type for EAP-PEAPv0.

3.7.3 RTUtil500 configuration

The configuration parameters for IEEE 802.1X Port-based Network Access Control are defined
for each Ethernet interface within an RTU.

A checkbox "IEEE 802.1X Authentication" is available on Ethernet interface E1 and if present E2

tab of a CMU module to enable the supplicant functionality.

Parameter name Default Parameter location

IEEE 802.1X Authentication disabled CMU - Network Interfaces

If the option is checked,
IEEE 802.1X Port-based Network Access Control will be enabled.

The following parameters are configured in a separate dialog accessible via "Configuration"
button.

Parameter name Default Parameter location

EAP Identity CMU - Network Interfaces

The identity sent in response messages to the authenticator.
EAP-TLS disabled CMU - Network Interfaces
If the option is checked,
Extensible Authentication Protocol type Transport Layer Security (TLS) will be enabled.
Certificate-based authentication CMU - Network Interfaces
Select a certificate used for IEEE 802.1X authentication.
List items depend on certificate store configuration, that means prior to that list selection set an entry with descriptive text in
the certificate store of the CMU module to upload external certificates for the IEEE 802.1X authentication.
EAP-PEAPv0 disabled CMU - Network Interfaces
If the option is checked,
Extensible Authentication Protocol type Protected EAP (PEAPv0) will be enabled.
EAP-MSCHAPv2 disabled CMU - Network Interfaces
If the option is checked,
Extensible Authentication Protocol type Microsoft-Challenge-
Handshake Authentication Protocol version 2 (MSCHAPv2) will be enabled.
MSCHAPv2 User ID CMU - Network Interfaces
The user-id used in MSCHAPv2 handshakes.
MSCHAPv2 Password CMU - Network Interfaces
The password used in MSCHAPv2 handshakes.

66 1KGT 150 948 V005 1

Networks IEEE 802.1X Port-based Network Access Control

3.7.4 Certificate upload via the RTU500 Web server

A digital certificate is used to prove that someone is who they say they are. In an 802.1X
negotiation, the authentication server uses certificates to prove its identity to the supplicant.
The certificates used by the authentication server are called server certificates. The
certificates used by the supplicant are called client certificates. Server certificates are
required for EAP-TLS and EAP-PEAPv0. EAP-TLS requires that the RTU500 prove its identity
with a client certificate as well.

EAP-TLS requires an uploaded external certificate stored in the certificate store of the CMU
module. The web pages for certificate configuration require secure HTTPSS web server
access. It is not possible to open the web pages with standard HTTP access. For uploading
the generated certificate must be stored in PKCS#12 format.

The upload of an external generated certificate is done via the RTU500 Web server. In the Web
server menu the link "Certificate Management" is the entry point for the certificate upload.
This link can be found under the menu item "Management".

To upload a certificate the following steps have to be executed:

• Select the description of the certificate to upload in the column "Certificate description".
In the selection all in RTUtil500 configured entries of the certificate store appear. The
selection text is the descriptive name set in RTUtil500.
• Select a certificate file.
• Enter the private key passphrase by pressing the lock symbol.
When all steps are finished the certificate can be uploaded by pressing the button "Send
file to device". This button appears not before all required information are set. Further
information about the upload of external certificates can be found in User Manual RTU500
series Web Server Release 12 (1KGT 150 924).

1KGT 150 948 V005 1 67

IEEE 802.1X Port-based Network Access Control Networks

68 1KGT 150 948 V005 1

Glossary

4 Glossary
AES Advanced Encryption Standard

APN Access Point Name of GPRS Service Provider Network

CHAP Challenge Handshake Authentication Protocol

CMU Communication and Data Processing Unit

CS Control System

CSTD Carrier Setup Time Delay

CTS Clear to Send

CTTD Carrier Trailing Time Delay

DANP Doubly attached nodes obeying to PRP

DCD Data Carrier Detect

DES Data Encryption Standard

DH Diffie–Hellman key exchange

DNS Domain Name System

DSR Data Set Ready

DTR Data Terminal Ready

GPRS General Package Radio Service

GSM Global Standard for Mobile Communications

HMI Human Maschine Interface (here Integrated HMI function of the

RTU500 series)

HTTP Hypertext Transfer Protocol

IEC International Electrotechnical Commission

IED Intelligent Electronic Device

IEEE Institute of Electrical and Electronics Engineers

IKE Internet Key Exchange

LAN Local Area Network

Max Maximum

ms Millisecond

NCC Network Control Center

PC Personal Computer

PDP Process Data Processing

PIN Personal Identity Number

PPP Point to Point Protocol

1KGT 150 948 V005 1 69

 Glossary

PRP Parallel Redundancy Protocol

RADIUS Remote Authentication Dial-In User Service

RFC Request for Comments

RTS Request to Send

RTU Remote Terminal Unit

SAN singly attached PRP nodes

SCADA Supervision, Control and Data Acquisition

SCI Sub-Device Communication Interface

SIM Subscriber Identification Module

SLC Serial Line Controller

SNTP Simple Network Time Protocol (according to RFC 4330)

TCP/IP Transmission Control Protocol / Internet Protocol

UART Universal Asynchronous Receiver-transmitter

UDP User Datagram Protocol

USB Universal Serial Bus

VPN Virtual Private Network

70 1KGT 150 948 V005 1

 

1KGT 150 948 V005 1 71

  

Note:

The specifications, data, design or other information contained in this document (the
“Brochure”) - together: the “Information” - shall only be for information purposes and shall in
no respect be binding. The Brochure does not claim to be exhaustive. Technical data in the
Information are only approximate figures. We reserve the right at any time to make technical
changes or modify the contents of this document without prior notice. The user shall be
solely responsible for the use of any application example or information described within this
document. The described examples and solutions are examples only and do not represent any
comprehensive or complete solution. The user shall determine at its sole discretion, or as the
case may be, customize, program or add value to the ABB Power Grids Germany AG products
including software by creating solutions for the end customer and to assess whether and to
what extent the products are suitable and need to be adjusted or customized.

This product is designed to be connected to and to communicate information and data

via a network interface. It is the users sole responsibility to provide and continuously
ensure a secure connection between the product and users or end customers network
or any other network (as the case may be). The user shall establish and maintain any
appropriate measures (such as but not limited to the installation of firewalls, application
of authentication measures, encryption of data, installation of anti-virus programs, etc) to
protect the product, the network, its system and the interface against any kind of security
breaches, unauthorized access, interference, intrusion, leakage and/or theft of data or
information. ABB Power Grids Germany AG is not liable for any damages and/or losses related
to such security breaches, any unauthorized access, interference, intrusion, leakage and/or
theft of data or information.

ABB Power Grids Germany AG shall be under no warranty whatsoever whether express or
implied and assumes no responsibility for the information contained in this document or for
any errors that may appear in this document. ABB Power Grids Germany AG's liability under
or in connection with this Brochure or the files included within the Brochure, irrespective
of the legal ground towards any person or entity, to which the Brochure has been made
available, in view of any damages including costs or losses shall be excluded. In particular ABB
Power Grids Germany AG shall in no event be liable for any indirect, consequential or special
damages, such as – but not limited to – loss of profit, loss of production, loss of revenue, loss
of data, loss of use, loss of earnings, cost of capital or cost connected with an interruption of
business or operation, third party claims. The exclusion of liability shall not apply in the case
of intention or gross negligence. The present declaration shall be governed by and construed
in accordance with the laws of Switzerland under exclusion of its conflict of laws rules and of
the Vienna Convention on the International Sale of Goods (CISG).

ABB Power Grids Germany AG reserves all rights in particular copyrights and other intellectual
property rights. Any reproduction, disclosure to third parties or utilization of its contents -
in whole or in part - is not permitted without the prior written consent of ABB Power Grids
Germany AG.

© Copyright ABB Power Grids Germany AG 2020

All rights reserved

72 1KGT 150 948 V005 1

 

1KGT 150 948 V005 1 73

Visit us

ABB Power Grids Germany AG

P.O. Box 10 03 51
68128 Mannheim, Germany

www.abb.com/remote-terminal-units

1KGT 150 948 V005 1