A. In order for IPSec (tunnel mode or transport mode) to negotiate encryption, the systems must first decide they are willing to trust each other. There are two methods defined in IPSec to accomplish this. One is with X.509 certificates and the other is with pre-shared keys.
The most secure way to do this is with X.509 certificates. In this case, the two systems first obtain an X.509 certificate from certificate authorities so that the certificates share a common root authority. Think of it as both sides getting the certificate from someone they mutually trust. In this case, the certificate for the gateway uniquely identifies the gateway, and the certificate for the client uniquely identifies the client. Using IKE, the certificates are securely exchanged and the gateway and the client computers can authenticate each other after they generate encryption keys and begin using the IPSec main mode security association (SA).
Recognizing that certificate deployment had not yet matured, pre-shared keys were primarily placed into the IPSec standard for the purpose of testing basic interoperability between vendor implementations. Some people continue to use pre-shared keys rather than deploy much more secure X.509 certificates. For pre-shared keys, each system is configured with a shared key (similar to a password).
When the systems start IPSec main mode negotiation using IKE, they indicate to each other that a pre-shared key is used as the authentication method. However, there is no way to uniquely identify the gateway or the client in advance (particularly in remote access). You might try using the IP addresses as a hint, but in remote access, there is no way to know this because the computer is roaming between Internet access points and often gets a different IP address at each connection. For this to work, all computers involved must be configured with the same pre-shared key.
For example, if you have 1,500 VPN clients and four VPN servers, all of the systems would have to use the same pre-shared key. If the pre-shared key is ever compromised, a malicious user can use it to attempt to connect to your server. If the malicious user has the correct pre-shared key, the server will negotiate the main mode IPSec security association.
If user authentication is also used, the remote access connection is rejected, unless the malicious user also has knowledge of a set of valid user credentials. Even without valid user credentials, computation time on the gateway is used to derive the encryption keys and authenticate the computer attempting the IPSec SA. By performing repeated connection attempts from multiple computers, the gateway processing power can be consumed and block all other communications to the server, resulting in a denial of service attack.
The only way to fix the vulnerability of a compromised pre-shared key is to configure a new pre-shared key on the server and either manually reconfigure the pre-shared key on all other systems or distribute the new pre-shared key in secret. During the key change transition time, no one will have access to the server. This is equivalent to having to change the locks on the doors of your business when 1,500 employees share the same key required for accessing the building.