Skip to main content

IPsec Tunnel

Tips

For an introduction to IPsec, tunnel configuration, VPN modes, configuration scenarios, and authentication options, see the IPsec chapter in the Configuration Pages of the respective Router Manual.

Certificate Generation

The following procedure describes how to generate certificates and keys without a passphrase:

Below are examples of certificate generation using a passphrase ("router") for the server and client certificates (the CA remains unchanged):

The IPsec configuration supports the following identifier (ID) types for the Remote ID and Local ID parameters:

  • IP address (for example, 192.168.1.1)
  • DN (for example, C=CZ,O=CompanyName,OU=TP,CN=A)
  • FQDN (for example, @director.companyname.cz) — the @ symbol precedes the FQDN.
  • User FQDN (for example, director@companyname.cz)

Tips

Certificates and private keys must be in PEM format. Use only certificates that contain the standard -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tags.

The interval after which the router renegotiates new keys is randomized as follows:

Lifetime − (Rekey Margin + random value in range ⟨0, Rekey Margin × Rekey Fuzz / 100⟩)

With default settings, the key renegotiation occurs within the following time range:

  • Minimum time: 1 h − (9 min + 9 min) = 42 min
  • Maximum time: 1 h − (9 min + 0 min) = 51 min

IPsec Status — Tunnel Established

Selecting the IPsec option in the Status menu of the web interface displays information about established IPsec tunnels. If a tunnel is built correctly, the screen will show ESTABLISHED and indicate that 1 up IPsec connection is active (highlighted in orange in the figure below). If the log shows "0 up," the tunnel was not created!

IPsec Status
IPsec Status

Examples of Use

IPv6 IPsec Tunnel over IPv4 Internet

IPv6 IPsec tunnel over IPv4 Internet — two Advantech routers
IPv6 IPsec tunnel over IPv4 Internet — two Advantech routers

This example demonstrates the establishment of an IPsec tunnel for an IPv6 network. Two Advantech v3 routers are used—one as the IPsec initiator and one as the IPsec responder. Although both routers connect to the Internet via IPv4, the communication within the established tunnel is IPv6, thereby connecting IPv6 networks on both sides.

Initiator configuration of the IPv6 over IPv4 IPsec tunnel
Initiator configuration of the IPv6 over IPv4 IPsec tunnel
Responder configuration of the IPv6 over IPv4 IPsec tunnel
Responder configuration of the IPv6 over IPv4 IPsec tunnel
IPsec Status of the Initiator
IPsec Status of the Initiator
IPsec Status of the Responder
IPsec Status of the Responder

Advantech Router and Cisco Basic IPsec Tunnel Configurations

Warning

There is a known bug in Cisco ASA 5500-X Series Firewalls: IKEv2 between ASA and strongSwan (using IKEv2 with AES256/SHA256) does not work. More information is available at Cisco Bug CSCvb21927.

IKEv1 Pre-shared Key Tunnel

Advantech Router as IPsec Initiator

The IP address of the SIM card in the Advantech router can be static or dynamic since the IPsec tunnel is initiated by the router. In this configuration, the Linux server (Cisco router) offers IPsec tunnel services and must have a static IP address or a resolvable domain name.

IPsec tunnel — initiator on the router
IPsec tunnel — initiator on the router

If the tunnel endpoints are directly visible, specify these items: Description, Remote IP Address, First Remote Subnet, First Remote Subnet Mask, First Local Subnet, and First Local Subnet Mask. If one end is behind a private network, enable Force NAT Traversal by setting it to yes.

If NAT Traversal is active, you must also set Remote ID to the fully qualified domain name (FQDN) of the remote device. Certificate-based authentication can also be used; in that case, Remote ID is not required.

Below is an example of IPsec tunnel settings for an initiator:

ItemValue
Remote IP Address83.208.155.127
Remote IDciscoasa@default.domain
First Remote Subnet192.168.1.0
First Remote Subnet Mask255.255.255.0
First Local Subnet192.168.3.0
First Local Subnet Mask255.255.255.0
Force NAT Traversalyes
Pre-shared Keytest

Other parameters may be left at their default values. If the Remote IP Address field is empty on one side of the tunnel, that side will wait for a connection rather than initiating one.

IPsec tunnel — example configuration of initiator on the router
IPsec tunnel — example configuration of initiator on the router

Information about the active IPsec tunnel can be viewed in the Status section of the IPsec page on the router’s web interface.

Advantech Router as IPsec Responder

When the Advantech router acts as the responder, it must have an available static IP address or use a dynamic IP (with DynDNS translation). In this case, the Linux server (Cisco router) initiates the tunnel.

IPsec tunnel — responder on the router
IPsec tunnel — responder on the router

If the endpoints are directly visible, specify these items: Description, First Remote Subnet, and First Remote Subnet Mask. If one end is behind a private network, enable Force NAT Traversal (set to yes).

If NAT Traversal is enabled, you must also set Remote ID (FQDN format). Certificate-based authentication is an alternative that does not require entering a Remote ID.

Below is an example of IPsec tunnel settings for a responder:

ItemValue
Remote IDciscoasa@default.domain
First Remote Subnet192.168.2.219
First Remote Subnet Mask255.255.255.255
Force NAT Traversalyes
Pre-shared Keytest

Other parameters may be left at their default values. If the Remote IP Address field is empty, that side will wait for a connection rather than initiating one.

IPsec tunnel — example configuration of responder on the router
IPsec tunnel — example configuration of responder on the router

Active IPsec tunnel information is available in the Status section on the IPsec page of the router’s web interface.

Linux Server IPsec Configuration

IPsec tunnel — Linux server
IPsec tunnel — Linux server

On the Linux server, configure the ipsec.conf and ipsec.secrets files. For example, an ipsec.conf file might look like this:

The ipsec.secrets file should contain:

83.208.155.127 172.24.68.112: PSK "test"

Cisco Router as Initiator — IPsec Configuration

Warning

Cisco routers support IPsec protocol starting with IOS version 7.1.

IPsec tunnel — Cisco router as initiator
IPsec tunnel — Cisco router as initiator

Below is an example Cisco configuration for an IPsec tunnel as initiator:

Cisco Router as Responder — IPsec Configuration

Warning

Cisco routers support IPsec protocol starting with IOS version 7.1.

IPsec tunnel — Cisco router as responder
IPsec tunnel — Cisco router as responder

Example configuration for a Cisco router acting as the responder:

Detailed Certificate Generation

This section describes how to generate certificates and keys on a Linux- or Windows-based machine.

1. Certification Authority — ca.key, ca.csr, ca.crt

  • Create the working directory and initialize the certificate database:
    mkdir certs; cd certs; touch index.txt
  • Copy the openssl.conf configuration file into the working directory (see Appendix A).
  • Generate the CA private key:
    openssl genrsa -des3 -out ca.key 2048
  • Generate the certificate signing request (CSR):
    openssl req -verbose -new -key ca.key -out ca.csr -sha256
  • Self-sign the CA certificate:
    openssl ca -create_serial -extensions v3_ca -config ./openssl.conf -out ca.crt -keyfile ca.key -verbose -selfsign -md sha256 -enddate 301231235959Z -infiles ca.csr
  • Verify the CA certificate:
    openssl x509 -noout -text -in ca.crt

2. Server Certificate — server_cisco.key, server_cisco.csr, server_cisco.crt

  • Generate the server private key:
    openssl genrsa -des3 -out server_cisco.key 2048
  • Generate the certificate signing request (see Appendix B for an example server_req.conf):
    openssl req -verbose -new -key server_cisco.key -out server_cisco.csr -config server_req.conf
  • Sign the server certificate using the CA:
    openssl ca -config ./server_req.conf -extensions v3_req -enddate 301231235959Z -out server_cisco.crt -keyfile ca.key -infiles server_cisco.csr
  • Verify the server certificate:
    openssl x509 -noout -text -in server_cisco.crt

3. Client Certificate — client_router.key, client_router.csr, client_router.crt

  • Generate the client private key:
    openssl genrsa -des3 -out client_router.key 2048
  • Generate the certificate signing request (see Appendix C for an example client_req.conf):
    openssl req -verbose -new -key client_router.key -out client_router.csr -config client_req.conf
  • Sign the client certificate using the CA:
    openssl ca -config ./client_req.conf -extensions v3_req -enddate 301231235959Z -out client_router.crt -keyfile ca.key -infiles client_router.csr
  • Verify the client certificate:
    openssl x509 -noout -text -in client_router.crt

4. Verify That the Certificates and Keys Match

The modulus hashes of the certificate and its corresponding private key must be identical:

openssl x509 -noout -modulus -in [client_router/server_cisco].crt | openssl md5
openssl rsa -noout -modulus -in [client_router/server_cisco].key | openssl md5

How to Import Certificates to Cisco

This section shows how to import the CA, server key, and server certificates to a Cisco device.

  1. configure terminal

  2. crypto pki trustpoint server.cisco

    no revocation-check
enrollment terminal pem
exit

  3. crypto pki import server.cisco pem terminal password <password>

    paste ca certificate in PEM format
paste encrypted private server key in PEM format
paste server certificate in PEM format
exit

  4. crypto pki certificate map ike_v2_certmap 10

    subject-name co client

  5. show crypto pki trustpoint server.cisco status

Note: If Cisco is configured by copy/paste via terminal, private keys are not imported (only CA and cert are imported). In this case, use the following commands to import the private key:

  1. crypto key import rsa <name> terminal <password>
  2. crypto pki trustpoint <name>
    rsakeypair <name>

IKEv1 Certificate-Based Tunnel

This section describes how to set up an IKEv1 certificate-based tunnel between a Cisco device (responder) and an Advantech router (initiator). See Detailed Certificate Generation for certificate generation and How to Import Certificates to Cisco for import instructions.

Cisco Device Configuration

  1. configure terminal

  2. crypto pki certificate map ikev1_map 10

    subject-name co client

  3. crypto isakmp policy 10

    encr aes 256
hash sha256
group 14

  4. crypto isakmp identity dn (identity is the DN of the server.cisco certificate)

  5. crypto isakmp profile ikev1

    ca trust-point server.cisco
match certificate ikev1_map
local-address <IP address>

  6. crypto map ike_v1_map 10 ipsec-isakmp

    set peer <IP address>
set transform-set aeset
set isakmp-profile ikev1
match address ike_v2_acl

  7. interface GigabitEthernet0

    ip address <IP address> <mask>
duplex auto
speed auto
no keepalive
crypto map ike_v1_map

  8. exit

  9. Verify the IKE security associations: show crypto isakmp sa detail

Advantech Router Configuration

IKEv2 Certificate-Based Tunnel

This section describes how to set up an IKEv2 certificate-based tunnel between a Cisco device (server/responder) and an Advantech router (client/initiator). See Detailed Certificate Generation and How to Import Certificates to Cisco.

Cisco Device Configuration

  1. configure terminal

  2. crypto ikev2 authorization policy ike_v2_policy

    crypto ikev2 proposal ike_v2_proposal
encryption aes-cbc-256
integrity sha256
group 14

  3. crypto ikev2 policy ike_v2_policy

  4. crypto ipsec transform-set aeset esp-aes 256 esp-sha256-hmac

    mode tunnel

  5. crypto map ike_v2_map 10 ipsec-isakmp

    set peer <IP address>
set transform-set aeset
set ikev2-profile ike_v2_profile
match address ike_v2_acl

  6. ip access-list extended ike_v2_acl

    permit ip <local subnet> 0.0.0.255 <remote subnet> 0.0.0.255

  7. interface GigabitEthernet0

    ip address <IP address> <mask>
duplex auto
speed auto
no keepalive
crypto map ike_v2_map

  8. exit

  9. Verify: show crypto ikev2 session and show crypto ipsec sa

Advantech Router Configuration

IKEv2 with Asymmetric Pre-Shared Key

This section describes how to set up an IKEv2 tunnel with an asymmetric pre-shared key between a Cisco device and an Advantech router. Each side authenticates using a different pre-shared key: the Cisco device uses cisco as its local key and expects router from the remote peer, while the Advantech router uses router as its local key and expects cisco from the remote peer.

Cisco Device Configuration

Advantech Router Configuration

Windows Computer IPsec Tunnel with Advantech Router

This example uses policy-based mode. For a comparison of both VPN modes, see Policy-based vs. Route-based VPN.

IPsec tunnel — Windows
IPsec tunnel — Windows

The recommended IPsec client for Windows is NCP Secure Entry Client, which is the basis for the following configuration description.

Windows IPsec Configuration — NCP Secure Entry Client

NCP Secure Entry Client
NCP Secure Entry Client

First, create a new profile for the IPsec tunnel. Select the Configuration tab and then select Profiles.

NCP Secure Entry Client — profiles
NCP Secure Entry Client — profiles

Click Add/Import to create a new profile. On the second screen, enter a profile name. The remaining screens can be confirmed with Next (or Finish on the last screen); configure all other settings later. To configure the IPsec tunnel, select the profile and click Edit.

NCP Secure Entry Client — edit
NCP Secure Entry Client — edit

Select IPsec General Settings in the left-hand menu, then click the Policy Editor... button on the right.

NCP Secure Entry Client — IPsec general settings
NCP Secure Entry Client — IPsec general settings

In the Policy Editor window, select the Pre-shared Key item under the IKE Policy section and click Edit.

NCP Secure Entry Client — policy editor
NCP Secure Entry Client — policy editor

In the window that opens, select the desired encryption and hash algorithms, then confirm by clicking OK.

NCP Secure Entry Client — pre-shared key
NCP Secure Entry Client — pre-shared key

Next, select the ESP - AES128 - MD5 item in the IPsec Policy section and click Edit.

NCP Secure Entry Client — policy editor
NCP Secure Entry Client — policy editor

In the new window, enter the desired policy name and select the encryption and hash algorithms. Confirm by clicking OK.

NCP Secure Entry Client — IPsec policy
NCP Secure Entry Client — IPsec policy

Return to the main IPsec General Settings window and set the IKE Policy and IPsec Policy fields according to the configuration defined in the previous steps. Set IKE DH Group to DH-Group 2 (1024 bit).

NCP Secure Entry Client — IPsec general settings
NCP Secure Entry Client — IPsec general settings

Select Identities in the left-hand menu and fill in the configuration form as shown below.

NCP Secure Entry Client — identities
NCP Secure Entry Client — identities

The same IP address must also be entered on the IPsec Address Assignment page.

NCP Secure Entry Client — IPsec address assignment
NCP Secure Entry Client — IPsec address assignment

On the Split Tunneling page, click Add and enter the IP address of the subnet behind the Advantech router and the corresponding subnet mask. Confirm by clicking OK.

NCP Secure Entry Client — add IP network
NCP Secure Entry Client — add IP network
NCP Secure Entry Client — split tunneling
NCP Secure Entry Client — split tunneling

Advantech Router IPsec Configuration

Advantech router IPsec configuration
Advantech router IPsec configuration

Advanced IPsec Configurations

This section covers advanced IPsec configuration scenarios: Multiple Clients, Static Routes, and Dynamic Routing. The examples use route-based mode, but all scenarios are equally applicable to policy-based mode when the Enabled Installing Routes option is used.

For further background, refer to the Route-based VPNs page on the strongSwan website.

Multiple Clients

This example demonstrates the configuration of multiple IPsec clients, where one Advantech router acts as the server and assigns IP addresses to all clients. For more information, see the Virtual IP strongSwan webpage.

Server configuration
Server configuration
Client configuration
Client configuration
Server IPsec status
Server IPsec status
Client IPsec status
Client IPsec status
Server route table
Server route table
Client route table
Client route table

Static Routes

This example demonstrates the configuration of an IPsec server and client where routes are installed statically by the FRR/zebra and FRR/staticd applications configured in the FRR Router App, which must be installed and configured on both routers. For more information, see the FRRouting User Guide.

Server configuration
Server configuration
Client configuration
Client configuration
Server FRR static configuration
Server FRR static configuration
Client FRR static configuration
Client FRR static configuration
Client and server FRR Zebra configuration
Client and server FRR Zebra configuration
Server FRR status overview
Server FRR status overview
Client FRR status overview
Client FRR status overview
Server IPsec status
Server IPsec status
Server route table
Server route table
Client IPsec status
Client IPsec status
Client route table
Client route table

Dynamic Routing

This example demonstrates the configuration of two routers where routes are installed dynamically by the FRR/zebra and FRR/BGP applications configured in the FRR Router App, which must be installed and configured on both routers. For more information, see the FRRouting User Guide.

Client 1 configuration
Client 1 configuration
Client 2 configuration
Client 2 configuration
Client 1 FRR BGP configuration
Client 1 FRR BGP configuration
Client 2 FRR BGP configuration
Client 2 FRR BGP configuration
Client 1 FRR Zebra configuration
Client 1 FRR Zebra configuration
Client 2 FRR Zebra configuration
Client 2 FRR Zebra configuration
Client 1 FRR status overview
Client 1 FRR status overview
Client 2 FRR status overview
Client 2 FRR status overview
Client 1 IPsec status
Client 1 IPsec status
Client 1 route table
Client 1 route table
Client 2 IPsec status
Client 2 IPsec status
Client 2 route table
Client 2 route table

Known Issues

Several Subnets in one CHILD_SA

If you use IKEv2, some peers (for example, devices by Checkpoint, Cisco, and Fortinet) may not support multiple subnets within a single CHILD_SA. (For further details, see the Interoperability page.)

Tips

If you are using strongSwan with a different IPsec solution, consult Interoperability before contacting technical support.

Appendices

Appendix A: openssl.conf

Appendix A: openssl.conf
Below is an example OpenSSL configuration file used primarily for generating certificate requests.

Appendix B: server_req.conf

Appendix B: server_req.conf
Below is an example configuration file for a server certificate request.

Appendix C: client_req.conf

Appendix C: client_req.conf
Below is an example configuration file for a client certificate request.