<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hello all,<br><br>First, thank you for this great software. It's one of a kind :)<br><br>Now my problem. I think you are familiar with the problems about checkpoint. I am trying to connect to checkpoint vpn's and I think I have managed to go as far as phase 2. Below are the options I used to accomplish this. By the way, I have found all of these by trial and error.<br><br>- Auto configuration: Disabled<br>- IKE fragmentation: Disable<br>- Name resolution: manual<br>- authentication: hybrid rsa + xauth<br>- local identity : UFQDN with "cn=<username>"<br>- remote identity: ip address (use discovered)<br>- credentials: server ca certificate in pem format<br>- phase 1: main-group 2-aes-256-md5 (enabele checkpoint compatible)<br>- phase 2: esp-aes-256-md5-group 2 (compression disabled)<br>- policy: manual<br><br>According to debug logs, this establishes the
 Phase 2 SA.  However, one last thing can't be accomplished which keeps me from getting into the vpn. Let me tell you about that:<br><br>- Checkpoint securemote registers itself as a network packet filter with an ip address of 0.0.0.0.<br>- The checkpoint dhcp server leases the ip address 0.0.0.0 as well whereas the original ip address of the client in the VPN is something else. (192.168.x.x)<br>- When Shrew client sees the configuration request for 0.0.0.0, it fails to configure the interface obviously telling that it is an erroneous address.<br><br>So I tried changing the address method, giving an IP address by hand and whatever I could think of but to no avail.<br><br>If, for example, I could specify an existing tap device it would most probably solve the issue but that is not an option.<br><br>Do you have any suggestions, or could you take this as a feature request? :)<br><br>Best,<br>Volkan KURT<br></td></tr></table><br>