Re: ipsec vpn problem
On Fri, Aug 22, 2008 at 03:11:16PM +0200, Claus Larsen wrote: Well I did get a bit futher with the problem, it seems it was cause by a firewall blocking some of the traffic. So new problem now. Using the Greenbow vpn client. It says Phase 2 algoritm problem. From the isakmpd output I get (a larger portion of the output included below): 164658.900458 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id d5ade2e5: 213.173.226.229, responder id c0a80102: 192.168.1.2 164658.901274 Default dropped message from 213.173.226.229 port 500 due to notification type NO_PROPOSAL_CHOSEN Any idea whats going on? when this happens to me, it is a config mismatch between the two peers. sometimes the mismatch can be excruciatingly subtle. but one wrong little anything will make the flow or sa or whatever it is that the wrong peer installs end up completely not matching what the other has. at times i've resorted to doing line-by-line echo $LINE | md5 to help speed the process of finding the mismatch along. given that in this case, there's 1918 IP on one side and !1918 on the other, the 1918 peer is perhaps using its 1918 IP by default but the other peer expects him to be sending his public IP. you can also see this type of mismatch with loglines that say something like Expected: 3DES, Received: $whatever_you're_trying_to_use for the algorithm in question; has always been the same thing for me in that case, (potentially subtle) config mismatch. /etc/ipsec.conf ike passive from any to any \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group none \ psk openbsdrules hrm; i guess i'd assume 'any' would make it not care, so maybe my whole suggestion is shot. maybe for starters, copy that off to a new ike setup and specifically define the stuff that it seems the remote peer is sending that your end is complaining about, and then work back from there after you get that working. -- jared
ipsec vpn problem
Have a problem getting a vpn tunnel up between a zyxel vpn gw and my openbsd 4.3 system. /etc/ipsec.conf ike passive from any to any \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group none \ psk openbsdrules Below follows output from cmd: isakmpd -d -DA=99 -K In the output is the line: 173307.589683 Exch 90 check_vendor_openbsd: bad size 20 != 16 which does not seem to cause any problems A then futher down the line: 173307.682833 Default sendmsg (14, 0xcfbd65a0, 0): Permission denied which does not have any lines before it which (to me) explains what goes wrong. These two lines is what I found strange, but I have no idea where to go from here. Thanks, Claus 173307.533538 Trpt 70 transport_setup: added 0x7ce24ac0 to transport list 173307.534309 Trpt 70 transport_setup: added 0x7ce24b00 to transport list 173307.535214 Trpt 50 virtual_clone: old 0x7ce24680 new 0x7ce249c0 (main is 0x7ce24ac0) 173307.536014 Trpt 70 transport_setup: virtual transport 0x7ce249c0 173307.536809 Trpt 95 transport_reference: transport 0x7ce249c0 now has 1 references 173307.537700 Mesg 90 message_alloc: allocated 0x83151280 173307.538473 Mesg 70 message_recv: message 0x83151280 173307.539310 Mesg 70 ICOOKIE: 4558dc89993e4538 173307.540292 Mesg 70 RCOOKIE: 173307.540993 Mesg 70 NEXT_PAYLOAD: SA 173307.541788 Mesg 70 VERSION: 16 173307.542575 Mesg 70 EXCH_TYPE: ID_PROT 173307.543469 Mesg 70 FLAGS: [ ] 173307.544277 Mesg 70 MESSAGE_ID: 173307.544951 Mesg 70 LENGTH: 128 173307.546067 Mesg 70 message_recv: 4558dc89 993e4538 01100200 0080 0d38 173307.547105 Mesg 70 message_recv: 0001 0001 002c 01010001 0024 0101 80010005 80020002 173307.548131 Mesg 70 message_recv: 80030001 80040002 800b0001 000c0004 00015180 0d14 afcad713 68a1f1c9 173307.549317 Mesg 70 message_recv: 6b8696fc 77570100 0018 62502774 9d5ab97f 5616c160 2765cf48 0a3b7d0b 173307.550011 SA 90 sa_find: no SA matched query 173307.550936 Mesg 50 message_parse_payloads: offset 28 payload SA 173307.551623 Mesg 50 message_parse_payloads: offset 84 payload VENDOR 173307.552429 Mesg 50 message_parse_payloads: offset 104 payload VENDOR 173307.553226 Mesg 60 message_validate_payloads: payload SA at 0x8315131c of message 0x83151280 173307.554202 Mesg 70 DOI: 1 173307.554834 Mesg 70 SIT: 173307.555797 Misc 95 conf_get_str: configuration value not found [Phase 1]: 195.184.124.220 173307.556514 Misc 95 conf_get_str: [Phase 1]:Default-peer-default 173307.557474 Misc 95 conf_get_str: [peer-default]:Configuration-mm-default 173307.558177 Misc 95 conf_get_str: configuration value not found [mm-default]:DOI 173307.558977 Misc 95 conf_get_str: [mm-default]:EXCHANGE_TYPE-ID_PROT 173307.559852 Misc 95 conf_get_str: [General]:Exchange-max-time-120 173307.560688 Timr 10 timer_add_event: event exchange_free_aux(0x7de79800) added last, expiration in 120s 173307.561565 Misc 95 conf_get_str: configuration value not found [peer-default]:Flags 173307.562379 Cryp 60 hash_get: requested algorithm 1 173307.563305 Exch 10 exchange_setup_p1: 0x7de79800 peer-default mm-default policy responder phase 1 doi 1 exchange 2 step 0 173307.564149 Exch 10 exchange_setup_p1: icookie 4558dc89993e4538 rcookie a42fec0b4dc4e6f0 173307.564962 Exch 10 exchange_setup_p1: msgid 173307.565751 Trpt 95 transport_reference: transport 0x7ce249c0 now has 2 references 173307.566558 SA 80 sa_reference: SA 0x7de79900 now has 1 references 173307.567493 SA 70 sa_enter: SA 0x7de79900 added to SA list 173307.568157 SA 80 sa_reference: SA 0x7de79900 now has 2 references 173307.568944 SA 60 sa_create: sa 0x7de79900 phase 1 added to exchange 0x7de79800 (peer-default) 173307.569762 SA 80 sa_reference: SA 0x7de79900 now has 3 references 173307.570682 Mesg 50 message_parse_payloads: offset 40 payload PROPOSAL 173307.571360 Mesg 50 message_parse_payloads: offset 48 payload TRANSFORM 173307.572180 Mesg 50 Transform 1's attributes 173307.572965 Mesg 50 Attribute ENCRYPTION_ALGORITHM value 5 173307.573733 Mesg 50 Attribute HASH_ALGORITHM value 2 173307.574508 Mesg 50 Attribute AUTHENTICATION_METHOD value 1 173307.575286 Mesg 50 Attribute GROUP_DESCRIPTION value 2 173307.576066 Mesg 50 Attribute LIFE_TYPE value 1 173307.576967 Mesg 50 Attribute LIFE_DURATION value 86400 173307.577715 Mesg 60 message_validate_payloads: payload PROPOSAL at 0x83151328 of message 0x83151280 173307.578680 Mesg 70 NO: 1 173307.579317 Mesg 70 PROTO: ISAKMP 173307.580124 Mesg 70 SPI_SZ: 0 173307.580923 Mesg 70 NTRANSFORMS: 1 173307.581695 Mesg 70 SPI: 173307.582492 Mesg 60 message_validate_payloads: payload TRANSFORM at 0x83151330 of message 0x83151280 173307.583461 Mesg 70 NO: 1 173307.584108 Mesg 70 ID: 1 173307.584860 Mesg 70 SA_ATTRS: 173307.585645 Mesg 60 message_validate_payloads: payload VENDOR at 0x83151354 of message 0x83151280 173307.586462 Mesg 70 ID: 173307.587267 Exch 10 dpd_check_vendor_payload: DPD capable peer
[SOLVED] Re: Strange VPN problem
Hi, On Wed, 03.01.2007 at 22:54:16 +0100, Toni Mueller [EMAIL PROTECTED] wrote: I have a very odd problem with a VPN machine. The situation: nevermind, it was human error (expired certificates) after all. I have to find out whether the error messages should have told me this earlier on, or whether I was only too blind to see. Best, --Toni++
Strange VPN problem
Hello, I have a very odd problem with a VPN machine. The situation: Net 1 --- Host 1 - Internet - Host 2 --- Net 2 \ +- Host 3 --- Net 3 The whole thing was working since the days of 3.5 or so with ISAKMPD and X.509 certificates in tunnel mode. Last year, everything was on 3.8. Now I upgraded Host 2 to 4.0. Everything was still fine. Today I upgraded Host 1 to 4.0, then to 4.0-stable (this was required anyway, and prompted by disk failure), things stopped working completely. I see such packets being sent between hosts 1 and 2 (real IPs replaced by RFC1918 with s///): 22:37:11.106378 192.168.1.3.500 192.168.1.2.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: f06dc17173c6c1fa- msgid: len: 184 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = AES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = RSA_SIG attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 payload: VENDOR len: 20 (supports OpenBSD-4.0) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports DPD v1.0) (ttl 63, id 28972, len 212) 22:37:11.125678 192.168.1.2.500 192.168.1.3.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: len: 184 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 36 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = AES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = RSA_SIG attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute KEY_LENGTH = 128 payload: VENDOR len: 20 (supports OpenBSD-4.0) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports DPD v1.0) (ttl 64, id 35720, len 212) 22:37:11.274135 192.168.1.3.500 192.168.1.2.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D len: 24 payload: NAT-D len: 24 (ttl 63, id 4431, len 256) 22:37:11.349204 192.168.1.2.500 192.168.1.3.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D len: 24 payload: NAT-D len: 24 (ttl 64, id 32849, len 256) 22:37:11.558309 192.168.1.3.500 192.168.1.2.500: [udp sum ok] isakmp v1.0 exchange ID_PROT encrypted cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: len: 972 (ttl 63, id 3944, len 1000) 22:37:11.668529 192.168.1.2.500 192.168.1.3.500: [udp sum ok] isakmp v1.0 exchange ID_PROT encrypted cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: len: 940 (ttl 64, id 60717, len 968) 22:37:11.864217 192.168.1.3.500 192.168.1.2.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE encrypted cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: aaeca62d len: 300 (ttl 63, id 14459, len 328) 22:37:11.914359 192.168.1.2.500 192.168.1.3.500: [udp sum ok] isakmp v1.0 exchange INFO encrypted cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: 87fd8670 len: 76 (ttl 64, id 59694, len 104) 22:37:11.915785 192.168.1.2.500 192.168.1.3.500: [udp sum ok] isakmp v1.0 exchange INFO encrypted cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: a7a43d6f len: 76 (ttl 64, id 45897, len 104) 22:37:18.878857 192.168.1.3.500 192.168.1.2.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE encrypted cookie: f06dc17173c6c1fa-3a8a72a4e10f97c3 msgid: aaeca62d len: 300 (ttl 63, id 25088, len 328) 22:37:18.976186 192.168.1.2.500 192.168.1.3.500: [udp sum ok] isakmp v1.0 exchange INFO encrypted
vpn problem
Hello all, Currently my brother and I try to set up a vpn using isakmpd between two OBSD 3.8 boxes. We had a similar vpn working before. We both changed ADSL providers and thought it is time for an upgrade. However... Our vpn refuses to work. We singled out a possible firewall problem. The pflog is quet and even after a '$pfctl -F rules' we keep the same problem. A 'tcpdump -i xl1 port 500' shows that both sided receive cookies, but nothing more: like this $ tcpdump -i xl1 port 500 13:24:47.067067 broeahs.net.isakmp daim.broeahs.net.isakmp: isakmp v1.0 exchange ID_PROT cookie: 385103343a680645-9c61c0d839d1d9ec msgid: len: 168 13:24:48.878894 daim.broeahs.net.isakmp broeahs.net.isakmp: isakmp v1.0 exchange ID_PROT cookie: 7fd785c9ee93e8fe-31884d57a94e56a0 msgid: len: 168 The debuggin' info gives messages like this: 132740.737518 Exch 40 exchange_establish_finalize: finalizing exchange 0x7cdb9b0 0 with arg 0x85e318d0 (daim-dimitri) fail = 1 132740.736495 SA 90 sa_find: no SA matched query 132641.268445 Default transport_send_messages: giving up on exchange dimitri, no response from peer 194.109.199.156:500 My question is: What is happening here? How is it possible there is traffic on both sides on port 500 but the two are not able to get decent contact? Thank you in advance. Daom confs follow: # cat /etc/isakmpd/isakmpd.policy KeyNote-Version: 2 Authorizer: POLICY Licensees: our_bad_passw Conditions: app_domain == IPsec policy esp_present == yes esp_enc_alg != null - true; # cat /etc/isakmpd/isakmpd.conf # $OpenBSD: VPN-east.conf,v 1.7 1999/10/29 07:46:04 todd Exp $ # $EOM: VPN-east.conf,v 1.7 1999/07/18 09:25:34 niklas Exp $ # A configuration sample for the isakmpd ISAKMP/Oakley (aka IKE) daemon. [General] Retransmits= 5 Exchange-max-time=120 Listen-on= xxx.xxx.xxx.xxx #Shared-SADB= Defined # Incoming phase 1 negotiations are multiplexed on the source IP address [Phase 1] yyy.yyy.yyy.yyy=dimitri # These connections are walked over after config file parsing and told # to the application layer so that it will inform us when traffic wants to # pass over them. This means we can do on-demand keying. [Phase 2] Connections= daim-dimitri [dimitri] Phase= 1 Transport= udp Local-address= xxx.xxx.xxx.xxx Address= yyy.yyy.yyy.yyy Configuration= Default-main-mode Authentication= our_bad_passw [daim-dimitri] Phase= 2 ISAKMP-peer= dimitri Configuration= Default-quick-mode Local-ID= Net-daim Remote-ID= Net-dimitri [Net-daim] ID-type= IPV4_ADDR_SUBNET Network= 192.168.0.0 Netmask= 255.255.255.0 [Net-dimitri] ID-type= IPV4_ADDR_SUBNET Network= 10.10.10.0 Netmask= 255.255.255.0 # Main mode descriptions [Default-main-mode] DOI= IPSEC EXCHANGE_TYPE= ID_PROT Transforms= DES-SHA # Main mode transforms ## # DES [DES-MD5] ENCRYPTION_ALGORITHM= DES_CBC HASH_ALGORITHM= MD5 AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_768 Life= LIFE_600_SECS,LIFE_1000_KB [DES-MD5-NO-VOL-LIFE] ENCRYPTION_ALGORITHM= DES_CBC HASH_ALGORITHM= MD5 AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_768 Life= LIFE_600_SECS [DES-SHA] ENCRYPTION_ALGORITHM= DES_CBC HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_768 Life= LIFE_600_SECS,LIFE_1000_KB # 3DES [3DES-SHA] ENCRYPTION_ALGORITHM= 3DES_CBC HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life= LIFE_3600_SECS # Blowfish [BLF-SHA-M1024] ENCRYPTION_ALGORITHM= BLOWFISH_CBC KEY_LENGTH= 128,96:192 HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life= LIFE_600_SECS,LIFE_1000_KB [BLF-SHA-EC155] ENCRYPTION_ALGORITHM= BLOWFISH_CBC KEY_LENGTH= 128,96:192 HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= EC2N_155 Life= LIFE_600_SECS,LIFE_1000_KB [BLF-MD5-EC155] ENCRYPTION_ALGORITHM= BLOWFISH_CBC KEY_LENGTH= 128,96:192 HASH_ALGORITHM= MD5 AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= EC2N_155 Life= LIFE_600_SECS,LIFE_1000_KB [BLF-SHA-EC185] ENCRYPTION_ALGORITHM= BLOWFISH_CBC KEY_LENGTH= 128,96:192 HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= EC2N_185 Life= LIFE_600_SECS,LIFE_1000_KB [3DES-MD5] ENCRYPTION_ALGORITHM= 3DES_CBC HASH_ALGORITHM= MD5 AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life= LIFE_1_DAY [CAST-SHA] ENCRYPTION_ALGORITHM= CAST_CBC HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1536 Life= LIFE_1_DAY # Quick mode description [Default-quick-mode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-SHA-PFS-SUITE,QM-ESP-3DES-SHA-PFS-SUITE,QM-ESP-DES-MD5-PFS-SUITE [Greenbow-quick-mode] DOI= IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-DES-SHA-PFS-SUITE # Quick mode protection suites ## # DES [QM-ESP-DES-SUITE] Protocols= QM-ESP-DES [QM-ESP-DES-PFS-SUITE] Protocols= QM-ESP-DES-PFS [QM-ESP-DES-MD5-SUITE] Protocols=
Re: vpn problem
--- plz? yeah plz [EMAIL PROTECTED] wrote: Hello all, Currently my brother and I try to set up a vpn using isakmpd between two OBSD 3.8 boxes. We had a similar vpn working before. We both changed ADSL providers and thought it is time for an upgrade. However... I did notice some redundancy under [Default-quick-mode]. What about the other file?
