checkpoint-hyper-vpn-Upgrade PBR - Policy Base Routing
VPN Site to Site Troubleshooting
1. Check if connectivity exist between the 2 Gateway peers
2. VPN Debugging - Looking at the IKE negoatations
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.
-----------------------------------------------------------------------------------------------------
Debug
-------
1. Turn on debugs
vpn debug trunc
vpn debug on TDERROR_ALL_ALL=5
2. Run the following command to reset the tunnel
(not needed if you are testing a Remote Access VPN):
vpn tu
Then select the option that reads,
"Delete all IPsec+IKE SAs for a given peer (GW)"
enter your remote GW ip address
exit the utility
3. Try to build the tunnel back up again, in both directions,
attempt to connect from YOUR NETWORK to a device in
the remote encryption domain and then attempt to connect
from THE REMOTE NETWORK to a device in the local
encryption domain.
4. Turn off debugs
vpn debug ikeoff
vpn debug off
debug file location:
SecurePlatform - $FWDIR/log/ike.elg*
$FWDIR/log/vpnd.elg*
Windows - %FWDIR%\log\ike.elg*
%FWDIR%\log\vpnd.elg*
------------------------------------------------------------------------------------------------
VPN Peer: 216.231.83.36
Phase 1 IKE Properties:
Key Exchange: 3DES
Data Integrity: SHA256
Renegotiate IKE SA: 86400 seconds
DH-Group: Group 2
Phase 2 IPSEC Properties:
Data Encryption: 3DES
Data Integrity: SHA256
Perfect Forward Secrecy: Enabled
Renegotiate IPSEC SA’s Every: 3600 Seconds
216.231.67.57 our side
10.160.242.71 cisco side
encryption failure: error occured on the implied rule
reviewed config, looks fine
most likely encryption dislike from the cisco side
he mentioned that setting the encryption to 3DES and MD5 allows the tunnel to come up
they have a conf call with them in an hour
gave him the below debug to run if the encryption tweaks on the cisco side don't resolve the issue
1. Delete all $FWDIR/log/ike.elg and vpnd.elg files
# cd $FWDIR/log/
# rm ike.elg.*
# rm vpnd.elg.*
2. Delete all IPSec+ IKE SAs for the given peer through
# vpn tu
3. Start ike debug
# vpn debug ikeon (creates the ike.elg file)
# vpn debug trunc
4. Replicate the problem
5. Stop ike debug
# vpn debug ikeoff
# vpn debug off
6. Send me all of the $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg files for further review.
Client
vendor
----------------------------------------------------------------------------
Proxy ID - 216.231.64.0/19 (neehan stuff) 10.15.0.0/16 tumbleweed
ENCRYPTION
----------
IKE Security Association (Phase 1) Properties:
-Performed Key Exchange encryption with: ASE-256
-Perform Data Integrity with: SHA-256
IPsec Security Association (Phase 2) Properties
Perform IPsec data encryptoin with: 3DES
Perform data Integrity with: MD5
TUNNEL MANAGEMENT
-----------------
- One VPN tunnel per each pair of hosts
- One VPN tunnel per subnet pair (each subnet create a new SA (security Association) proxyID is Network in the master Encryption domain
- One VPN tunnel per Gateway pair (one SA created for Gateway pair - ProxyID is 0.0.0.0.0/0.0.0.0.0)
ADVANCE VPN PROPERTIES
----------------------
VPN Routing for satellites:
To Center only
Shared Secret - peer name -shared secret
IKE Phase 1
Diffie-Hellman group: group 2 (1024 bits)
Renegotiate IKE security association every: 480 minuits
IPSec (Phase 2)
Use Perfect Forward Secrety
Diffie-Hellman group: group 2 (1024 bits)
debug files first taken didn't capture the negotiation
cisco router VPN
216.231.83.36 our side
10.160.242.71 cisco side peer 54.152.244.11
took the remote and reran them
had them go for a bit longer
reviewed the files
QM P1 failure, we send them:
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] allocateSpi: Allocated SPI: 0x570a57c2, 0 collisions (currently 1 reserved).
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] QMCreate1: rangeUsed: 1 my [0-ffffffff] peer [0-ffffffff]
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
They don't like the all 0's subnets and return with no proposal chosen
they haven't configured their side to accept 0.0.0.0 encryption domain which we send because we have it set to "one vpn tunnel per gateway pair"
changed to "one vpn tunnel per subnet pair" and installed policy
will initiate the tunnel for testing at a later time as the other team has left
Number: 3446237
Date: 19Jan2012
Time: 23:17:13
Interface: daemon
Origin: lanvpn-fwa
Type: Log
Action: Key Install
Source: lanvpn-fwa (10.210.0.220)
Destination: 199.204.139.93
Community: MYTUNNEL
Information: IKE: Main Mode completion [UDP].
Encryption Scheme: IKE
Encryption Methods: 3DES + SHA1, Pre shared secrets
IKE Initiator Cookie: 4619fb5980099913
IKE Responder Cookie: 6ac91b5a9949dcf4
VPN Peer Gateway: 199.204.139.93
Subproduct: VPN
VPN Feature: IKE
Product: Security Gateway/Management
Number: 3446238
Date: 19Jan2012
Time: 23:17:13
Interface: daemon
Origin: lanvpn-fwa
Type: Log
Action: Key Install
Source: myvpn-fwa (10.210.0.220)
Destination: 199.204.139.93
Community:
Information: IKE: Quick Mode completion
IKE IDs: subnet: 216.118.176.0 (mask= 255.255.248.0) and host: 199.168.173.245
Source Key ID: 0xa07407ec
Destination Key ID: 0xb59a73e4
Encryption Scheme: IKE
Encryption Methods: ESP: 3DES + SHA1
IKE Initiator Cookie: 4619fb5980099913
IKE Responder Cookie: 6ac91b5a9949dcf4
IKE Phase2 Message ID: 0f4283dc
VPN Peer Gateway: 199.204.139.93
Subproduct: VPN
VPN Feature: IKE
Product: Security Gateway/Management
Number: 3446242
Date: 19Jan2012
Time: 23:17:13
Interface: eth3
Origin: myvpn-fwa
Type: Log
Action: Encrypt
Service: https (443)
Source Port: 4036
Source: DKdesktop (10.210.52.13)
Destination: 199.168.173.245
Protocol: tcp
Rule: 3
Rule UID: {1352B071-1C14-4B74-9D3C-555608A8B472}
Current Rule Number: 3-lanvpn-cluster
NAT rule number: 32
NAT additional rule number: 0
XlateSrc: MYVPN-Hide-NAT (216.118.182.11)
XlateSPort: 39542
Community: MYTUNNEL
Information: service_id: https
Encryption Scheme: IKE
Encryption Methods: ESP: 3DES + SHA1
VPN Peer Gateway: 199.204.139.93
Subproduct: VPN
VPN Feature: VPN
Product: Security Gateway/Management
IPS Profile: Default_Protection
Policy Info: Policy Name: myvpn-cluster
Created at: Thu Jan 19 22:18:32 2012
Installed from: myfwm01
VPN Peer: 216.231.183.136
Phase 1 IKE Properties:
Key Exchange: 3DES
Data Integrity: SHA256
Renegotiate IKE SA: 86400 seconds
DH-Group: Group 2
Phase 2 IPSEC Properties:
Data Encryption: 3DES
Data Integrity: SHA256
Perfect Forward Secrecy: Enabled
Renegotiate IPSEC SA’s Every: 3600 Seconds
10.160.242.71 cisco side
encryption failure: error occured on the implied rule
reviewed config, looks fine
most likely encryption dislike from the cisco side
he mentioned that setting the encryption to 3DES and MD5 allows the tunnel to come up
they have a conf call with them in an hour
gave him the below debug to run if the encryption tweaks on the cisco side don't resolve the issue
1. Delete all $FWDIR/log/ike.elg and vpnd.elg files
# cd $FWDIR/log/
# rm ike.elg.*
# rm vpnd.elg.*
2. Delete all IPSec+ IKE SAs for the given peer through
# vpn tu
3. Start ike debug
# vpn debug ikeon (creates the ike.elg file)
# vpn debug trunc
4. Replicate the problem
5. Stop ike debug
# vpn debug ikeoff
# vpn debug off
6. Send me all of the $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg files for further review.
----------------------------------------------------------------------------
Proxy ID - 216.231.64.0/19 (my stuff) 10.15.0.0/16 ftp
ENCRYPTION
----------
IKE Security Association (Phase 1) Properties:
-Performed Key Exchange encryption with: ASE-256
-Perform Data Integrity with: SHA-256
IPsec Security Association (Phase 2) Properties
Perform IPsec data encryptoin with: 3DES
Perform data Integrity with: MD5
TUNNEL MANAGEMENT
-----------------
- One VPN tunnel per each pair of hosts
- One VPN tunnel per subnet pair (each subnet create a new SA (security Association) proxyID is Network in the master Encryption domain
- One VPN tunnel per Gateway pair (one SA created for Gateway pair - ProxyID is 0.0.0.0.0/0.0.0.0.0)
ADVANCE VPN PROPERTIES
----------------------
VPN Routing for satellites:
To Center only
Shared Secret - peer name -shared secret
IKE Phase 1
Diffie-Hellman group: group 2 (1024 bits)
Renegotiate IKE security association every: 480 minuits
IPSec (Phase 2)
Use Perfect Forward Secrety
Diffie-Hellman group: group 2 (1024 bits)
debug files first taken didn't capture the negotiation
cisco router VPN
216.231.183.36 our side
10.160.242.171 cisco side peer 54.152.244.11
took the remote and reran them
had them go for a bit longer
reviewed the files
QM P1 failure, we send them:
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] allocateSpi: Allocated SPI: 0x570a57c2, 0 collisions (currently 1 reserved).
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] QMCreate1: rangeUsed: 1 my [0-ffffffff] peer [0-ffffffff]
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
They don't like the all 0's subnets and return with no proposal chosen
they haven't configured their side to accept 0.0.0.0 encryption domain which we send because we have it set to "one vpn tunnel per gateway pair"
changed to "one vpn tunnel per subnet pair" and installed policy
will initiate the tunnel for testing at a later time as the other team has left
--------------------------------------------------------------------------------
Your Public IP is used for Phase I,
internal IP(s) for Phase II.
Phase II is only allowed with any particular subnet if it is defined in the encryption domain.
For example, if you had:
LAN1 = 10.0.10.0/24
LAN2 = 10.0.11.0/24
DMZ = 172.16.0.0/23
Let's say you need to encrypt LAN1 and DMZ to a DR site so you can replicate data. On the CP side, you should have/create a group, let's call it "site_a_enc_domain" for this example. You should also create network objects representing your segments listed above. You would need to add the LAN1 and DMZ network objects to that group.
Then, in gateway/cluster properties -> Topology tab -> Manually Defined: Drop down the box and select the group you created.
For Phase I setup, you need to:
1) Create an Interoperable device and define the Public IP used for the VPN
2) Create a network(s) that represents the remote side INTERNAL/PRIVATE network (or multiples and add them to a group as you did on your side)
3) Assign that group/network as the encryption domain for that remote firewall object
4) This step differs depending on Traditional or Simplified VPN mode
As for the rules you will need for Phase II... Again, that depends on what you are running - Traditional or Simplified VPN mode
At a minimum, this should allow you to look around at the others and figure it out. Let us know if you need more help.
---------------------------------------------------------------------------------
1. IKE negotation between the 2 peers
2. Can both sides see the IKE packets arriving during a key exchange?
IKE negotiation consists of two phases -
Phase I (Main mode which is six packets) and
Phase II (Quick Mode which is three packets).
Phase I negotiates encryption methods (DES/3DES/AES etc), the key length, the hash Algorithm (MD5/SHA1) and 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.
3. These are then exchanged.
4. Each peer generates a shared secret from its private key and its peers public key, this is the DH key.
5. The peers exchange DH Key material (random bits and mathematical data) and methods for PhaseII are agreed for encryption and integrity.
6. 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).
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.
If your encryption fails in Main Mode Packet 5, then you need to check the authentication - Certificates or pre-shared secrets
PHASE II
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.
In IkeView under the IP address of the peer, expand Quick Mode packet 1:
> "P2 Quick Mode ==>" for outgoing or "P2 Quick Mode <==" for incoming
> QM Packet 1
> Security Association
> prop1 PROTO_IPSEC_ESP
> tran1 ESP_AES (for an AES encrypted tunnel)
You should be able to see the SA life Type, Duration, Authentication Alg, Encapsulation Mode and Key length.
If your encryption fails here, it is one of the above Phase II settings that needs to be looked at.
There are two ID feilds in a QM packet. Under
> QM Packet 1
> ID
You should be able to see the initiators VPN Domain configuration including the type (ID_IPV4_ADDR_SUBNET) and data (ID Data field).
Under the second ID field you should be able to see the peers VPN Domain configuration.
Packet 2 from the responder agrees to its own subnet or host ID, encryption and hash algorithm.
Packet 3 completes the IKE negotiation.
If all of this works without any errors, then you may have previously initiated an invalid tunnel previously. You can use the VPN tunnel utility "vpn tu" to remove SA keys from the table.
VPN Site to Site Troubleshooting
1. Check if connectivity exist between the 2 Gateway peers
2. VPN Debugging - Looking at the IKE negoatations
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.
-----------------------------------------------------------------------------------------------------
Debug
-------
1. Turn on debugs
vpn debug trunc
vpn debug on TDERROR_ALL_ALL=5
2. Run the following command to reset the tunnel
(not needed if you are testing a Remote Access VPN):
vpn tu
Then select the option that reads,
"Delete all IPsec+IKE SAs for a given peer (GW)"
enter your remote GW ip address
exit the utility
3. Try to build the tunnel back up again, in both directions,
attempt to connect from YOUR NETWORK to a device in
the remote encryption domain and then attempt to connect
from THE REMOTE NETWORK to a device in the local
encryption domain.
4. Turn off debugs
vpn debug ikeoff
vpn debug off
debug file location:
SecurePlatform - $FWDIR/log/ike.elg*
$FWDIR/log/vpnd.elg*
Windows - %FWDIR%\log\ike.elg*
%FWDIR%\log\vpnd.elg*
Gather the following information to resolve the VPN related issues:
1. CPINFO from the Security Management server. Refer to sk30567.
2. Encryption Integrity, Encryption Strengths, DH group, IPsec lifetime for Phase 1 and 2 and the networks proposed on each end.
Fill out the following table for each end-point of the tunnel
1.Check Point Site Info
Fill out the following table for each end-point of the tunnel
1.Check Point Site Info
:
Phase 1 - Encryption Strength (3Des, Des, AES256) = - Encryption Integrity (MD5, SHA1) = - Diffie-Hellman Group for IKE (phase 1) (group 1, 2, 5) = - Renegotiate IKE (phase 1) (1400 minutes) = - Support Aggressive mode (yes, no) = Phase 2 - Encryption Strength (3Des, Des, AES256) = - Encryption Integrity (MD5, SHA1) = - Use Perfect Forward Secrecy (if yes what group) = - Renegotiate IPsec (3600 seconds) = 2. Are you using Pre-Shared secrets or Certificates? 3. Are they able to establish the tunnel one-way? If so which way? 4. What are the IP addresses that you are testing from and two in your
encryption domains? 5. What is the IP address and name of the security gateway in question? 6. What is the IP address and name of the remote VPN site? Also, what is
the type of VPN appliance being used? 1. Remote Site Info: Phase 1 - Encryption Strength (3Des, Des, AES256) = - Encryption Integrity (MD5, SHA1) = - Diffie-Hellman Group for IKE (phase 1) (group 1, 2, 5) = - Renegotiate IKE (phase 1) (1400 minutes) = - Support Aggressive mode (yes, no) = Phase 2 - Encryption Strength (3Des, Des, AES256) = - Encryption Integrity (MD5, SHA1) = - Use Perfect Forward Secrecy (if yes what group) = - Renegotiate IPsec (3600 seconds) = 2. Are you using Pre-Shared secrets or Certificates? 3. Are they able to establish the tunnel one-way? If so which way? 4. What are the addresses that you are testing from and two in your
encryption domains.
3. The
Follow the below procedure to create the
IKE.elg and vpnd.elg files which include an easily identified period when a connection is being tested. Follow the below procedure to create the
IKE.elg and vpnd.elg debug files:
a. Delete the
$FWDIR/log/IKE.elg and the $FWDIR/log/vpnd.elg files from the security gateway.
b. On the security gateway run "
This will bring up the following options:
(exception in NGX there is an addition option to Delete User with IPsec)
Select either option #6 and put in the remote site IP address or 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.
vpn tu" or "vpn tunnelutil". This will bring up the following options:
(exception in NGX there is an addition option to Delete User with IPsec)
********** 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 ******************************************* Select either option #6 and put in the remote site IP address or 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.
c. Run "
vpn debug ikeon" to enable the IKE debugging.
d. From either side of the security gateway generate traffic through the tunnel.
e. Once the tunnel fails, run "
vpn debug ikeoff".
f. The IKE.elg file will be created in the
$FWDIR/log directory on the security gateway. ------------------------------------------------------------------------------------------------
I compiled a list of VPN debugs, error messages, and common gotchas. This information is relevant for Check Point NGX firewall, but is not a complete VPN Debugging Guide.
DEBUGGING INSTRUCTIONS:
From the command line ( if cluster, active member )
· vpn debug on
· vpn debug ikeon
· vpn tu
· select the option to delete IPSEC+IKE SAs for a given peer (gw)
· Try the traffic to bring up the tunnel
· vpn debug ikeoff
· vpn debug off
Log Files are
· $FWDIR/log/ike.elg
· $FWDIR/log/vpnd.elg
COMMON MESSAGES:
According to the Policy the Packet should not have been decrypted
· The networks are not defined properly or have a typo
· Make sure VPN domains under gateway A are all local to gateway A
· Make sure VPN domains under gateway B are all local to gateway B
Wrong Remote Address
Failed to match proposal
· sk21636 – cisco side not configured for compression
No response from peer
· check encryption domains.
· remote end needs a decrypt rule
· remote firewall not setup for encryption
· something is blocking communication between VPN endpoints
· Check UDP 500 and protocol 50
No Valid SA
· both ends need the same definition for the encrytpion domain.
· sk19243 – (LAST OPTION) use debedit objects_5_0.c, then add subnets/hosts in users.def
· likely phase2 settings
· cisco might say ‘no proxy id allowed”
· Disable NAT inside VPN community
· Support Key exchange for subnets is properly configured
· Make sure firewall external interface is in public IP in general properties
No Proposal chosen
· sk19243 – usually cuased when a peer does not agree to VPN Domain or subnet mask
· make sure that encryption and hash match as well in Phase 2 settings
Cannot Identify Peer (to encryption connection)
· sk22102 – rules refer to an object that is not part of the local firewalls encryption domain
· may have overlapping encryption domains
· 2 peers in the same domain
· sk18972 – explains overlapping
Invalid ID
· sk25893 – Gateway: VPN-> VPN Advanced, Clear “Support key exhcnage for subnets”, Install policy
Authentication Failure
Payload Malformed
· check pre shared secrets
RESPONDER-LIFETIME
· As seen in ike debugs, make sure they match on both ends
Invalid Certificate
· sk17106 – Remote side peer object is incorrectly configured
· sk23586 – nat rules are needed
· sk18805 – multiple issues, define a static nat, add a rule, check time
· sk25262 – port 18264 has problems
· sk32648 – port 18264 problems v2
· sk15037 – make sure gateway can communicate with management
No Valid CRL
· sk32721 – CRL has expired, and module can’t get a new valid CRL
AddNegotiation
· FW-1 is handling more than 200 key negotiations at once
· vSet maximum concurrent IKE connections
Could not get SAs from packet
·
·
FW MONITOR NOTES
· packet comes back i I o O
· packet will be ESP between o and O
BASIC STUFF TO CHECK IN THE CONFIGURATION:
Accept FW-1 Control Connections
VPN domains
· setup in the topology of that item
· using topology is recommended, but you must define
· looking for overlap, or missing networks.
· Check remote and local objects.
Encryption Domains
· your firewall contains your networks
· their firewall contains their networks
Rule Setup
· you need a rule for the originator.
· Reply rule is only required for 2 way tunnel
Preshared secret or certificate
· Make sure times are accurate
Security rulebase
· make sure there are rules to allow the traffic
Address Translation
· be aware that this will effect the Phase 2 negotiations
· most people disable NAT in the community
Community Properties
· Tunnel management, Phase1 Phase2 encrypt settings.
Link selection
Routing
· make sure that the destination is routed across the interface that you want it to encrypt on
· you need IP proto 50 and 51 fo IPSEC related traffic
· you need port 500 UDP for IKE
· netstat -rn and look for a single valid default route
Smartview Tracker Logs
· purple = encrypted
· red = dropped
· green = no encryption
TRADITIONAL MODE NOTES
· can’t VPN Route
· encryption happens when you hit explicit rule
· rules must be created
SIMPLIFIED MODE NOTES
· VPN Communities
· Encryption happens at rule 0
· rules are implied
CHECKLIST
· Define encryption domains for each site
· Define firewall workstation objects for each site
· Configure the gateway objects for the correct encryption domain
· Configure the extranet community with the appropriate gateways and objects
· Create the necessary encryption rules.
· Configure the encryption properties for each encryption rule.
· Install the security Policy
IKE PACKET MODE QUICK REFERENCE
· – > outgoing
· < – incoming
PHASE 1 (MAIN MODE)
· 1 > Pre shared Secrets, Encryption & hash Algorithims, Auth method, inititor cookie (clear text)
· 2 < agree on one encryption & hash, responder cookie (clear text)
· 3 > random numbers sent to prove identity (if it fails here, reinstall)
· 4 < random numbers sent to prove identity (if it fails here, reinstall)
· 5 > authentication between peers, peers ip address, certificates exchange, shared secrets, expired certs, time offsets
· 6 < peer has agreed to the proposal and has authenticated initiator, expired certs, time offsets
PHASE 2 (QUICK MODE)
· 1 > Use a subnet or a host ID, Encryption, hash, ID data
· 2 < agrees with it’s own subnet or host ID and encryption and hash
· 3 > completes IKE negotiation
GOOD SKS to KNOW
· sk31221 – The NGX Advanced Troubleshooting Reference Guide (ATRG)
· sk26362 – Troubleshooting MTU related issues
· sk30509 – Configuring VPN-1/FireWall-1
· sk31567 – What is ike.elg?
· sk20277 – “Tunnel failure, cannot find IPSec methods of the community (VPN Error code 01)” appears
· sk31279 – Files copied over encrypted tunnel displaying error: “network path is too deep”
· sk32648 – Site-to-site VPN using certificates issued by the ICA (Internal Certificate Authority) fails
· sk19243 – largest possible subnet even when the largest_possible_subnet option is set to false
· sk31619 – VPN tunnel is down troubleshooting
· sk19599 – how to edit user.def for largest possible subnets & host only
VPN Peer: 216.231.83.36
Phase 1 IKE Properties:
Key Exchange: 3DES
Data Integrity: SHA256
Renegotiate IKE SA: 86400 seconds
DH-Group: Group 2
Phase 2 IPSEC Properties:
Data Encryption: 3DES
Data Integrity: SHA256
Perfect Forward Secrecy: Enabled
Renegotiate IPSEC SA’s Every: 3600 Seconds
216.231.67.57 our side
10.160.242.71 cisco side
encryption failure: error occured on the implied rule
reviewed config, looks fine
most likely encryption dislike from the cisco side
he mentioned that setting the encryption to 3DES and MD5 allows the tunnel to come up
they have a conf call with them in an hour
gave him the below debug to run if the encryption tweaks on the cisco side don't resolve the issue
1. Delete all $FWDIR/log/ike.elg and vpnd.elg files
# cd $FWDIR/log/
# rm ike.elg.*
# rm vpnd.elg.*
2. Delete all IPSec+ IKE SAs for the given peer through
# vpn tu
3. Start ike debug
# vpn debug ikeon (creates the ike.elg file)
# vpn debug trunc
4. Replicate the problem
5. Stop ike debug
# vpn debug ikeoff
# vpn debug off
6. Send me all of the $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg files for further review.
Client
| VPN Details | |
| VPN Parameters | |
| Equipment type | Checkpoint Gaia R77.20 |
| VPN Peer IP Address | 216.118.190.119 |
| Encryption Domain | Ref Crypto domain tab |
| IKE Parameters | |
| Authentication Method | Preshare |
| Pre-Shared Key | Exchange over phone |
| Authentification Algorithm | SHA-1 |
| Encryption Algorithm | 3DES |
| DH-Group ( 1 or 2 ) | 2 |
| Life Time ( Seconds ) | 86400 |
| Life Time ( KB ) | no volume limit |
| Mode (Aggressive/Main) | Main |
| IPSEC Parameters | |
| Encapsulation Protocol | ESP |
| Encryption Algorithm | 3DES |
| Authentication Algorithm | SHA-1 |
| PFS / DH-group | Disable |
| Life Time ( Seconds ) | 3600 |
| Life Time ( KB ) | 4608000 |
| Encapsulation Mode | Tunnel |
| Contact Information | |
| Name: | dk |
| Email: | email@me.com |
| Phone:223222 | |
| VPN Site Address: | |
vendor
| VPN Details | |
| VPN Parameters | |
| Equipment type | Vyatta VyOS 1.1.6 |
| VPN Peer IP Address | 23.168.132.124 |
| Encryption Domain | Ref Crypto domain tab |
| IKE Parameters | |
| Authentication Method | Preshare |
| Pre-Shared Key | Exchange over phone |
| Authentification Algorithm | SHA-1 |
| Encryption Algorithm | 3DES |
| DH-Group ( 1 or 2 ) | 2 |
| Life Time ( Seconds ) | 86400 |
| Life Time ( KB ) | no volume limit |
| Mode (Aggressive/Main) | Main |
| IPSEC Parameters | |
| Encapsulation Protocol | ESP |
| Encryption Algorithm | 3DES |
| Authentication Algorithm | SHA-1 |
| PFS / DH-group | Disable |
| Life Time ( Seconds ) | 3600 |
| Life Time ( KB ) | 4608000 |
| Encapsulation Mode | Tunnel |
| Contact Information | |
| Name: | dava |
| Email:dadada@asdaf.com | |
| Phone:dada | 6151 |
| VPN Site Address:dad | Dallas, TX |
----------------------------------------------------------------------------
Proxy ID - 216.231.64.0/19 (neehan stuff) 10.15.0.0/16 tumbleweed
ENCRYPTION
----------
IKE Security Association (Phase 1) Properties:
-Performed Key Exchange encryption with: ASE-256
-Perform Data Integrity with: SHA-256
IPsec Security Association (Phase 2) Properties
Perform IPsec data encryptoin with: 3DES
Perform data Integrity with: MD5
TUNNEL MANAGEMENT
-----------------
- One VPN tunnel per each pair of hosts
- One VPN tunnel per subnet pair (each subnet create a new SA (security Association) proxyID is Network in the master Encryption domain
- One VPN tunnel per Gateway pair (one SA created for Gateway pair - ProxyID is 0.0.0.0.0/0.0.0.0.0)
ADVANCE VPN PROPERTIES
----------------------
VPN Routing for satellites:
To Center only
Shared Secret - peer name -shared secret
IKE Phase 1
Diffie-Hellman group: group 2 (1024 bits)
Renegotiate IKE security association every: 480 minuits
IPSec (Phase 2)
Use Perfect Forward Secrety
Diffie-Hellman group: group 2 (1024 bits)
debug files first taken didn't capture the negotiation
cisco router VPN
216.231.83.36 our side
10.160.242.71 cisco side peer 54.152.244.11
took the remote and reran them
had them go for a bit longer
reviewed the files
QM P1 failure, we send them:
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] allocateSpi: Allocated SPI: 0x570a57c2, 0 collisions (currently 1 reserved).
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] QMCreate1: rangeUsed: 1 my [0-ffffffff] peer [0-ffffffff]
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
[vpnd 5356 1988448384]@hinoff-fwb.bcbsma.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
They don't like the all 0's subnets and return with no proposal chosen
they haven't configured their side to accept 0.0.0.0 encryption domain which we send because we have it set to "one vpn tunnel per gateway pair"
changed to "one vpn tunnel per subnet pair" and installed policy
will initiate the tunnel for testing at a later time as the other team has left
Number: 3446237
Date: 19Jan2012
Time: 23:17:13
Interface: daemon
Origin: lanvpn-fwa
Type: Log
Action: Key Install
Source: lanvpn-fwa (10.210.0.220)
Destination: 199.204.139.93
Community: MYTUNNEL
Information: IKE: Main Mode completion [UDP].
Encryption Scheme: IKE
Encryption Methods: 3DES + SHA1, Pre shared secrets
IKE Initiator Cookie: 4619fb5980099913
IKE Responder Cookie: 6ac91b5a9949dcf4
VPN Peer Gateway: 199.204.139.93
Subproduct: VPN
VPN Feature: IKE
Product: Security Gateway/Management
Number: 3446238
Date: 19Jan2012
Time: 23:17:13
Interface: daemon
Origin: lanvpn-fwa
Type: Log
Action: Key Install
Source: myvpn-fwa (10.210.0.220)
Destination: 199.204.139.93
Community:
Information: IKE: Quick Mode completion
IKE IDs: subnet: 216.118.176.0 (mask= 255.255.248.0) and host: 199.168.173.245
Source Key ID: 0xa07407ec
Destination Key ID: 0xb59a73e4
Encryption Scheme: IKE
Encryption Methods: ESP: 3DES + SHA1
IKE Initiator Cookie: 4619fb5980099913
IKE Responder Cookie: 6ac91b5a9949dcf4
IKE Phase2 Message ID: 0f4283dc
VPN Peer Gateway: 199.204.139.93
Subproduct: VPN
VPN Feature: IKE
Product: Security Gateway/Management
Number: 3446242
Date: 19Jan2012
Time: 23:17:13
Interface: eth3
Origin: myvpn-fwa
Type: Log
Action: Encrypt
Service: https (443)
Source Port: 4036
Source: DKdesktop (10.210.52.13)
Destination: 199.168.173.245
Protocol: tcp
Rule: 3
Rule UID: {1352B071-1C14-4B74-9D3C-555608A8B472}
Current Rule Number: 3-lanvpn-cluster
NAT rule number: 32
NAT additional rule number: 0
XlateSrc: MYVPN-Hide-NAT (216.118.182.11)
XlateSPort: 39542
Community: MYTUNNEL
Information: service_id: https
Encryption Scheme: IKE
Encryption Methods: ESP: 3DES + SHA1
VPN Peer Gateway: 199.204.139.93
Subproduct: VPN
VPN Feature: VPN
Product: Security Gateway/Management
IPS Profile: Default_Protection
Policy Info: Policy Name: myvpn-cluster
Created at: Thu Jan 19 22:18:32 2012
Installed from: myfwm01
VPN Peer: 216.231.183.136
Phase 1 IKE Properties:
Key Exchange: 3DES
Data Integrity: SHA256
Renegotiate IKE SA: 86400 seconds
DH-Group: Group 2
Phase 2 IPSEC Properties:
Data Encryption: 3DES
Data Integrity: SHA256
Perfect Forward Secrecy: Enabled
Renegotiate IPSEC SA’s Every: 3600 Seconds
Additional Notes
216.231.67.57 our side10.160.242.71 cisco side
encryption failure: error occured on the implied rule
reviewed config, looks fine
most likely encryption dislike from the cisco side
he mentioned that setting the encryption to 3DES and MD5 allows the tunnel to come up
they have a conf call with them in an hour
gave him the below debug to run if the encryption tweaks on the cisco side don't resolve the issue
1. Delete all $FWDIR/log/ike.elg and vpnd.elg files
# cd $FWDIR/log/
# rm ike.elg.*
# rm vpnd.elg.*
2. Delete all IPSec+ IKE SAs for the given peer through
# vpn tu
3. Start ike debug
# vpn debug ikeon (creates the ike.elg file)
# vpn debug trunc
4. Replicate the problem
5. Stop ike debug
# vpn debug ikeoff
# vpn debug off
6. Send me all of the $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg files for further review.
----------------------------------------------------------------------------
Proxy ID - 216.231.64.0/19 (my stuff) 10.15.0.0/16 ftp
ENCRYPTION
----------
IKE Security Association (Phase 1) Properties:
-Performed Key Exchange encryption with: ASE-256
-Perform Data Integrity with: SHA-256
IPsec Security Association (Phase 2) Properties
Perform IPsec data encryptoin with: 3DES
Perform data Integrity with: MD5
TUNNEL MANAGEMENT
-----------------
- One VPN tunnel per each pair of hosts
- One VPN tunnel per subnet pair (each subnet create a new SA (security Association) proxyID is Network in the master Encryption domain
- One VPN tunnel per Gateway pair (one SA created for Gateway pair - ProxyID is 0.0.0.0.0/0.0.0.0.0)
ADVANCE VPN PROPERTIES
----------------------
VPN Routing for satellites:
To Center only
Shared Secret - peer name -shared secret
IKE Phase 1
Diffie-Hellman group: group 2 (1024 bits)
Renegotiate IKE security association every: 480 minuits
IPSec (Phase 2)
Use Perfect Forward Secrety
Diffie-Hellman group: group 2 (1024 bits)
debug files first taken didn't capture the negotiation
cisco router VPN
216.231.183.36 our side
10.160.242.171 cisco side peer 54.152.244.11
took the remote and reran them
had them go for a bit longer
reviewed the files
QM P1 failure, we send them:
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] allocateSpi: Allocated SPI: 0x570a57c2, 0 collisions (currently 1 reserved).
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] QMCreate1: rangeUsed: 1 my [0-ffffffff] peer [0-ffffffff]
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
[vpnd 5356 1988448384]@myoff-fwb.mydomain.com[24 Jun 23:42:27] RESULT: range_first 0 last ffffffff subnet_addr 0 mask 0
They don't like the all 0's subnets and return with no proposal chosen
they haven't configured their side to accept 0.0.0.0 encryption domain which we send because we have it set to "one vpn tunnel per gateway pair"
changed to "one vpn tunnel per subnet pair" and installed policy
will initiate the tunnel for testing at a later time as the other team has left
--------------------------------------------------------------------------------
Your Public IP is used for Phase I,
internal IP(s) for Phase II.
Phase II is only allowed with any particular subnet if it is defined in the encryption domain.
For example, if you had:
LAN1 = 10.0.10.0/24
LAN2 = 10.0.11.0/24
DMZ = 172.16.0.0/23
Let's say you need to encrypt LAN1 and DMZ to a DR site so you can replicate data. On the CP side, you should have/create a group, let's call it "site_a_enc_domain" for this example. You should also create network objects representing your segments listed above. You would need to add the LAN1 and DMZ network objects to that group.
Then, in gateway/cluster properties -> Topology tab -> Manually Defined: Drop down the box and select the group you created.
For Phase I setup, you need to:
1) Create an Interoperable device and define the Public IP used for the VPN
2) Create a network(s) that represents the remote side INTERNAL/PRIVATE network (or multiples and add them to a group as you did on your side)
3) Assign that group/network as the encryption domain for that remote firewall object
4) This step differs depending on Traditional or Simplified VPN mode
As for the rules you will need for Phase II... Again, that depends on what you are running - Traditional or Simplified VPN mode
At a minimum, this should allow you to look around at the others and figure it out. Let us know if you need more help.
---------------------------------------------------------------------------------
1. IKE negotation between the 2 peers
2. Can both sides see the IKE packets arriving during a key exchange?
IKE negotiation consists of two phases -
Phase I (Main mode which is six packets) and
Phase II (Quick Mode which is three packets).
Phase I negotiates encryption methods (DES/3DES/AES etc), the key length, the hash Algorithm (MD5/SHA1) and 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.
3. These are then exchanged.
4. Each peer generates a shared secret from its private key and its peers public key, this is the DH key.
5. The peers exchange DH Key material (random bits and mathematical data) and methods for PhaseII are agreed for encryption and integrity.
6. 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).
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.
If your encryption fails in Main Mode Packet 5, then you need to check the authentication - Certificates or pre-shared secrets
PHASE II
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.
In IkeView under the IP address of the peer, expand Quick Mode packet 1:
> "P2 Quick Mode ==>" for outgoing or "P2 Quick Mode <==" for incoming
> QM Packet 1
> Security Association
> prop1 PROTO_IPSEC_ESP
> tran1 ESP_AES (for an AES encrypted tunnel)
You should be able to see the SA life Type, Duration, Authentication Alg, Encapsulation Mode and Key length.
If your encryption fails here, it is one of the above Phase II settings that needs to be looked at.
There are two ID feilds in a QM packet. Under
> QM Packet 1
> ID
You should be able to see the initiators VPN Domain configuration including the type (ID_IPV4_ADDR_SUBNET) and data (ID Data field).
Under the second ID field you should be able to see the peers VPN Domain configuration.
Packet 2 from the responder agrees to its own subnet or host ID, encryption and hash algorithm.
Packet 3 completes the IKE negotiation.
If all of this works without any errors, then you may have previously initiated an invalid tunnel previously. You can use the VPN tunnel utility "vpn tu" to remove SA keys from the table.
DEBUGGING INSTRUCTIONS:
From the command line ( if cluster, active member )- vpn debug on
- vpn debug ikeon
- vpn tu
- select the option to delete IPSEC+IKE SAs for a given peer (gw)
- Try the traffic to bring up the tunnel
- vpn debug ikeoff
- vpn debug off
- $FWDIR/log/ike.elg
- $FWDIR/log/vpnd.elg
COMMON MESSAGES:
According to the Policy the Packet should not have been decrypted- The networks are not defined properly or have a typo
- Make sure VPN domains under gateway A are all local to gateway A
- Make sure VPN domains under gateway B are all local to gateway B
Wrong Remote Address
Failed to match proposal
- sk21636 – cisco side not configured for compression
No response from peer
- check encryption domains.
- remote end needs a decrypt rule
- remote firewall not setup for encryption
- somethign is blocking communication between VPN endpoints
- Check UDP 500 and protocol 50
No Valid SA
- both ends need the same definition for the encrytpion domain.
- sk19243 – (LAST OPTION) use debedit objects_5_0.c, then add subnets/hosts in users.def
- likely phase2 settings
- cisco might say ‘no proxy id allowed”
- Disable NAT inside VPN community
- Support Key exchange for subnets is properly configured
- Make sure firewall external interface is in public IP in general properties
No Proposal chosen
- sk19243 – usually cuased when a peer does not agree to VPN Domain or subnet mask
- make sure that encryption and hash match as well in Phase 2 settings
Cannot Identify Peer (to encryption connection)
- sk22102 – rules refer to an object that is not part of the local firewalls encryption domain
- may have overlapping encryption domains
- 2 peers in the same domain
- sk18972 – explains overlapping
Invalid ID
- sk25893 – Gateway: VPN-> VPN Advanced, Clear “Support key exhcnage for subnets”, Install policy
Authentication Failure
Payload Malformed
- check pre shared secrets
RESPONDER-LIFETIME
- As seen in ike debugs, make sure they match on both ends
Invalid Certificate
- sk17106 – Remote side peer object is incorrectly configured
- sk23586 – nat rules are needed
- sk18805 – multiple issues, define a static nat, add a rule, check time
- sk25262 – port 18264 has problems
- sk32648 – port 18264 problems v2
- sk15037 – make sure gateway can communicate with management
No Valid CRL
- sk32721 – CRL has expired, and module can’t get a new valid CRL
AddNegotiation
- FW-1 is handling more than 200 key negotiations at once
- vSet maximum concurrent IKE connections
Could not get SAs from packet
FW MONITOR NOTES
- packet comes back i I o O
- packet will be ESP between o and O
BASIC STUFF TO CHECK IN THE CONFIGURATION:
Accept FW-1 Control Connections
VPN domains
- setup in the topology of that item
- using topology is recommended, but you must define
- looking for overlap, or missing networks.
- Check remote and local objects.
Encryption Domains
- your firewall contains your networks
- their firewall contains their networks
Rule Setup
- you need a rule for the originator.
- Reply rule is only required for 2 way tunnel
Preshared secret or certificate
- Make sure times are accurate
Security rulebase
- make sure there are rules to allow the traffic
Address Translation
- be aware that this will effect the Phase 2 negotiations
- most people disable NAT in the community
Community Properties
- Tunnel management, Phase1 Phase2 encrypt settings.
Link selection
Routing
- make sure that the destination is routed across the interface that you want it to encrypt on
- you need IP proto 50 and 51 fo IPSEC related traffic
- you need port 500 UDP for IKE
- netstat -rn and look for a single valid default route
Smartview Tracker Logs
- purple = encrypted
- red = dropped
- green = no encryption
TRADITIONAL MODE NOTES
- can’t VPN Route
- encryption happens when you hit explicit rule
- rules must be created
SIMPLIFIED MODE NOTES
- VPN Communities
- Encryption happens at rule 0
- rules are implied
CHECKLIST
- Define encryption domains for each site
- Define firewall workstation objects for each site
- Configure the gateway objects for the correct encryption domain
- Configure the extranet community with the appropriate gateways and objects
- Create the necessary encryption rules.
- Configure the encryption properties for each encryption rule.
- Install the security Policy
IKE PACKET MODE QUICK REFERENCE
- – > outgoing
- < – incoming
- 1 > Pre shared Secrets, Encryption & hash Algorithims, Auth method, inititor cookie (clear text)
- 2 < agree on one encryption & hash, responder cookie (clear text)
- 3 > random numbers sent to prove identity (if it fails here, reinstall)
- 4 < random numbers sent to prove identity (if it fails here, reinstall)
- 5 > authentication between peers, peers ip address, certificates exchange, shared secrets, expired certs, time offsets
- 6 < peer has agreed to the proposal and has authenticated initiator, expired certs, time offsets
- 1 > Use a subnet or a host ID, Encryption, hash, ID data
- 2 < agrees with it’s own subnet or host ID and encryption and hash
- 3 > completes IKE negotiation
GOOD SKS to KNOW
- sk31221 – The NGX Advanced Troubleshooting Reference Guide (ATRG)
- sk26362 – Troubleshooting MTU related issues
- sk30509 – Configuring VPN-1/FireWall-1
- sk31567 – What is ike.elg?
- sk20277 – “Tunnel failure, cannot find IPSec methods of the community (VPN Error code 01)” appears
- sk31279 – Files copied over encrypted tunnel displaying error: “network path is too deep”
- sk32648 – Site-to-site VPN using certificates issued by the ICA (Internal Certificate Authority) fails
- sk19243 – largest possible subnet even when the largest_possible_subnet option is set to false
- sk31619 – VPN tunnel is down troubleshooting
- sk19599 – how to edit user.def for largest possible subnets & host only
| Solution ID | sk33327 |
| Product | IPSec VPN |
| Version | All |
| Platform / Model | All |
| Date Created | 26-Jul-2007 |
| Last Modified | 20-Dec-2015 |
Turn on Debug and Capture Log Files
- vpn debug trunc
- vpn debug on TDERROR_ALL_ALL=5
- fwaccel off
- fwaccel stat
- fw monitor -e "accept;" -o /var/log/fw_monitor.cap or
- fw monitor -e "accept port(500) or port(4500);" -o /var/log/fw_monitor.cap
- vpn debug mon
- vpn tu
- vpn debug truncoff
- fwaccel on
- fwaccel stat
Log Files ---------
$FWDIR/log/ike.elg*$FWDIR/log/vpnd.elg*$FWDIR/log/ikemonitor.snoop/var/log/fw_monitor.cap
$FWDIR/log/ike.elg*$FWDIR/log/vpnd.elg*$FWDIR/log/ikemonitor.snoop/var/log/fw_monitor.cap
Notes:vpn debug trunc - This command initiates both VPND debug and IKE debugvpn debug on TDERROR_ALL_ALL=5 - the level of detail providedfwaccel off - Disable SecureXL
Solution
It is very helpful to gather the IKE information in both directions. This allows you to see what each VPN Gateway proposes to the other in order to reconcile the differences.
This can be done by having both endpoints initiate communications at different times and generating debug output for IKE and VPND on both sides.
These debugs are valid for VPN connections between SecureClient and Security Gateways, as well as for Site-to-Site VPN connections.
Note: This article is also relevant for Site-to-Site VPN with 3rd Party VPN Gateways.
Follow the steps below to generate debug information:
Note: For SecurePlatform or Gaia OS, you must be logged in as Expert.
This can be done by having both endpoints initiate communications at different times and generating debug output for IKE and VPND on both sides.
These debugs are valid for VPN connections between SecureClient and Security Gateways, as well as for Site-to-Site VPN connections.
Note: This article is also relevant for Site-to-Site VPN with 3rd Party VPN Gateways.
Follow the steps below to generate debug information:
Note: For SecurePlatform or Gaia OS, you must be logged in as Expert.
- Initiate debug of VPND daemon on Check Point Security Gateway from the CLI:
[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'. - Disable SecureXL:
[Expert@HostName]# fwaccel off[Expert@HostName]# fwaccel stat - 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. - 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. - Then select the option "
Delete all IPsec+IKE SAs for a given peer (GW)". - Enter your remote Security Gateway IP address.
- 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. - Reproduce the issue, attempt to connect FROM YOUR NETWORK to a device in the remote encryption domain. This initiates the tunnel.
- 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. - Select the option that "
Delete all IPsec+IKE SAs for a given peer (GW)". - Enter your remote Security Gateway IP address.
- Exit from the '
vpn tu' the utility. - Reproduce the issue, attempt to connect FROM THE REMOTE NETWORK to a device in the local encryption domain. This initiates the tunnel.
- 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'. - Stop packet capture by pressing "CTRL+C".
- If SecureXL was disabled, re-enable it:
[Expert@HostName]# fwaccel on[Expert@HostName]# fwaccel stat - 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
How to run complete VPN debug on Security Gateway to troubleshoot VPN issues?
| Solution ID | sk63560 |
| Product | IPSec VPN |
| Version | NGX R65, R70, R71, R75, R76, R77, R77.10, R77.20, R77.30 |
| Platform / Model | All |
| Date Created | 16-Jun-2011 |
| Last Modified | 13-Aug-2015 |
Solution
Important: Before running any debug, consult with Check Point Support. Depending on your specific issue, you may need to set different debug flags.
Perform the following debug procedure on the problematic VPN Security Gateway.
Note: In cluster environment, this procedure must be performed on all members of the cluster.
Perform the following debug procedure on the problematic VPN Security Gateway.
Note: In cluster environment, this procedure must be performed on all members of the cluster.
- 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.
The following menu will be displayed (available options differ between Security Gateway versions):
********** Select Option ********** (1) List all IKE SAs (2) List all IPsec SAs (3) List all IKE SAs for a given peer (GW) or user (Client) (4) List all IPsec SAs for a given peer (GW) or user (Client) (5) Delete all IPsec SAs for a given peer (GW) (6) Delete all IPsec SAs for a given User (Client) (7) Delete all IPsec+IKE SAs for a given peer (GW) (8) Delete all IPsec+IKE SAs for a given User (Client) (9) Delete all IPsec SAs for ALL peers and users (0) Delete all IPsec+IKE SAs for ALL peers and users (Q) Quit *******************************************
Select the relevant option:
- Either delete all IPsec SAs for a given peer (GW) (option #5 in current example) and enter IP address of the involved remote site,
- Or delete all IPsec+IKE SAs for a given peer (GW) (option #7 in current example) (this will delete the IPsec and IKE SAs and will send a delete IKE SA packet to the remote site telling it to take down the existing tunnel).
- Enable VPND and IKE debug:
[Expert@HostName]# vpn debug trunc
[Expert@HostName]# vpn debug on TDERROR_ALL_ALL=5 - Start FW Monitor:
Note: For syntax, refer to sk30583 - What is FW Monitor?.
[Expert@HostName]# fw monitor -e "accept;" -o /var/log/fw_mon_traffic.cap - Start kernel debug in a new shell:
[Expert@HostName]# fw ctl debug 0
[Expert@HostName]# fw ctl debug -buf 32000
[Expert@HostName]# fw ctl debug -m fw + conn drop vm crypt
[Expert@HostName]# fw ctl debug -m VPN all
[Expert@HostName]# fw ctl kdebug -T -f > /var/log/kernel_debug.txt - Initialize traffic from both sides through the VPN tunnel.
- Replicate the issue.
- Stop kernel debug:
Press CTRL-C and run
[Expert@HostName]# fw ctl debug 0 - Stop FW Monitor:
Press CTRL-C - Stop VPND and IKE debug:
[Expert@HostName]# vpn debug off
[Expert@HostName]# vpn debug ikeoff - Collect and send the following files to Check Point Support:
/var/log/fw_mon_traffic.capfrom the Security Gateway/var/log/kernel_debug.txtfrom the Security Gateway$FWDIR/log/ike.elg*from the Security Gateway$FWDIR/log/ikev2.xml*from the Security Gateway$FWDIR/log/vpnd.elg*from the Security Gateway- Relevant IP addresses, which are involved in the VPN issue
- CPinfo file from the Security Gateway
- CPinfo file from the Security Management Server (that manages this Security Gateway)
