Null
The customer uses the SSL VPN webpage and configures the URL list, but finds that some high-security websites cannot be accessed.
The firewall's interface capture found that the TLS 1.2 handshake failed.
Check the TLS 1.2 Client Hello message sent by the firewall and find that the cipher suite contains only three.
It is suspected that the website that was not accessed normally does not support these three default cipher suites.
By using IP access to directly connect to the problematic website from the local computer, it was found that the connection could be established normally. Upon checking the client hello and service hello messages, it was found that a larger number of cipher suites were being used.
By examining normal access, acknowledge that the cipher suite supported by the target website is rsa_aes_256_gcm_sha384.
Configure the SSL client policy on the firewall and add the corresponding cipher suite.
ssl client-policy test
prefer-cipher rsa_aes_128_cbc_sha rsa_aes_256_cbc_sha rsa_aes_256_gcm_sha384
Introduce the policy in the SSLVPN context.
sslvpn context ctxip
ssl client-policy test
Then re-enable the sslvpn template (mandatory, it will not take effect without a restart).
Continue testing, and find that the first two interactions are normal, but the negotiation failure reason has changed to the firewall not recognizing the target server's CA.
Since the URLs configured in the firewall are manually set by the administrator, there generally won't be security risks, so these certificates can be trusted. Next, modify the client policy to not validate the certificates.
ssl client-policy test
undo server-verify enable
The sslvpn template also needs to be restarted.
Access is normal after configuration.
1. Capture packets to obtain supported cipher suites.
2. Configure ssl client-policy - trust the corresponding cipher suites and CA.
3. Add the policy to the sslvpn context.