Westermo MR Series - Manual (Page 151)

151 6622-3201
Web Interface and Command Line Reference Guide www.westermo.com
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 concentrator it will send an IKE request
to the concentrator. The 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 concentrator will use this ID and look through the eroutes configured and dynam-
ic eroutes 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 eroute is found, the local user configuration is used
to locate the password, and a normally configured eroute 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 eroute. As long as the dynamic eroute exists, it behaves just like a nor-
mal eroute. i.e. SAs are replaced/removed as required.
If errors are received from the MySQL database, or not enough fields are returned, the dynamic
eroutes are removed, and IKE negotiations in progress will be terminated. There are a limited
number of dynamic eroutes. If the number of free dynamic eroutes is less than 10% of the total
number of dynamic eroutes, the Westermo router will periodically remove the oldest dynamic
eroutes. This is done to ensure that there will always be some free dynamic eroutes available for
incoming connections from remote routers. It is possible to view the current dynamic tunnels that
exist using the WEB server, browse to Status > IPSec > Dynamic Tunnels. The table will indicate
the base eroute and the Remote Peer ID in the status display to help identify which remote sites
are currently connected.
Preliminary Eroute confi guration:
The eroute configuration Configure > IPSec > Eroutes > Eroute n differs from a normal configu-
ration 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 unit 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 inter-
rogated. So that the unit can make this decision, the remote router must supply an ID that
matches the peerid configured into the eroute. Wildcard matching is supported which means
that the peerid may contain ’*’ and ’?’ characters. If only one eroute 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.
All other fields should be configured as usual. It is possible to set up other Egroups linked with
other eroutes. This would be done if there is a second group of remote sites that have a differ-
ent set of local and remote subnets, or perhaps different encryption requirements. The only real
requirement is that this second group uses peer IDs that do not match up with those in use by the
first egroup.