First you need to capture a vpn debug files from the firewall. The proper steps to gather a clean Ike.elg file is to force the firewall to re-negotiate the VPN tunnel. To do this you need to do the following:
- On one for the firewalls issue the command “vpn tu or vpn tunnelutil”. This will bring up the following options:
********** Select Option **********
(1) List all IKE SAs
(2) List all IPsec SAs
(3) List all IKE SAs for a given peer
(4) List all IPsec SAs for a given peer
(5) Delete all IPsec SAs for a given peer
(6) Delete all IPsec+IKE SAs for a given peer
(7) Delete all IPsec SAs for ALL peers
(8) Delete all IPsec+IKE SAs for ALL peers
(A) Abort
*******************************************
You can select either option #6 and put in the remote side Ip address or you can select option #8 and delete all the tunnels IPsec and IKE SAs. This will delete the IPsec and IKE SAs and this will send a delete IKE SA packet to the remote side telling it to take down the exciting tunnel.
- On the local firewall issue the command “vpn debug ikeon”. This will turn on IKE debugging.
- From either side of the firewall generate traffic through the tunnel.
- Once the tunnel have failed issue the command “vpn debug ikeoff”.
- Gather the ike.elg file that is in the $FWDIR/log directory on the firewall.
How to open an Ike.elg file:
- You will need a tool called IKEView. This file is available with the INFOView tool at https://support.nokia.com/employee/tac_source/tac.jsp?f=tac_source/Software/cp_tools.html#ike_view
- Once you have the tool open you can drag and drop the Ike.elg file into the tool or you can use the file open and select the ike.elg file.
- It should look at the following once opened. (Note this is a working VPN Example)
How to Read an Ike.elg:
To read an Ike.elg file you should have the understanding on the componets that are needed for an IPSec VPN. Resolution #23501 goes in depth on the componets for IPSec. For a VPN tunnel to establish there is two phases. They are know as Phase 1 “Main Mode” and Phase 2 “Quick Mode”
Phase 1:
Can either consist of 3 packets “Aggressive mode” or 6 packets “Normal mode”. Aggressive mode is quicker but is less insecure then Normal mode. Phase 1 negotiate the IPSec SA of a tunnel. A single IPSec SA can consist of multiple IKE SAs (for Phase 2). Phase 1 is the negotiation of the keys between firewalls before it goes to Phase 2.
This is an example of a completed negotiation of a Main Mode. This Ike.elg was taken off a firewall with the Ip address 10.207.107.80 going to 10.207.107.70.
The way you would read this is the part that circled in red is the Ip address of the other end of the tunnel. The part in circle in blue indicates who is negotiating the tunnel (were the traffic is coming from). Since the arrow is point to the right. This indicates that 10.207.107.80 (Local firewall from you took this ike.elg off) is making the tunnel and the traffic is going outbound.
(NOTE: <== indicates traffic inbound: ==> indicates traffic outbound)
Since Phase 1 (Normal mode) consist of 6 packets. The first packet in the example above is sent by the local firewall “MM packet 1”. MM represents the Main Mode packet. An example of a Main mode packet flow is as below.
The way the packets are organized in Main Mode:
Main Mode with Pre-Shared Key.
MM packet 1 Contains: Header, Security Association (Integrity, Encryption Strengths, DH group,
IPSec lifetime
MM packet 2 Contains: Header, Security Association (Integrity, Encryption Strengths, DH group,
IPSec lifetime
MM packet 3 Contains: Header, DH Key Exchange, Nonce (Random number)
MM packet 4 Contains: Header, DH Key Exchange, Nonce (Random number)
MM packet 5 Contains: Header, ID. This is encrypted
MM packet 6 Contains: Header, ID. This is encrypted
If the VPN fails on MM packet 5 or 6 this is normal because of a miss match of the Pre-Shared key.
Example below is an expanded MM packet 1. This shows that we are proposing (in blue) 3DES, MD5, Authentication Method= Pre-shared, DH group 2, and IPSec life of 86400.
Main Mode with Certificates.
MM packet 1 Contains: Header, Security Association (Integrity, Encryption Strengths, DH group,
IPSec lifetime
MM packet 2 Contains: Header, Security Association (Integrity, Encryption Strengths, DH group,
IPSec lifetime
MM packet 3 Contains: Header, DH Key Exchange, Nonce (Random number)
MM packet 4 Contains: Header, DH Key Exchange, Nonce (Random number), and Certificate Request
MM packet 5 Contains: Header, ID, Certificate, Signature, and Certificate Request. This is encrypted
MM packet 6 Contains: Header, ID, Certificate, and Signature. This is encrypted
What to check when Main Mode is failing.
The only two packets that you can really look at in Main Mode are MM packet 1 and 2. The rest are really will not provide you mush details. MM packet 1 and 2 will provide you the details on the Security Association. This consist of the proposed Integrity, Encryption Strengths, DH group and the IPSec life time. You can expand the packets in IKEView and see what each firewall is proposing. You will be able to tell what the remote firewall is proposing within the MM packet that is received from the remote side.
MM packet 3 and 4 are just the exchange in the DH key and a Nonce (Random number generated from the remote side to encrypt the data for MM packet 5 and 6). There is really noting that you can look for within here
MM packet 5 and 6 are encrypted. This is the for the exchange in the pre-shared key or the Certificate. If the VPN is failing on these two packets then you know it is a possible Pre-shared key mismatch or an invalid certificate.
Phase 2:
IPsec negotiation, or Quick Mode, is similar to an Aggressive Mode IKE negotiation, except negotiation must be protected within an IPsec SA from Phase 1. Quick Mode negotiates the SA for the data encryption and manages the key exchange for that IPsec SA. There are 4 packets used in Quick Mode. They contain all information required to maintain secure connection between two IP-based hosts. The first two packets in the exchange provide the details on the networks or host that you will be negotiating, encryption strengths, integrity, and the nonce. The last two packets are encrypted traffic. In an ike.elg you may only see three packets.
The example above the remote peer Ip address is 10.207.107.70 (In Red). The local firewall is making the negotiation to the remote peer (arrow points to the right in red indicates this). The blue is the local encryption domain (Check Point try to use the largest possible subnet). The green is the remote encryption domain (remember that Check Point try to use largest possible subnet. If the networks overlap the SA will not be negotiated).
In the example above since we are local firewall is making the connection to the remote peer. QM packet (Quick Mode-Phase 2) 1 and 3 is sent from the local firewall. QM packet 2 is send from the remote firewall.
The way Quick Mode packets are organized are as followed:
QM packet 1 Contains: Header, Security Association (Integrity, Encryption Strengths, IPSec (IKE phase 2) lifetime, and IPSec proposal (Networks or host)
QM packet 2 Contains: Header, Security Association (Integrity, Encryption Strengths, IPSec (IKE phase 2) lifetime, and IPSec proposal (Networks or host)
QM packet 3 Contains: Header, Hash
QM packet 4 Contains: Header, Hash, and Connection Notifications.
What to check when Quick Mode is failing:
Since there is only 3 or 4 packets in Quick Mode there is not too much to check. The only two packets that would do any good to look at are QM packet 1and QM packet 2. In the example above the local firewall is proposing the following:
QM packet 1 (17:47:00) - (192.168.199.8 255.255.255.248) - (192.168.198.0 255.255.255.0)
- The (192.168.199.8 255.255.255.248) is the local encryption domain and the (192.168.198.0 255.255.255.0) is what is defined as the remote side encryption domain. The remote side should match up with the same networks. If they do not you will get an error for “No Valid SA” in most cases.
- If what you are proposing is you’re outside IP address of your firewall and not what you have defined in local encryption domain this means that your firewall is nating the traffic. This is when a not nat rule is needed (unless you would like it this want and the remote side needs to have the external Ip address of your firewall defined in the remote side encryption domain.
For QM packet 2 you should see the same if the encryption domains are matched up. If you are making a connection to a Cisco, Netscreen, or a SonicWall you may see the request be made by host. In this case you will need to follow resolution #1733. This will force the local firewall to negotiate the SAs per host and not per largest possible subnet.
