Richard Chan | 12 Oct 2011 03:08
Picon

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

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!


The StrongSwan RW successfully connects with split tunneling (two subnets behind IOS). It obtains
a /32 address, and installs the xfrm correctly. Everything works as expected. There are however
some messages about attribute failed. Just wondering what these 'failed' messages mean.


(StrongSwan is behind a NAT device)
certificate status is not available
  reached self-signed root ca with a path length of 0
authentication of 'XXXX' with RSA signature successful
IKE_SA roadw2[1] established between 192.168.2.139[XXXX]...1.2.3.4[YYYY]
scheduling reauthentication in 10105s
maximum IKE_SA lifetime 10645s
handling INTERNAL_IP4_NETMASK attribute failed
handling INTERNAL_IP4_SUBNET attribute failed
handling INTERNAL_IP4_SUBNET attribute failed
installing new virtual IP 192.168.87.35


conn roadw2
    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

While this is not an IOS list, I noticed that IOS installs an
"all IP traffic to 192.168.87.35/32" selector, instead of narrowing its selectors to match StrongSwan's rightsubnets. So just incase there are some inter-op experts here

  protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.87.35/255.255.255.255/0/0)
   current_peer 1.2.3.4 port 4500
     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 1.2.3.5, remote crypto endpt.: 1.2.3.4
     path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/2
     current outbound spi: 0xCAF25434(3404878900)
     PFS (Y/N): N, DH group: none

(I am by no means an IOS 15.1 expert and it took some time to figure this out).
This split tunnel networks are specified by an acl.


Extended IP access list acl.ROADW
    10 permit ip 192.168.10.0 0.255.255.255 any
    20 permit ip 192.168.11.0 0.0.0.255 any


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 MYCA
 aaa authorization group MYLOCAL name-mangler MANGLER





<div><p>Hi,<br><br>Much to my pleasant surprise I was able to set up a RW connection to a Cisco IOS 15.1<br>headend using IKEv2. Kudos so the StrongSwan team! <br><br><br>The StrongSwan RW successfully connects with split tunneling (two subnets behind IOS). It obtains<br>
a /32 address, and installs the xfrm correctly. Everything works as expected. There are however<br>some messages about attribute failed. Just wondering what these 'failed' messages mean.<br><br><br>(StrongSwan is behind a NAT device)<br>
certificate status is not available<br>&nbsp; reached self-signed root ca with a path length of 0<br>authentication of 'XXXX' with RSA signature successful<br>IKE_SA roadw2[1] established between 192.168.2.139[XXXX]...1.2.3.4[YYYY]<br>
scheduling reauthentication in 10105s<br>maximum IKE_SA lifetime 10645s<br>handling INTERNAL_IP4_NETMASK attribute failed<br>handling INTERNAL_IP4_SUBNET attribute failed<br>handling INTERNAL_IP4_SUBNET attribute failed<br>
installing new virtual IP 192.168.87.35<br><br><br>conn roadw2<br>&nbsp;&nbsp;&nbsp; left=%defaultroute<br>&nbsp;&nbsp;&nbsp; leftsourceip=%config<br>&nbsp;&nbsp;&nbsp; leftcert=mycert.crt<br>&nbsp;&nbsp;&nbsp; right=1.2.3.4<br>&nbsp;&nbsp;&nbsp; rightsubnet=<a href="http://192.168.10.0/24,192.168.11.0/24">192.168.10.0/24,192.168.11.0/24</a><br>
&nbsp;&nbsp;&nbsp; rightid="CN=IOS15"<br>&nbsp;&nbsp;&nbsp; rightca="CN=IOS-CA"<br>&nbsp;&nbsp;&nbsp; ike=aes256-sha1-modp1536<br>&nbsp;&nbsp;&nbsp; esp=aes256-sha1<br>&nbsp;&nbsp;&nbsp; auto=add<br>&nbsp;&nbsp;&nbsp; authby=pubkey<br>&nbsp;&nbsp;&nbsp; keyexchange=ikev2<br><br>While this is not an IOS list, I noticed that IOS installs an<br>
"all IP traffic to <a href="http://192.168.87.35/32">192.168.87.35/32</a>" selector, instead of narrowing its selectors to match StrongSwan's rightsubnets. So just incase there are some inter-op experts here<br><br>&nbsp; protected vrf: (none)<br>&nbsp;&nbsp; local&nbsp; ident (addr/mask/prot/port): (<a href="http://0.0.0.0/0.0.0.0/0/0">0.0.0.0/0.0.0.0/0/0</a>)<br>&nbsp;&nbsp; remote ident (addr/mask/prot/port): (<a href="http://192.168.87.35/255.255.255.255/0/0">192.168.87.35/255.255.255.255/0/0</a>)<br>
&nbsp;&nbsp; current_peer 1.2.3.4 port 4500<br>&nbsp;&nbsp;&nbsp;&nbsp; PERMIT, flags={}<br>&nbsp;&nbsp;&nbsp; #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0<br>&nbsp;&nbsp;&nbsp; #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0<br>&nbsp;&nbsp;&nbsp; #pkts compressed: 0, #pkts decompressed: 0<br>
&nbsp;&nbsp;&nbsp; #pkts not compressed: 0, #pkts compr. failed: 0<br>&nbsp;&nbsp;&nbsp; #pkts not decompressed: 0, #pkts decompress failed: 0<br>&nbsp;&nbsp;&nbsp; #send errors 0, #recv errors 0<br><br>&nbsp;&nbsp;&nbsp;&nbsp; local crypto endpt.: 1.2.3.5, remote crypto endpt.: 1.2.3.4<br>
&nbsp;&nbsp;&nbsp;&nbsp; path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/2<br>&nbsp;&nbsp;&nbsp;&nbsp; current outbound spi: 0xCAF25434(3404878900)<br>&nbsp;&nbsp;&nbsp;&nbsp; PFS (Y/N): N, DH group: none<br><br>(I am by no means an IOS 15.1 expert and it took some time to figure this out).<br>
This split tunnel networks are specified by an acl.<br><br><br>Extended IP access list acl.ROADW<br>&nbsp;&nbsp;&nbsp; 10 permit ip 192.168.10.0 0.255.255.255 any<br>&nbsp;&nbsp;&nbsp; 20 permit ip 192.168.11.0 0.0.0.255 any<br><br><br>crypto ikev2 name-mangler MANGLER<br>
&nbsp;dn organization-unit<br>crypto ikev2 authorization policy ROADW<br>&nbsp;pool pool.ROADW<br>&nbsp;netmask 255.255.255.0<br>&nbsp;subnet-acl 199<br>crypto ikev2 proposal AES256 <br>&nbsp;encryption aes-cbc-256<br>&nbsp;integrity sha1<br>&nbsp;group 5<br>
crypto ikev2 policy ROADW <br>&nbsp;proposal AES256<br>crypto ikev2 profile ROADW<br>&nbsp;match certificate CERTMAP<br>&nbsp;identity local dn <br>&nbsp;authentication local rsa-sig<br>&nbsp;authentication remote rsa-sig<br>&nbsp;pki trustpoint MYCA<br>
&nbsp;aaa authorization group MYLOCAL name-mangler MANGLER<br><br><br><br><br><br></p></div>
Martin Willi | 12 Oct 2011 10:35
Favicon

Re: IKEv2 StrongSwan to Cisco IOS 15.1 interop quirks: some 'attributes failed'

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

Richard Chan | 13 Oct 2011 02:46
Picon

Re: IKEv2 StrongSwan to Cisco IOS 15.1 interop quirks: some 'attributes failed'

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


<div>
<p>Thanks Martin - glad to know that these are abstruse corner cases.<br><br><br>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.<br><br><br>!--- StrongSwan Roadwarrior to IOS 15.1 headend<br>conn roadw<br>&nbsp;&nbsp;&nbsp; left=%defaultroute<br>&nbsp;&nbsp;&nbsp; leftsourceip=%config<br>&nbsp;&nbsp;&nbsp; leftcert=mycert.crt<br>&nbsp;&nbsp;&nbsp; right=1.2.3.4<br>&nbsp;&nbsp;&nbsp; rightsubnet=<a href="http://192.168.10.0/24,192.168.11.0/24">192.168.10.0/24,192.168.11.0/24</a><br>
&nbsp;&nbsp;&nbsp; rightid="CN=IOS15"<br>&nbsp;&nbsp;&nbsp; rightca="CN=IOS-CA"<br>&nbsp;&nbsp;&nbsp; ike=aes256-sha1-modp1536<br>&nbsp;&nbsp;&nbsp; esp=aes256-sha1<br>&nbsp;&nbsp;&nbsp; auto=add<br>&nbsp;&nbsp;&nbsp; authby=pubkey<br>&nbsp;&nbsp;&nbsp; keyexchange=ikev2<br><br>!--- Cisco IOS 15.1 using crypto maps<br>
aaa new-model<br>aaa authorization network MYLOCAL local <br>!<br>ip local pool pool.ROADW 192.168.87.33 192.168.87.63<br>!<br>
access-list 199 permit ip 192.168.10.0 0.0.0.255 any<br>access-list 199 permit ip 192.168.11.0 0.255.255.255 any<br>!<br>crypto pki certificate map CERTMAP 10<br>&nbsp;subject-name co ou = roadw<br>!<br>crypto ikev2 name-mangler MANGLER<br>
&nbsp;dn organization-unit<br>!<br>crypto ikev2 authorization policy ROADW<br>&nbsp;pool pool.ROADW<br>&nbsp;netmask 255.255.255.0<br>&nbsp;subnet-acl 199<br>!<br>crypto ikev2 proposal AES256 <br>&nbsp;encryption aes-cbc-256<br>&nbsp;integrity sha1<br>
&nbsp;group 5<br>!<br>crypto ikev2 policy ROADW <br>&nbsp;proposal AES256<br>!<br>crypto ikev2 profile ROADW<br>&nbsp;match certificate CERTMAP<br>&nbsp;identity local dn <br>&nbsp;authentication local rsa-sig<br>&nbsp;authentication remote rsa-sig<br>
&nbsp;pki trustpoint IOS-CA<br>&nbsp;aaa authorization group MYLOCAL name-mangler MANGLER<br>!<br>crypto dynamic-map ROADW 100<br>&nbsp;set ikev2-profile ROADW<br>&nbsp;reverse-route<br>!<br>crypto map STATIC 20000 ipsec-isakmp dynamic ROADW <br>
!<br>interface GigabitEthernet0/2<br>&nbsp;crypto map STATIC<br>!<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br></p>
<div class="gmail_quote">On Wed, Oct 12, 2011 at 4:35 PM, Martin Willi <span dir="ltr">&lt;<a href="mailto:martin@...">martin <at> strongswan.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">Hi,<br><br>
&gt; Much to my pleasant surprise I was able to set up a RW connection to a<br>
&gt; Cisco IOS 15.1 headend using IKEv2. Kudos so the StrongSwan team!<br><br>
</div>That's good to hear!<br><div class="im">
<br>
&gt; handling INTERNAL_IP4_NETMASK attribute failed<br>
&gt; handling INTERNAL_IP4_SUBNET attribute failed<br>
&gt; handling INTERNAL_IP4_SUBNET attribute failed<br><br>
</div>We don't interpret these attributes. Their purpose is not fully clear<br>
from the standard.<br><br>
The netmask could be used to define a broadcast domain, but we currently<br>
don't send broadcasts over a "routed path".<br><br>
The subnet attribute is superfluous, as the destination networks are<br>
negotiated using traffic selectors. There are some theoretical uses of<br>
this attribute discussed in RFC 5996 3.15.2, but we currently don't<br>
handle it at all.<br><br>
Best regards<br>Martin<br><br>
</blockquote>
</div>
<br>
</div>

Gmane