The IPsec client database is a database configured in the (config>ipsec>client-db) CLI context, which can be used to authenticate and authorize IKEv2 dynamic LAN-to-LAN tunnels.
Each client database contains one or more client entries. When the system receives a new tunnel request, it performs a look up in the associated database of the IPsec gateway (ipsec-gw). If there is match, the system optionally could use credentials configured in the matched client entry to authenticate the peer. If the authentication succeeds, then, optionally, the matched entry could also return certain IPsec parameters such as the private service ID which can be used for tunnel setup.
If the client database lookup failed to return a match result, then the system can either fall back to the ipsec-gw level configuration or fail the tunnel setup. The action to take depends on the CLI configuration.
The system supports one of the following as matching input:
the peer’s tunnel IP address
the peer’s IDi
a combination of both
The above matching input is defined in the match-list context in the client-db configuration. Each client entry contains client matching criteria that corresponds to the match list. The system correlates matching input with the client matching criteria of each client entry in the client-db configuration. The system supports the following matching methods:
for the peer's IDi
Any matches any IDi.
IPv4/IPv6 prefix matches the peer’s address type IDi to a configured prefix. It is considered a match if the IDi falls within the prefix.
FQDN matches the peer’s FQDN type IDi to a string. This supports a complete string match or a suffix string match.
RFC822 matches the peer’s RFC 822 type IDi to a string. This supports a complete string match or suffix string match.
for the peer's tunnel IP address
Matches the peer’s tunnel address to a configured prefix. It is a match if the IDi fall within the prefix.
IPv4 Any matches any IPv4 address.
IPv6 Any matches any IPv6 address.
Each client entry has a client index (an integer). This is different from a client identification. If there are multiple matched entries in a lookup, the client entry with the smallest client index is used. The client entry supports using a pre-shared key as the credential.
If the credential is not configured in the matched entry, the credential configured under the ipsec-gw context is used.
A client entry could optionally return the following IPsec parameters:
a private service ID
a private interface name
a tunnel-template ID
a Ts list
The returned parameter overrides the configuration of the ipsec-gw level.
There is only one client-db for each ipsec-gw, but different ipsec-gw configurations can use the same client-db.
Note that the encapsulated-ip-mtu command in the client-db returned tunnel-template is not applied to the IKE packet fragmentation. The encapsulated-ip-mtu command configured in the config>ipsec>tunnel-template context is used instead. However, the client-db returned encapsulated IP MTU value still applies to the ESP packet fragmentation.
A client entry in a shutdown state is skipped while the system performs the matching process.
If the configuration returned by client-db is invalid, the system fails the tunnel setup.
The reference of the client-db under the ipsec-gw context can be changed without shutting down ipsec-gw
Shutting down a referenced client-db without shutting down ipsec-gw is allowed and the established tunnel is not impacted. The system uses the configuration on the ipsec-gw level for new a tunnel request while the client-db is shutdown if a fallback is configured.
Adding a new client in a referenced client-db without shutting down ipsec-gw or client-db is allowed.
Removing a client in the referenced client-db without shutting down ipsec-gw or client-db is allowed. However, the shutdown of the client to be removed is required.
Changing an existing client of a referenced client-db without shutting down ipsec-gw or client-db is allowed. However, the shutdown of the client to be removed is required.