VPN Trouble shooting

[mhinman]

I am having some trouble with a VPN conection and was wondering what the best way to activly monitor a tunnel is. What should the creation look like? Any documents, tips, filters etc would be very helpful. Thanks everyone!

[flontous]

Did you ever get any info? Need the same!

[gavvys]

Hi
I would like to have additional information regarding troubleshooting of VPN, like settings while creating the object and community.If you are sure that settings are correct then, what logs you are getting while you are trying to connect the VPN tunnel.

I need the logs to troubleshoot this all.


Regards
Ranjit

[munrog]

Trouble shooting VPNs is covered ad infinitum in the Check Point Management II/III courseware... It's fair to say over 95% of problems are a result of configuration or cross vendor compatibility issues.

Make sure you read http://secureknowledge.checkpoint.co....do?id=sk19423 !

Most VPN debugging consists of looking at the IKE negotiation although first you should check that connectivity actually exists between the two peers. If I ping does the other end see it! Can both sides see the IKE packets arriving during a key exchange?

You need to understand the IKE process to be able to debug.

IKE negotiation consists of two phases - Phase I (Main mode which is six packets) and Phase II (Quick Mode which is three packets). The $FWDIR/log/ike.elg file contains this information (once debugging is enabled). To enable debugging, you need to login to your firewall and enter the command "vpn debug on; vpn debug ikeon" or "vpn debug trunc". Check Point have a tool called IKEView.exe which parses the information of ike.elg into a GUI making this easier to view.

Note that another useful tool is "vpn debug on mon" which writes all of the IKE captured data into a file ikemonitor.snoop which you can open with wireshark or ethereal.

So 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. 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).

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

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.

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.


I hope that this helps.
Greg

[Tan Da Boss]

Hi Greg,

really great explanations!
very useful.

Cheers

Tan

[Gremlin]

Hi all,

First of all – thank you Greg for this very useful information. And - I have a couple of questions on this topic:

A. If there is any additional information regarding two other frequent problems – one way only traffic and tunnel disconnections?
B. If there is any information regarding ike.elg + vpn.elg explanation. I familiar with the ike/ipsec processes but those 2 files are still no easy to understand (I know there is a tool called ikeview but I don’t work for organization considered as CSP so it’s seems like I’ll never put my hands on this tool) ?

Please consider both questions for multi-vendor environment (nowadays, everything is “IPSec compatible”).

Thanks in advance and Have a nice day.

[munrog]

Hi Gremlin

With respect to your questions
A. If there is any additional information regarding two other frequent problems – one way only traffic and tunnel disconnections?

One way only traffic is generally the result of one peer not having correctly established a security association.

Most frequently this is due to the way in which Check Point combines adjacent IP address networks together into supernets. ie, if you have 192.168.0.0/24 and 192.168.1.0/24, Check Point will supernet this into 192.168.0.0/23.

This is done to reduce the number of keys required and hence reduce the load on the VPN gateway. However, other VPN devices do not follow this methodology, so depending upon the version of VPN-1 you are using, you may need to set IKE_use_largest_possible_subnets or correctly configure the VPN communities tunnel management (one vpn per pair of hosts, per subnet pair or per gateway). See SecureKnowledgebase article Solution ID: #sk26336.

Tunnel disconnections can be caused either a physical connectivity problem or routing problems or once again, a mismatch in the VPN security associations. Be particularly careful with VPNs to Cisco in this regards. Plenty of times I've seen people confused between seconds and minutes! I've also seen that sometimes the Cisco ends of VPNs dont want to reset the SAs when told to by the Check Point end.

B. If there is any information regarding ike.elg + vpn.elg explanation. I familiar with the ike/ipsec processes but those 2 files are still no easy to understand (I know there is a tool called ikeview but I don’t work for organization considered as CSP so it’s seems like I’ll never put my hands on this tool) ?


From my answer above, you can see that my statement about "Most VPN debugging consists of looking at the IKE negotiation" to be true. And it is most unlikely that you will need to look into the vpnd.elg file. With respect to obtaining ikeview.exe, I would talk to your local Check Point office and see if they are accomodating.
-Greg

[Gremlin]

Many thanks ,
that was helpful .

Cheers .

[iwdafa]

Has anyone ever attempted to have VPN Tunnel (Site-2-Site) monitored and set up to receive notification (SNMP ideally) on VPN Tunnel "status change" that presents a "broken" tunnel? ( hate to hear from user.-> " VPN Tunnel is not working!!...")

Even if not tried, any idea how one may go about this?

Thanks for everyone's contribution, if any!

Fred!

[munrog]

Its quite easy, but you have to be running NGX (you can do it with NG, but it requires some manual file modifications), you have to allow tunnel_test and tunnel_test_mapped between both peers and you have to configure the connection as a permanent tunnel.

Permanent Tunnels are VPN tunnels that are constantly kept active and as a result, make it easier to recognize malfunctions and connectivity problems. You can monitor the two sides of a VPN tunnel, and identify problems without delay.

Each VPN tunnel in the community may be set to be a Permanent Tunnel.

Since Permanent Tunnels are constantly monitored, if the VPN tunnel is down, then a log, alert, or user defined action, can be issued. Permanent Tunnels can only be established between Check Point gateways.

You set permanent tunnels within the VPN community window under the tab "tunnel management". Once you enable Set Permanent Tunnels, you choose if you want all tunnels in the community, specific gateways or specific tunnels in a community. You can also select the tracking for tunnels that change state up or down. These are the usual suspects of none, log, popup alert, mail alert, snmp alert and userdefined alerts.

Set this to snmp, next go into Policy > Global Properties > Log and Alert > Alert Commands: select the checkbox next to "Run SNMP trap alert script" and in the box beside it put "internal_snmp_trap <snmptrapserver>" where <snmptrapserver> is the name or IP address of your SNMP management server that should receive the traps. After that, it's up to your SNMP management system to page you or whatever...

[desperado618]

Is the "vpn debug on mon" command still valid?
It accepts the command but does not generate the file in $FWDIR/log. I also checked the entire partition for *.snoop and there were no files.

For those interested, I have an IKEVIEW guide in my forum:
Netleets.com &bull; View topic - VPN Troubleshooting with IKEVIEW

[hunteralpha]

My experience on the same question is not all problem in check point, I solve this issue on 2008.10.14, a NG R55 with Juniper Netscreen 25, the issue is one Juniper not Check Point.

The problem is on netscreen keep ike policy so reject vpn domain exchange (netscreen call this proxy id), cause one way vpn.

On that way, netscreen to check point vpn is fine, but check point to netscreen vpn alway reject, the following is netscreen reject message.

2008-10-09 17:33:04 system info 00536 IKE<CheckPointIP> Phase 2: No policy exists for the proxy ID received: local ID (<192.168.14.0>/<255.255.254.0>, <0>, <0>) remote ID (<10.101.0.0>/<255.255.0.0>, <0>, <0>).
2008-10-09 17:33:04 system info 00536 IKE<CheckPointIP> Phase 2 msg ID <5aae18e1>: Responded to the peer's first message.
2008-10-09 17:33:00 system info 00536 IKE<CheckPointIP> Phase 2 msg ID <5aae18e1>: Negotiations have failed.
2008-10-09 17:33:00 system info 00536 Rejected an IKE packet on ethernet3 from CheckPointIP:500 to JuniperIP:500 with cookies d8264746d526c416 and 97679af0e9a7991a because the peer sent a proxy ID that did not match the one in the SA config.

So, I using the follow instruction on juniper to solve my issue.
I think this issue should version independent on NG or NGX.
Hope this help for you.

unset ike policy-checking
unset ike accept-all-proposal