Saturday, June 17, 2023

VPN Site to Site Troubleshooting

 VPN Site to Site Troubleshooting 

VPN Users   fw tab -t userc_key -s

  1. Check if connectivity exist between the 2 Gateway peers
  2. VPN Debugging - Looking at the IKE negotiations
  3. Can both sides see the IKE packets arriving during teh Key Exchange? 

IKE Process (2 Phases)
Phase 1 - Main Mode (6 Packets)
Phase 2 - Quick Mode (3 Packets)

4. Turn VPN Debug On  - enter the command "vpn debug on; vpn debug ikeon" or "vpn debug trunc". 
The $FWDIR/log/ike.elg file contains information once debugging is enabled.
Checkpoint has a tool IKEView.exe - it parse information of ike.elg

5. Another tool is "vpn debug on mom" - it writes IKE captured data into file ikemonitor.snoop
This file is open with wireshark or ethereal. 

Phase I 

  • - Negotiates encryption methods (DES/3DES/AES etc)
  • - The key length
  • - The Hash Algorithm (MD5/SHA1) 
  • - Creates a key to protect the messages of the exchange. 


It does this in 5 stages:

  1. Peers Authenticate using Certificates or a pre-shared secret.
  2. Each peer generates a private Diffie-Hellman key from random bits and from that derives a DH public key. These are then exchanged.
  3. Each peer generates a shared secret from its private key and its peers public key, this is the DH key.
  4. The peers exchange DH Key material (random bits and mathematical data) and methods for PhaseII are agreed for encryption and integrity.
  5. Each side generates a symmetric key (based upon the DH key and key material exchanged).

In IkeView under the IP address of the peer, open the Main Mode Packet 1 - expand :
> "P1 Main Mode ==>" for outgoing or "P1 Main Mode <==" for incoming 
> MM Packet 1
> Security Association 
> prop1 PROTO_ISAKMP
> tran1 KEY_IKE

You should then be able see the proposed Encryption Algorithm, Key Length, Hash Algorithm, Authentication Method, DH Group, and SA renegotiation params (life type - usually secs and duration).

UNDERSTAND THE 5 PACKETS

- If your encryption fails in Main Mode 

Packet 1, then you need to check your VPN communities.

Packet 2 ( MM Packet 2 in the trace ) is from the responder to agree on one encryption and hash algorithm

Packets 3 and 4 arent usually used when troublshooting. They perform key exchanges and include a large number called a NONCE. The NONCE is a set   of never before used random numbers sent to the other part, signed and returned to prove the parties identity.

Packets 5 and 6 perform the authentication between the peers. The peers IP address shows in the ID field under MM packet 5. Packet 6 shows that   the peer has agreed to the proposal and has authorised the host initiating the key exchange.


NOTE: 

1. If your encryption fails in Main Mode Packet 1, then you need to check your VPN communities.

2. If your encryption fails in Main Mode Packet 5, then you need to check the authentication - Certificates or pre-shared secrets


PHASE II

Next is Phase II - the IPSec Security Associations (SAs) are negotiated, 

- The shared secret key material used for the SA is determined and there is an additional DH exchange. 

- Phase II failures are generatlly due to a misconfigured VPN domain. 

- Phase II occurs in 3 stages:

1. Peers exchange key material and agree encryption and integrity methods for IPSec.

2. The DH key is combined with the key material to produce the symmetrical IPSec key.

3. Symmetric IPSec keys are generated.


Note: For SecurePlatform or Gaia OS, you must be logged in as Expert.

1. Initiate debug of VPND daemon on Check Point Security Gateway from the CLI:
2. [Expert@HostName]# vpn debug trunc

Notes:

This command initiates both VPND debug and IKE debug, whereas the 'vpn debug on' command only initiates VPND debug.

If you also need the level of detail provided by TDERROR_ALL_ALL=5, then you also need to run:

[Expert@HostName]# vpn debug on TDERROR_ALL_ALL=5 

This must be run after the command 'vpn debug trunc'.

3. Disable SecureXL:
[Expert@HostName]# fwaccel off
[Expert@HostName]# fwaccel stat 

4. Initiate a packet capture on the Security Gateways involved in Site-to-Site VPN (or tcpdump, or Wireshark pcap):

Notes:

You can press "Alt + F1" to open a second terminal, or open a second SSH session, or (for Windows) open a second command prompt.

[Expert@HostName]# fw monitor -e "accept;" -o /var/log/fw_monitor.cap

or

[Expert@HostName]# fw monitor -e "accept port(500) or port(4500);" -o /var/log/fw_monitor.cap

or

[Expert@HostName]# vpn debug mon

If you run 'vpn debug mon', the output file is 'ikemonitor.snoop'. In this output file, all the IKE payloads are in clear text. Whereas, in 'fw_monitor.cap' file, all the IKE payloads are encrypted.

5. Launch the TunnelUtil tool, which is used to control VPN tunnels:
[Expert@HostName]# vpn tu
Note: Before running the 'vpn tu' command, kill all traffic over the VPN. This will include stopping all continuous traffic across the VPN tunnel.

6. Then select the option "Delete all IPsec+IKE SAs for a given peer (GW)".

7. Enter your remote Security Gateway IP address.

8. Exit from the 'vpn tu' utility.

Important note: This procedure closes open VPN tunnels. This can be useful because the next time communication is attempted you will capture the VPN tunnel creation information. Please be aware that existing VPN tunnels with this remote peer will be closed and will have to be reestablished. This is especially important in a Production environment. If the remote peer is a third-party device, then it is important to also clear the keys on the remote peer device. Clearing the keys on only the Check Point gateway will often cause a problem where the remote peer refuses to allow the Check Point to establish a new key because it already has one.

If it is not possible to clear the keys on both the Check Point gateway and the remote third-party peer, DO NOT clear the key on only the Check Point gateway! In that case, skip this step completely.

9. Reproduce the issue, attempt to connect FROM YOUR NETWORK to a device in the remote encryption domain. This initiates the tunnel.

10. Launch the TunnelUtil tool, which is used to control VPN tunnels:
[Expert@HostName]# vpn tu
Note: Before running the 'vpn tu' command, kill all traffic over the VPN.

11. Select the option that "Delete all IPsec+IKE SAs for a given peer (GW)".

12. Enter your remote Security Gateway IP address.

13. Exit from the 'vpn tu' the utility.

14. Reproduce the issue, attempt to connect FROM THE REMOTE NETWORK to a device in the local encryption domain. This initiates the tunnel.

15. Stop debug of VPND daemon on the Security Gateways involved in Site-to-Site VPN:
[Expert@HostName]# vpn debug truncoff
Note: If you used 'vpn debug mon' command, you need to run 'vpn debug moff'.

16. Stop packet capture by pressing "CTRL+C".

17. If SecureXL was disabled, re-enable it:
[Expert@HostName]# fwaccel on
[Expert@HostName]# fwaccel stat 

18. Send the following files from the Security Gateways to Check Point Support:
• $FWDIR/log/ike.elg*
• $FWDIR/log/vpnd.elg*
• $FWDIR/log/ikemonitor.snoop
• /var/log/fw_monitor.cap


From <http://dkcheckpoint.blogspot.com/2016/01/vpnsitetosite-troubleshooting.html> 








Posted by at