Hi, Once we had a lot of trouble with checkpoint too.
While to one company ( also using a chekpoint ) every thing works fine, a vpn to a other company using checkpoint gave a lot trouble. we used "rather standard" 3des-md5 to both directions. One problem was located on the checkpoint side - they where using a kind of securitiy "Cloud" instead of just making a dedicate tunnel. the other problem was chosing the right proposal. keep in mind that openbsd defaults to diffie-hellman group 2 for PFS. A paper which helped us a lot in debugging was: http://www.icsalabs.com/icsa/docs/html/communities/ipsec/IPsec_Advanced_Toubleshooting_GuideFinal.pdf This helped us a lot for seeing which proposals were offerd and we adjusted your isakmpd.conf acordingly. Kind regards, Stefan > -----Urspr|ngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Im Auftrag von Olivier Horn > Gesendet: Donnerstag, 11. Januar 2007 18:15 > An: misc@openbsd.org > Betreff: VPN/IPSEC trouble with Checkpoint > > Hi all! > I have a problem with a VPN tunnel. > > The VPN is set between an OpenBSD 4.0 GENERIC and a Checkpoint NG FP3. > When I etablish the tunnel all is okay for a while. But after a moment > (variable) the tunnel break because a NO_PROPOSAL_CHOSEN. The > problem appear to come from the OpenBSD side (see log below) > and that for 3.9 and 4.0. The isakmpd config file are very basic. > > I have to kill the isakmpd process and start it again (for a > variable moment only until a new NO_PROPOSAL_CHOSEN). > > From the log : > Dec 28 14:56:28 uranium isakmpd[21562]: attribute_unacceptable: > AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG Dec > 28 14:56:28 uranium isakmpd[21562]: ike_phase_1_validate_prop: > failure > Dec 28 14:56:28 uranium isakmpd[21562]: message_negotiate_sa: > proposal 1 failed Dec 28 14:56:28 uranium isakmpd[21562]: > message_negotiate_sa: no compatible proposal found Dec 28 > 14:56:28 uranium isakmpd[21562]: dropped message from > xxx.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN > > The Checkpoint side has 3DES/SHA/GRP2 with PRE-SHARED Secret > for Phase 1 and 3DES/SHA for Phase2 enabled. > > As somebody encoutered the same problem or have a tip to > resolve this ? > > Thanks a lot in advance. > > Olivier > ------------------ > > isakmpd.conf > > [General] > Retransmits= 5 > #Exchange-max-time= 120 > Exchange-max-time= 20 > Check-interval= 10 > Listen-on= xxx.xxx.xxx.xxx > #Default-phase-1-lifetime= 86400 > #Default-phase-2-lifetime= 3600 > DPD-check-interval= 20 > > [Phase 1] > Other= ISAKMP-peer-node-Other > > [Phase 2] > Connections= IPsec-Conn-Home-Other > > # ISAKMP Phase 1 peer sections > > [ISAKMP-peer-node-Other] > Phase= 1 > Address= XXX.XXX.XXX.XXX > Configuration= Default-main-mode > Authentication= TheGreatSecret > > # IPsec Phase 2 sections > > [IPsec-Conn-Home-Other] > Phase= 2 > ISAKMP-peer= ISAKMP-peer-node-Other > Configuration= Default-quick-mode > Local-ID= MyNet > Remote-ID= OtherNet > > # Client ID sections > > [MyNet] > ID-type= IPV4_ADDR_SUBNET > Network= 192.168.1.0 > Netmask= 255.255.255.0 > > [OtherNet] > ID-type= IPV4_ADDR_SUBNET > Network= 192.168.2.0 > Netmask= 255.255.255.0 > > # Main mode description > > [Default-main-mode] > DOI= IPSEC > EXCHANGE_TYPE= ID_PROT > Transforms= 3DES-SHA-GRP2 > > # Quick mode description > > [Default-quick-mode] > DOI= IPSEC > EXCHANGE_TYPE= QUICK_MODE > Suites= QM-ESP-3DES-SHA-SUITE > > ------------------- > isakmpd.policy > > KeyNote-Version: 2 > Comment: This policy accepts ESP SAs from a remote that uses > the right password > $OpenBSD: policy,v 1.6 2001/06/20 16:36:19 angelos Exp $ > $EOM: policy,v 1.6 2000/10/09 22:08:30 angelos Exp $ > Authorizer: "POLICY" > Conditions: app_domain == "IPsec policy" && esp_present == > "yes" && esp_enc_alg != "null" -> "true";
