[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