[strongSwan] How to define multiple proposals in IKEv1

[Steve Leung]

Hi Tobias,

Finally looks like it's configuration problem on remote peer. I can receive
multiple proposals on remote peer now.

Thank you so much for your help. Below is my testing ipsec.conf for
reference, and remote peer is able to see 3des-sha1 proposal for both phase
1 and phase 2.


~ # cat /etc/ipsec.conf
config setup
        uniqueids=yes
        charondebug=""

conn IPSEC1
        type=tunnel
        authby=secret
        aggressive=no
        left=10.90.45.1
        ike=aes256-sha1-modp1024,3des-sha1-modp1024!
        esp=aes128-sha2_256-modp1024,3des-sha1-modp1024!
        forceencaps=no
        keyexchange=ikev1
        lifetime=28800s
        ikelifetime=3600s
        dpddelay=10
        dpdtimeout=30
        dpdaction=restart
        rekey=yes
        keyingtries=%forever
        right=10.90.46.1

conn IPSEC1-1x1
        leftsubnet=192.168.1.0/24
        rightsubnet=192.168.2.0/24
        also=IPSEC1
        auto=start

conn IPSEC1-1x2
        leftsubnet=192.168.1.0/24
        rightsubnet=172.16.2.0/24
        also=IPSEC1
        auto=start

conn IPSEC1-2x1
        leftsubnet=172.16.1.0/24
        rightsubnet=192.168.2.0/24
        also=IPSEC1
        auto=start

conn IPSEC1-2x2
        leftsubnet=172.16.1.0/24
        rightsubnet=172.16.2.0/24
        also=IPSEC1
        auto=start



Best regards,
Steve


2016-08-30 20:08 GMT+08:00 Tobias Brunner <tobias at strongswan.org>:

> Hi Steve,
>
> > About Q1, for example, remote peer only accept *3des-sha1-modp1024*, and
> > local Strongswan using the following "ike" config.
> >
> > a) ike=aes256-sha1-modp1024,*3des-sha1-modp1024*,aes128-
> sha2_256-modp1024
> > b) ike=aes256-sha1-modp1024,*3des-sha1-modp1024*,aes128-
> sha2_256-modp1024!
> >
> > Config (a) works well and phase 1 passed using 3des-sha1-modp1024
> > without problem.
> >
> > Config (b) failed and Strongswan only propose aes256-sha1-modp1024 to
> > remote peer, and the 3des proposal is not sent at all. The only
> > difference compared to (a) is I have added "!" to restrict Strongswan to
> > accept the defined proposal.
> >
> > So question 1 is, why config (b) fail?
>
> I can't reproduce this.  When I use a) I get the following on the
> responder:
>
> > received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
>
> When I use b) I get this:
>
> > received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
> IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
>
> So the only difference is that the fourth proposal (derived from the
> default proposal) is not sent.  Check what your responder is doing and
> why it fails.
>
> > For Q2, using the same example, remote peer only accept
> > *3des-sha1-modp1024* for phase 2, and local Strongswan using:
> >
> > a) esp=aes256-sha1-modp1024,*3des-sha1-modp1024*
> > b) esp=aes256-sha1-modp1024,*3des-sha1-modp1024*!
> >
> > No matter (a) or (b), with or without "!", Strongswan never propose the
> > second 3des proposal to remote peer, the behavior is different compared
> > to "ike". Is this a bug?
>
> Again, I can't reproduce it.  But since these proposals include a DH
> group adding ! doesn't make a difference (because the default ESP
> proposal does not contain any DH groups it will be ignored).
>
> Are you really using 5.5.0?  Did you modify the source code in any way?
>
> Regards,
> Tobias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160901/99f11c0c/attachment.html>