From: Alex A. <Ale...@au...> - 2009-07-14 12:38:36
|
Hi, I think that I found a bug in "port matching" code in ipsec-tools 0.6.5 (from CentOS 5.3), 0.7.2 and 0.8 alpha. This bug, if my interpretation is correct, prevents proper interworking between Linux and Solaris 10 machines in certain IPSEC/IKE configurations. The problem is in the cmpsaddrwild() function inside src/racoon/sockmisc.c file and is caused by the fact that the current implementation treats port 0 in addr1 (subject address) as a wildcard. To demonstrate the problem that I'm talking about, consider the scenario where IPSEC is configured in transport mode between two machines (Linux and Solaris) for all traffic except the SSH. In order to do this, the following configuration is added: on Linux side: # bypass SSH traffic spdadd 10.7.1.1[22] 10.7.1.2 any -P out none; spdadd 10.7.1.2 10.7.1.1[22] any -P in none; # encrypt all the rest spdadd 10.7.1.1 10.7.1.2 any -P out ipsec spdadd 10.7.1.2 10.7.1.1 any -P in ipsec on Solaris side: # bypass SSH traffic { laddr 10.7.1.2 raddr 10.7.1.1 rport 22 dir in} bypass {} { laddr 10.7.1.2 raddr 10.7.1.1 rport 22 dir out} bypass {} # encrypt all the rest { laddr 10.7.1.2 raddr 10.7.1.1 } ipsec { encr_algs any encr_auth_algs any } When Solaris tries to negotiate IKE QuickMode, it fails at Phase 2 and the following logs are produced by raccoon (on Linux side): 2009-07-13 09:15:14: DEBUG: get sa info: 2009-07-13 09:15:14: DEBUG: get a src address from ID payload 10.7.6.19[0] prefixlen=32 ul_proto=255 2009-07-13 09:15:14: DEBUG: get dst address from ID payload 10.7.9.231[0] prefixlen=32 ul_proto=255 2009-07-13 09:15:14: DEBUG: begin. 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: seen nptype=2(prop) 2009-07-13 09:15:14: DEBUG: succeed. 2009-07-13 09:15:14: DEBUG: begin. 2009-07-13 09:15:14: DEBUG: seen nptype=3(trns) 2009-07-13 09:15:14: DEBUG: succeed. 2009-07-13 09:15:14: DEBUG: sub:0xbf8248b8: 10.7.1.2/32[0] 10.7.1.1/32[0] proto=any dir=in 2009-07-13 09:15:14: DEBUG: db: 0x92d1310: 10.7.1.2/32[0] 10.7.1.1/32[22] proto=any dir=in 2009-07-13 09:15:14: DEBUG: 0xbf8248b8 masked with /32: 10.7.1.2[0] 2009-07-13 09:15:14: DEBUG: 0x92d1310 masked with /32: 10.7.1.1[0] 2009-07-13 09:15:14: DEBUG: 0xbf8248b8 masked with /32: 10.7.1.2[0] 2009-07-13 09:15:14: DEBUG: 0x92d1310 masked with /32: 10.7.1.1[22] 2009-07-13 09:15:14: DEBUG: sub:0xbf8248b8: 10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out 2009-07-13 09:15:14: DEBUG: db: 0x92d1310: 10.7.1.2/32[0] 10.7.1.1/32[22] proto=any dir=in 2009-07-13 09:15:14: DEBUG: sub:0xbf8248b8: 10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out 2009-07-13 09:15:14: DEBUG: db: 0x92dbfa0: 10.7.1.1/32[22] 10.7.1.2/32[0] proto=any dir=out 2009-07-13 09:15:14: DEBUG: 0xbf8248b8 masked with /32: 10.7.1.1[0] 2009-07-13 09:15:14: DEBUG: 0x92dbfa0 masked with /32: 10.7.1.1[22] 2009-07-13 09:15:14: DEBUG: 0xbf8248b8 masked with /32: 10.7.1.2[0] 2009-07-13 09:15:14: DEBUG: 0x92dbfa0 masked with /32: 10.7.1.2[0] 2009-07-13 09:15:14: DEBUG: suitable SP found:10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out 2009-07-13 09:15:14: ERROR: policy found, but no IPsec required: 10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out 2009-07-13 09:15:14: ERROR: failed to get proposal for responder. 2009-07-13 09:15:14: ERROR: failed to pre-process packet. As you can see above, racoon matches "10.7.1.1/32[0] 10.7.1.2/32[0]" subject to the "SSH bypass" db entry (10.7.1.1/32[22] 10.7.1.2/32[0] proto=any dir=out") and since the latter says "none" it fails the Quick Mode. It's worth noting that when two Linux servers negotiate Quick Mode, the subject Addresses have port 500 in them and therefore the connection is successfully established even without my fix. The fix in question is pretty trivial and looks as follows: --- ipsec-tools-0.6.5/src/racoon/sockmisc.c.orig 2009-07-13 16:54:26.000000000 +0300 +++ ipsec-tools-0.6.5/src/racoon/sockmisc.c 2009-07-13 16:55:31.000000000 +0300 @@ -161,8 +161,7 @@ cmpsaddrwild(addr1, addr2) sa2 = (caddr_t)&((struct sockaddr_in *)addr2)->sin_addr; port1 = ((struct sockaddr_in *)addr1)->sin_port; port2 = ((struct sockaddr_in *)addr2)->sin_port; - if (!(port1 == IPSEC_PORT_ANY || - port2 == IPSEC_PORT_ANY || + if (!(port2 == IPSEC_PORT_ANY || port1 == port2)) return 1; if (memcmp(sa1, sa2, sizeof(struct in_addr)) != 0) @@ -174,8 +174,7 @@ cmpsaddrwild(addr1, addr2) sa2 = (caddr_t)&((struct sockaddr_in6 *)addr2)->sin6_addr; port1 = ((struct sockaddr_in6 *)addr1)->sin6_port; port2 = ((struct sockaddr_in6 *)addr2)->sin6_port; - if (!(port1 == IPSEC_PORT_ANY || - port2 == IPSEC_PORT_ANY || + if (!(port2 == IPSEC_PORT_ANY || port1 == port2)) return 1; if (memcmp(sa1, sa2, sizeof(struct in6_addr)) != 0) After applying the fix, I was able to successfully establish IPSEC Connections between both Linux and Solaris machines, as well as between 2 different Linux machines. A few notes: 1) cmpsaddrwild() function that I patched is called ONLY from the cmpspidxwild() function inside the policy.c file. The latter has the following comment: * compare policyindex, with wildcard address/protocol match. * a: subject b: db, can contain wildcard things. which is consistent with the fix I'm proposing. 2) cmpspidxwild() function inside the policy.c file has the following test in 0.7.2 that seems to treat "any" protocol in subject as a wildcard too: if (!(a->ul_proto == IPSEC_ULPROTO_ANY || b->ul_proto == IPSEC_ULPROTO_ANY || a->ul_proto == b->ul_proto)) return 1; in 0.8 alpha this is fixed to treat only db entry as a wildcard: if (!(b->ul_proto == IPSEC_ULPROTO_ANY || a->ul_proto == b->ul_proto)) return 1; so again, looks like this is consistent with my fix. Regards, Alex This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message |
From: Brian H. <bri...@hp...> - 2009-08-19 18:15:36
|
Alex Agranov wrote: > 2009-07-13 09:15:14: ERROR: policy found, but no IPsec required: 10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out > 2009-07-13 09:15:14: ERROR: failed to get proposal for responder. > 2009-07-13 09:15:14: ERROR: failed to pre-process packet. I was seeing a similar problem, but applying this patch didn't fix it, instead I see: 2009-08-19 10:38:28: ERROR: no policy found: 3ffe:bad:face::2:1/128[500] 3ffe:bad:face::1:5/128[500] proto=any dir=in 2009-08-19 10:38:28: ERROR: failed to get proposal for responder. 2009-08-19 10:38:28: ERROR: failed to pre-process packet. I'm running 0.7.1, but tried 0.7.3 as well (can't get 0.8 running at the moment). I'll explain my config since I'm not sure it's exactly correct: Local address: 3ffe:bad:face::1:5 Remote address: 3ffe:bad:face::2:1 spdadd ::/0 ::/0 icmp6 -P in none; spdadd ::/0 ::/0 icmp6 -P out none; spdadd 3ffe:bad:face::1:5[7] 3ffe:bad:face::2:1[2000] any -P out ipsec esp/transport//require; spdadd 3ffe:bad:face::2:1[2000] 3ffe:bad:face::1:5[7] any -P in ipsec esp/transport//require; racoon.conf: remote anonymous { exchange_mode base ; my_identifier asn1dn ; certificate_type x509 "host1_cert.pem" "host1_key.pem" ; dpd_delay 3 ; proposal { encryption_algorithm 3des ; hash_algorithm md5 ; authentication_method rsasig ; dh_group modp768 ; } } sainfo address 3ffe:bad:face::1:5 any address 3ffe:bad:face::2:1 any { pfs_group modp1024; encryption_algorithm aes; authentication_algorithm hmac_md5; compression_algorithm deflate; } If I bind the remote address to 2:1[2000] and try and connect to 1:5[7] it fails with this config. Changing everything from "any" to "tcp" makes it all work properly, which is why I think it might be the config. -Brian |
From: Alex A. <Ale...@au...> - 2009-08-19 19:34:13
|
v0.7.3 has a similar bug in "protocol matching" code - inside cmpspidxwild() function in src/racoon/policy.c file. It's fixed in 0.8 alpha - but you can easily back-port it to 0.7 tree... Hope this helps... Alex ________________________________________ From: Brian Haley [bri...@hp...] Sent: Wednesday, August 19, 2009 9:15 PM To: Alex Agranov Cc: ips...@li... Subject: Re: [Ipsec-tools-devel] Bug in port matching code (solves interop with Solaris 10) Alex Agranov wrote: > 2009-07-13 09:15:14: ERROR: policy found, but no IPsec required: 10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out > 2009-07-13 09:15:14: ERROR: failed to get proposal for responder. > 2009-07-13 09:15:14: ERROR: failed to pre-process packet. I was seeing a similar problem, but applying this patch didn't fix it, instead I see: 2009-08-19 10:38:28: ERROR: no policy found: 3ffe:bad:face::2:1/128[500] 3ffe:bad:face::1:5/128[500] proto=any dir=in 2009-08-19 10:38:28: ERROR: failed to get proposal for responder. 2009-08-19 10:38:28: ERROR: failed to pre-process packet. I'm running 0.7.1, but tried 0.7.3 as well (can't get 0.8 running at the moment). I'll explain my config since I'm not sure it's exactly correct: Local address: 3ffe:bad:face::1:5 Remote address: 3ffe:bad:face::2:1 spdadd ::/0 ::/0 icmp6 -P in none; spdadd ::/0 ::/0 icmp6 -P out none; spdadd 3ffe:bad:face::1:5[7] 3ffe:bad:face::2:1[2000] any -P out ipsec esp/transport//require; spdadd 3ffe:bad:face::2:1[2000] 3ffe:bad:face::1:5[7] any -P in ipsec esp/transport//require; racoon.conf: remote anonymous { exchange_mode base ; my_identifier asn1dn ; certificate_type x509 "host1_cert.pem" "host1_key.pem" ; dpd_delay 3 ; proposal { encryption_algorithm 3des ; hash_algorithm md5 ; authentication_method rsasig ; dh_group modp768 ; } } sainfo address 3ffe:bad:face::1:5 any address 3ffe:bad:face::2:1 any { pfs_group modp1024; encryption_algorithm aes; authentication_algorithm hmac_md5; compression_algorithm deflate; } If I bind the remote address to 2:1[2000] and try and connect to 1:5[7] it fails with this config. Changing everything from "any" to "tcp" makes it all work properly, which is why I think it might be the config. -Brian This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message |
From: Brian H. <bri...@hp...> - 2009-09-01 18:59:48
|
Brian Haley wrote: > Alex Agranov wrote: >> 2009-07-13 09:15:14: ERROR: policy found, but no IPsec required: 10.7.1.1/32[0] 10.7.1.2/32[0] proto=any dir=out >> 2009-07-13 09:15:14: ERROR: failed to get proposal for responder. >> 2009-07-13 09:15:14: ERROR: failed to pre-process packet. > > I was seeing a similar problem, but applying this patch didn't fix it, > instead I see: > > 2009-08-19 10:38:28: ERROR: no policy found: 3ffe:bad:face::2:1/128[500] 3ffe:bad:face::1:5/128[500] proto=any dir=in > 2009-08-19 10:38:28: ERROR: failed to get proposal for responder. > 2009-08-19 10:38:28: ERROR: failed to pre-process packet. > > I'm running 0.7.1, but tried 0.7.3 as well (can't get 0.8 running at the > moment). I'll explain my config since I'm not sure it's exactly correct: > > Local address: 3ffe:bad:face::1:5 > Remote address: 3ffe:bad:face::2:1 > > spdadd ::/0 ::/0 icmp6 -P in none; > spdadd ::/0 ::/0 icmp6 -P out none; > > spdadd 3ffe:bad:face::1:5[7] 3ffe:bad:face::2:1[2000] any -P out ipsec > esp/transport//require; > spdadd 3ffe:bad:face::2:1[2000] 3ffe:bad:face::1:5[7] any -P in ipsec > esp/transport//require; Just an update, this patch does help if I change this SPD entry to cover all traffic from one system to another, and not just these specific ports: spdadd 3ffe:bad:face::1:5 3ffe:bad:face::2:1 any -P out ipsec esp/transport//require; spdadd 3ffe:bad:face::2:1 3ffe:bad:face::1:5 any -P in ipsec esp/transport//require; Without the patch I get an error and Quick mode fails. Does anyone know why the responder wouldn't answer in that case? I didn't think IKE needed a policy in place in order for it to work. -Brian |