This indeed does help. Moved the policy to be the first. Thank you,
- Igor On 2017-06-06 05:56, Zé Loff wrote: > On Mon, Jun 05, 2017 at 07:50:01PM -0400, Igor V. Gubenko wrote: > >> Hello all, >> >> I am continuing my assault on iked.... :) >> >> Here is a perfectly working configuration that uses PSK's: >> >> ########### >> >> local_ip = "A.B.1.153" >> local_net = "172.16.0.0/20" >> >> ikev2 "KBweb" \ >> passive ipcomp esp \ >> from $local_net to 10.33.33.0/27 \ >> local $local_ip \ >> peer C.D.65.236 \ >> ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \ >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> srcid $local_ip \ >> dstid web01.domain.org \ >> psk thepsk >> >> ikev2 "KBDB" \ >> passive ipcomp esp \ >> from $local_net to 10.34.34.0/27 \ >> local $local_ip \ >> peer C.D.65.237 \ >> ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \ >> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \ >> srcid $local_ip \ >> dstid db01.domain.org \ >> psk thepsk >> >> ############### >> >> Now, I am adding a third connection, using certificates (presumably): >> >> ###### >> >> user "igor" "thepassword" >> >> ikev2 "roaming" \ >> passive esp \ >> from $local_net to 192.168.200.0/26 \ >> local $local_ip \ >> peer any \ >> eap "mschap-v2" \ >> config address 192.168.200.1 \ >> tag "$name-$id" >> >> ###### >> >> This results in the first 2 connections never working anymore: >> >> ikev2_msg_auth: responder auth data length 525 >> ikev2_msg_auth: initiator auth data length 488 >> ikev2_msg_authverify: method SHARED_KEY_MIC keylen 32 type NONE >> ikev2_msg_authverify: authentication successful >> sa_state: AUTH_REQUEST -> AUTH_SUCCESS >> sa_stateflags: 0x0028 -> 0x0038 auth,authvalid,sa (required 0x0079 >> cert,auth,authvalid,sa,eapvalid) >> ikev2_sa_negotiate: score 4 >> sa_stateflags: 0x0038 -> 0x0038 auth,authvalid,sa (required 0x0079 >> cert,auth,authvalid,sa,eapvalid) >> sa_stateok: VALID flags 0x0038, require 0x0079 >> cert,auth,authvalid,sa,eapvalid >> sa_state: cannot switch: AUTH_SUCCESS -> VALID >> ikev2_ike_auth: no CERTREQ, using default >> ikev2_policy2id: srcid IPV4/A.B.1.153 length 8 >> sa_stateflags: 0x0038 -> 0x003c certreq,auth,authvalid,sa (required >> 0x0079 cert,auth,authvalid,sa,eapvalid) >> config_free_proposals: free 0x23ee58d3f80 >> ca_getreq: found CA /C=US/ST=New Jersey/O=Gubenko/OU=IT/CN=cainter.dom.com >> ca_x509_subjectaltname: unsupported subjectAltName type 34 >> ca_getreq: found CA /C=US/ST=New >> Jersey/L=Livingston/O=Gubenko/OU=IT/CN=caroot.dom.com >> ca_getreq: no valid local certificate found >> ikev2_getimsgdata: imsg 19 rspi 0xbd166184c4d2d33b ispi >> 0xd7fc1a37a3acdec4 initiator 0 sa valid type 0 data length 0 >> ikev2_dispatch_cert: cert type NONE length 0, ignored >> >> As a side note, the certificate does contain several subjectAltName's: >> >> X509v3 Subject Alternative Name: >> DNS:ip6.dom.com, DNS:www.dom.com [1], DNS:www.ip6.dom.com [2], >> DNS:mail.dom.com, DNS:imap.dom.com, DNS:smtp.dom.com, DNS:proxy.dom.com, >> DNS:vpn.dom.com, DNS:pbx.dom.com >> >> As soon as the third section is commented out, and iked restarted, the >> first two connections come back up. >> >> Please help. > > RTFM > > From iked.conf(5): > > For incoming connections from remote peers, the policies are evaluated > in sequential order, from first to last. The last matching policy > decides what action is taken; if no policy matches the connection, the > default action is to ignore the connection attempt or to use the > default policy, if set. Please also see the EXAMPLES section for a > detailed example of the policy evaluation. > > (...) > > EXAMPLES > > (...) > > The following example illustrates the last matching policy evaluation > for incoming connections on an IKEv2 gateway. The peer 192.168.1.34 > will always match the first policy because of the quick keyword; > connections from the peers 192.168.1.3 and 192.168.1.2 will be matched > by one of the last two policies; any other connections from > 192.168.1.0/24 will be matched by the 'subnet' policy; and any other > connection will be matched by the 'catch all' policy. > > ikev2 quick esp from 10.10.10.0/24 to 10.20.20.0/24 \ > peer 192.168.1.34 > ikev2 "catch all" esp from 10.0.1.0/24 to 10.0.2.0/24 \ > peer any ikev2 "subnet" esp from 10.0.3.0/24 to 10.0.4.0/24 \ > peer 192.168.1.0/24 > ikev2 esp from 10.0.5.0/30 to 10.0.5.4/30 peer 192.168.1.2 > ikev2 esp from 10.0.5.8/30 to 10.0.5.12/30 peer 192.168.1.3 > > In summary you have a "last matching policy" and a "peer any" on the > last rule. Does it work if you move it upwards or add "quick" to the > other rules? > >> Many thanks, >> >> - Igor Links: ------ [1] http://www.dom.com [2] http://www.ip6.dom.com
