User`s guide

200
VPN Concentrator acting as a responder to a session initiated from the remote site
When a remote site needs to create an IPsec SA with the VPN Concentrator it will send an
IKE request to the VPN Concentrator. The VPN Concentrator needs to be able to confirm
that the remote device is authorised to create an IPsec tunnel. The remote site will supply
its ID to the host during the IKE negotiations. The VPN Concentrator will use this ID and
look through the IPsec tunnels configured and dynamic IPsec tunnels to see if the supplied
ID matches the configured Peer ID (peerid). If a match is found, the MYSQL database is
queried to retrieve the information required to complete the negotiation (e.g. pre-shared
key/password). If no matching base IPsec tunnel is found, the local user configuration is
used to locate the password, and a normally configured IPsec tunnel must also exist. Once
the information is retrieved from the MySQL database, IKE negotiations continue and the
created IPsec SAs will be associated with the dynamic IPsec tunnel. As long as the dynamic
IPsec tunnel exists, it behaves just like a normal IPsec tunnel. i.e. SAs are
replaced/removed as required.
If errors are received from the MySQL database, or not enough fields are returned, the
dynamic IPsec tunnel is removed, and IKE negotiations in progress will be terminated. There
are a limited number of dynamic IPsec tunnel. If the number of free dynamic IPsec tunnel is
less than 10% of the total number of dynamic IPsec tunnel, the Digi router will periodically
remove the oldest dynamic IPsec tunnel. This is done to ensure that there will always be
some free dynamic IPsec tunnel available for incoming connections from remote routers. It
is possible to view the current dynamic tunnels that exist using the WEB server, browse to
Management - Connections > Virtual Private Networking (VPN) > IPsec. The table
will indicate the base IPsec tunnel and the Remote Peer ID in the status display to help
identify which remote sites are currently connected.
Preliminary IP Tunnel configuration
The IPsec tunnel configuration Configuration – Network > Virtual Private Networking
(VPN) > IPsec > IPsec Tunnels > IPsec n differs from a normal configuration in the
following ways:
• Peer IP/hostname: Because the peer IP address to each peer is unknown and is
retrieved from the database, this field is left empty.
• Bakpeerip (CLI only): Because the peer IP address to each peer is unknown and is
retrieved from the database, this field is left empty.
• Peer ID: When the host Digi is acting as a responder during IKE negotiations, the
router uses the ID supplied by the remote to decide whether or not the MySQL
database should be interrogated. So that the Digi can make this decision, the remote
router must supply an ID that matches the peerid configured into the IPsec tunnel.
Wildcard matching is supported which means that the peerid may contain '*' and '?'
characters. If only one IPsec tunnel is configured, the peerid field may contain a '*',
indicating that all remote IDs result in a MySQL look up.
• Local subnet IP address / Local subnet mask: Configured as usual.
• Remote subnet IP address / Remote subnet mask: These fields should be configured
in such a way that packets to ALL remote sites fall within the configured subnet. e.g.
if there are two sites with remote subnets 192.168.0.0/24, and 192.168.1.0/24
respectively, a valid configuration for the host would be 192.168.0.0/23 so that
packets to both remote sites match.