Online help

VPN

A VPN (virtual private network) is used to connect IP end devices or entire networks with each other, in a safe way. The data is transmitted tamper-proof to a destination and cannot be read by third parties.

You can configure the router for an OpenVPN, IPsec, GRE or DMVPN connection. A VPN connection is added as an interface in the router and can then be used for routing - like a network interface.

The exact proceeding for creating a certificate structure and configuring a VPN participant is described in a series of configuration guides. These are available from our website or our support team.

OpenVPN

You can use the router as OpenVPN server or OpenVPN client.

The following figure shows a sample configuration for an OpenVPN connection. One router is configured as OpenVPN server and a second as OpenVPN client here. Both, client as well as server can be replaced by any OpenVPN-capable devices. In the example, a WWAN connection between the two devices exists. Via this WWAN connection, an OpenVPN connection is established.

As soon as a WAN connection has been established, IP connections between both networks can be established. OpenVPN uses an existing WAN connection to establish a VPN tunnel. A tunnel consists of an IP connection, which transports all packets to be tunnelled in its payload. OpenVPN will make a virtual network card available for sending data traffic.

In the sample configuration, the end points of the OpenVPN connection will have the IP addresses 10.1.0.1 and 10.1.0.2. The OpenVPN tunnel will be established within an already existing WAN connection. The OpenVPN clients and servers must also know which network is located behind the according tunnel ends. In the sample configuration, this is the network 192.168.200.0/24 on one side. On the other side, this is the network 192.168.1.0/24. As soon as the tunnel is established, data for these target networks is sent through the OpenVPN tunnel. If only data with a target in the network behind the tunnel end are to be transmitted via the WAN interface, it is recommended to enable the firewall after successful configuration. This will limit the communication to the port at which the OpenVPN tunnel is established (standard setting: UDP port 1194).

The router supports the following authentication methods when establishing the VPN tunnel:

  • User name/password and CA certificate One or several clients can establish an encrypted connection to an OpenVPN server with this. The routers identifies itself with the common CA certificate and a user name/password combination at the server. This authentication method is only available for the router as client.
  • Certificate-based One or several clients can establish an encrypted connection to an OpenVPN server with this. The authentication is made using a previously generated certificate structure where the router has been assigned an own certificate and a private key with this. This authentication method is recommended due to a significantly increased security.
  • Certificate-based + tls-auth: A static key will be used for authentication in addition to the certificate-based authentication with this.

For detailed information and troubleshooting, we also recommend the OpenVPN web site:

IPsec

IPsec (Internet Protocol Security) is a protocol suite for the safe communication via IP networks and can be used to set-up virtual private networks (VPN). Two subnets can be connected together using two suitable routers via a secure tunnel.

In the sample configuration, an IPsec tunnel will be established to the remote terminal with the domain remote-domain.com. The IPsec tunnel will be established within an already existing WAN connection. The IPsec peers must know which network is located behind the according tunnel ends. The local (own) subnet has the address 192.168.200.0/24. The subnet of the remote terminal is 192.168.200.0/24. The local tunnel address is in the local subnet and is here 192.168.1.1. It will be assigned to an IPsec interface and must not already be used by another Ethernet participant in the network. This interface device allows to apply routes or netfilter rules to this interface without having to use IP addresses. As soon as the tunnel is established, data for these target networks is sent through the IPsec tunnel.

The authentication of the two communication partners is accomplished either using a pre-shared key (PSK) or certificates. Available protocols for key exchange are IKEv1 or IKEv2 (Internet Key Exchange version 1 or 2). IKEv1 provides the authentication modes Main or Aggressive. The main mode transmits all authentication data encrypted, what makes this method safer. The aggressive mode works without encryption, what makes this method faster. The aggressive mode can only be used for authentication with PSK. It is STRONGLY recommended not to use Aggressive mode for reasons of security. In contrast to IKEv1, IKEv2 facilitates an easier, more flexible and less error-prone initiation of IPsec connections. The authentication encryption is defined by the IKE key parameters. These can be negotiated automatically or set fix. The authentication phase of the IKE protocol is also called phase 1.

Upon authentication and key exchange (IKE), a so-called security association (SA) will be negotiated with the remote terminal, that represents the actual IPsec tunnel. This is also considered as phase 2 of the tunnel establishment. The communication encryption is defined by the IPsec key parameters. These can be negotiated automatically or set fix. The encryption algorithms and the hash method can differ from the IKE settings, but must correspond to those of the remote terminal, if they are set fix. If Diffie-Hellman parameters are also used with fix set key parameters, perfect forward secrecy (PFS) will also be used. With this, the keys will be re-calculated and no information from the previously generated SAs will be included. This ensures that nobody can infer the new keys from the previously generated keys.

If no remote terminal is specified for an IPsec configuration, a tunnel cannot be started directly. In this case, the device only reacts on incoming IKE requests; it operates as so-called responder. If a remote terminal is specified, the router initiates an IKE negotiation; it operates as so-called initiator.

GRE

The Generic Routing Encapsulation protocol allows to transmit data transparently through an existing connection without changing the original packets. This rolls out a virtual network that includes the participating devices in the same address space. This facilitates communication between each other since addressing is easier. In addition, possible addressing conflicts can be solved with the new, virtual addresses.

The sample configuration shows a GRE network where the individual peers have the local tunnel end addresses 10.1.0.1, 10.1.0.2 and 10.1.0.3. These tunnel ends can be accessed from outside using the domains remote-domain_1.com, remote-domain_2.com and remote-domain_3.com. The own IP addresses are accordingly 192.168.1.1, 192.168.2.1 and 192.168.3.1. The GRE connection will be established within an already existing WAN connection to the public IP address or domain name of the remote terminal. Please note that GRE is not a virtual private network in its classical meaning since it is not encrypted and not "private" therefore.

DMVPN

The Dynamic Multipoint Virtual Private Network (DMVPN) is used in hub-and-spoke networks and supports direct connections between the spokes. The implementation on INSYS routers that act as spokes does not yet support direct spoke connections, but only connections to other spokes via the hub. For a DMVPN connection, a IPsec tunnel to the hub will be established first. Then, a GRE tunnel will be established in this IPsec tunnel. IPsec encryption can be deactivated optionally.

Back to overview