Source: https://sc1.checkpoint.com/documents/R76/CP_R76_VPN_AdminGuide/13847.htm
The Situation
You can learn a lot about encryption, hashing, and DH when configuring a site-to-site VPN.
I was on a conference call where several other network security engineers, project managers, and networking teams were trying to bring up an existing site-to-site IPSec VPN tunnel.
The configuration was actually completed weeks ago, but it was now that all the teams and testers were able to get together and see if it works.
As soon as the testing started, it failed right away. The client was trying to send a DNS query (UDP port 53) across the VPN tunnel by doing an nslookup. The error we saw on the Checkpoint firewall's packet capture utility said:
"ISAKMP_AUTH_FAILED = Responder is reporting that preshared key is mismatched"
We were using a pre-shared key for authentication between our firewall and the customer firewall. A pre-shared key has to match on both our firewall and the customer firewall in order for packets to be encrypted and decrypted, does this sound familiar? This is symmetric encryption.
The error message is telling us that there is a mismatch of a secret key either on our firewall or the peer firewall - somebody most likely made a spelling mistake. The secret key was something to the effect of this:
"3!_S9FH78b.)+3@8#Q"955z,S9j@8GFnF90*"
When we enter this into the firewall, it's a copy and paste job. We rarely ever take a PSK over the phone because you never know who is listening, and there is more of a chance for a mistake, a risk. Either way, either our firewall or their firewall had the wrong pre-shared secret.
The issue was that both firewalls were using what is known as Simplified VPN in Checkpoint firewalls. Which meant that once we put in a pre-shared secret into the configuration, it is starred out, we can't see it again.
I'm sure there are ways to recover it at the kernel level, but that would not be a prudent course of action during a conference call or during production hours.
The Pressure
So on this conference call, with tons of pressure to get this VPN tunnel up and running quickly, and an executive or two listening into the whole thing to make sure everyone is doing their job...both parties are unable to view the password required to move this solution forward.
What do we do?
This is where a proper change management process saves the day. Since both parties were following strict change management guidelines to begin building this VPN tunnel weeks ago, all we had to do was refer back to the change ticket and view the ticket logs. It's a good thing we also follow proper documentation.
Whenever there is a change to a firewall or another network device, a change management process must be followed. This means there would be documentation of the following:
Request for the initial change
Providing a design on how to perform the change
Stating the firewall name and changes to the rulebase
Logging any passwords or pre-shared keys within a secure ticketing system
Having a senior engineer review and approve the change
Implement the change
Fixing any issues
Closing out the change
If we looked back at our change management process, it would be accomplishing Step #4 which would allow us to find the original pre-shared key, which is exactly what we did.
Once we entered the pre-shared key exactly written down in the documentation and pushed the policy to the firewall, the VPN tunnel came back up. It was concluded that someone on our side did indeed enter the pre-shared secret incorrectly when first creating this VPN tunnel.
The tunnel came up, both parties acknowledge the DNS quiries were coming through the tunnel, and we successfully ended the call.
The lesson learned that since we had everything documented from the beginning, we were able to quickly resolve an issue weeks later. Documentation isn't just a cumbersome thing to do, it is a way to save yourself from extra work and effort later on down the road.
A proper documentation and change management process helped us to quickly resolve an important issue.
CISSP Take-Away Concepts
Domain 1: Security and Risk Management
Procedures
Procedures are a step-by-step guide to complete a task. We did this when we wrote up the procedure to create the VPN tunnel in our change design
Domain 3: Security Engineering
Symmetric Encryption
The pre-shared secret was the symmetric key. We were using symmetric encryption for this VPN tunnel. If we wanted to use asymmetric encryption, then we'd have used certificates, not pre-shared keys
Domain 4: Network Security
IPSec VPN
An IPSec VPN provides confidentiality, integrity, authentication
Firewalls
This whole article was about a VPN tunnel being built on two different firewalls
Domain 7: Security Operations
Change management
A proper change management process with documentation allowed us to refer back to it and retrieve a pre-shared key required to troubleshoot a VPN on an urgent conference call