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, DNS:www.ip6.dom.com,
> 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
>
>
>
--
