[strongSwan] IKEv2 StrongSwan to Cisco IOS 15.1 interop quirks: some 'attributes failed'

[Richard Chan]

Thanks Martin - glad to know that these are abstruse corner cases.


In the interest saving hair-pulling from others I am sharing here my
StrongSwan to IOS 15.1 IKEv2 setup. I am not using any EAP on the IOS side.


!--- StrongSwan Roadwarrior to IOS 15.1 headend
conn roadw
    left=%defaultroute
    leftsourceip=%config
    leftcert=mycert.crt
    right=1.2.3.4
    rightsubnet=192.168.10.0/24,192.168.11.0/24
    rightid="CN=IOS15"
    rightca="CN=IOS-CA"
    ike=aes256-sha1-modp1536
    esp=aes256-sha1
    auto=add
    authby=pubkey
    keyexchange=ikev2

!--- Cisco IOS 15.1 using crypto maps
aaa new-model
aaa authorization network MYLOCAL local
!
ip local pool pool.ROADW 192.168.87.33 192.168.87.63
!
access-list 199 permit ip 192.168.10.0 0.0.0.255 any
access-list 199 permit ip 192.168.11.0 0.255.255.255 any
!
crypto pki certificate map CERTMAP 10
 subject-name co ou = roadw
!
crypto ikev2 name-mangler MANGLER
 dn organization-unit
!
crypto ikev2 authorization policy ROADW
 pool pool.ROADW
 netmask 255.255.255.0
 subnet-acl 199
!
crypto ikev2 proposal AES256
 encryption aes-cbc-256
 integrity sha1
 group 5
!
crypto ikev2 policy ROADW
 proposal AES256
!
crypto ikev2 profile ROADW
 match certificate CERTMAP
 identity local dn
 authentication local rsa-sig
 authentication remote rsa-sig
 pki trustpoint IOS-CA
 aaa authorization group MYLOCAL name-mangler MANGLER
!
crypto dynamic-map ROADW 100
 set ikev2-profile ROADW
 reverse-route
!
crypto map STATIC 20000 ipsec-isakmp dynamic ROADW
!
interface GigabitEthernet0/2
 crypto map STATIC
!






















On Wed, Oct 12, 2011 at 4:35 PM, Martin Willi <martin at strongswan.org> wrote:

> Hi,
>
> > Much to my pleasant surprise I was able to set up a RW connection to a
> > Cisco IOS 15.1 headend using IKEv2. Kudos so the StrongSwan team!
>
> That's good to hear!
>
> > handling INTERNAL_IP4_NETMASK attribute failed
> > handling INTERNAL_IP4_SUBNET attribute failed
> > handling INTERNAL_IP4_SUBNET attribute failed
>
> We don't interpret these attributes. Their purpose is not fully clear
> from the standard.
>
> The netmask could be used to define a broadcast domain, but we currently
> don't send broadcasts over a "routed path".
>
> The subnet attribute is superfluous, as the destination networks are
> negotiated using traffic selectors. There are some theoretical uses of
> this attribute discussed in RFC 5996 3.15.2, but we currently don't
> handle it at all.
>
> Best regards
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20111013/3a125c5c/attachment.html>