[strongSwan-dev] Trouble getting unique ip addresses from client pool....

Andrew Foss afoss at actmobile.com
Sat Apr 25 19:42:23 CEST 2015


Miroslav, thank you, you got me going w/ a handle on the logs and 
finding the uniqueness of the ids and that it was due to XAuthName.

Just hoping to connect w/ someone is is really familiar with virtual ip 
addressing and really get a handle on what the "id" is, docs indicate it 
can be an address, a FQDN, a cert subject, and evidently an XAuthName, 
etc. Why it changed between 5.0.2 and 5.3.0...

That is a really important thing to have positive control over for road 
warrior configs, so thought I might get educated, before figuring out 
what direction to take it.

thanks,
andrew

On 4/25/15 10:00 AM, Miroslav Svoboda wrote:
> Andrew,
>
> Sorry for misleading advice with "rightsubnet".
> "rightsubnet" is a traffic selector and has no relation to virtual IP 
> pool.
> Your configuration with "rightsourceip" is correct.
>
> Are you able to find same scenario as yours among testcases here 
> <http://www.strongswan.org/testresults.html> and compare setup and 
> logfiles?
> Without complete logfile, attached as a file, I am not able to help 
> you further.
>
> Miroslav
>
> Miroslav Svoboda | +420 608 224 486 <tel:%2B420%20608%20224%20486>
>
>
> On 25 April 2015 at 16:51, Andrew Foss <afoss at actmobile.com 
> <mailto:afoss at actmobile.com>> wrote:
>
>     Miroslav,
>
>     sorry my last response to you got blocked, but when I use
>     rightsubnet this is what occurs in the logs and vpn doesn't
>     connect, am I missing something?
>
>     Apr 25 14:30:52 accel charon: 15[IKE] peer requested virtual IP %any
>     Apr 25 14:30:52 accel charon: 15[IKE] no virtual IP found for %any
>     requested by 'IDE-B1DA-3355-4C89-BA98-A580BD513292'
>
>     A little further further analysis and I have it working with
>     uiqueids = yes, but raised more questions, that I was not readily
>     able to answer by reviewing the code, but I am still coming up to
>     speed on the structure of the code.
>
>     We were using XAuthName "actmobile", I have changed it to the
>     device id 'IDE-B1DA-3355-4C89-BA98-A580BD513292' and put a
>     wildcard '*' into the ipsec.secrets file and it is working,
>     thankfully we seem to allow a wildcard match with '*" for the
>     secrets, though I suspect someone would file that as a bug.
>
>     It appears the the ip address management may use the XAuthName as
>     the id, not the Cert subject as the docs imply.
>
>     Is that true? Is there any way to control that in the config and
>     assure sessions, SAs, etc. are tracked by the cert subject name?
>
>     Further, it appears that running version 5.0.2 it behaves better
>     and in 5.3.0 the clients don't appear unique and all get the same
>     ip address. I am not convinced it was quite right in 5.0.2, but
>     does seem to behave differently.
>
>     I am suspecting that to ensure positive control over this I should
>     do a radius server and modify the dhcp plugin to really control
>     the ip addresses, but I am hoping to procrastinate doing anything
>     major.
>
>     I think the question is;
>
>     Am I doing something wrong or unusual in the config or can I
>     control in the config to use the cert as the id for the clients?
>     It feels like something that has the potential to bite back down
>     the road, if I do something odd.
>
>     Also, is there anywhere this part of the system is documented,
>     that I coudl refer to as an assist while I review the code and
>     understand what it is doing?
>
>     thanks,
>     andrew
>
>     Here is the config I am using, with a
>
>     * : XAUTH "actmobile" in /etc/ipsec.secrets
>
>     conn ios
>     keyexchange=ikev1
>     #esp=null-sha1!
>     authby=xauthrsasig
>     xauth=server
>     #left=%defaultroute
>         leftsubnet=0.0.0.0/0 <http://0.0.0.0/0>
>     leftupdown=/opt/actmobile/accelerator/actmobile_ipsec_updown
>     leftcert=serverCert.pem
>         rightsourceip=172.20.0.0/16 <http://172.20.0.0/16>
>     auto=add
>     rekey=yes
>     fragmentation=yes
>     lifetime=24h
>     dpddelay=0
>     dpdtimeout=24h
>         compress=yes
>
>     On 4/25/15 2:26 AM, Group Manager wrote:
>>     I replied on yours same question on users list.
>>     I believe that you need to use "rightsubnet" instead of
>>     "rightsourceip" in your conf.
>>     M.
>>
>>     On Saturday, April 25, 2015 at 3:04:46 AM UTC+2, Andrew Foss wrote:
>>
>>         It appears that our ip addresses are being assigned by the
>>         XAuthName
>>         'actmobile', unfortunately that is not unique?
>>
>>         On 4/24/15 5:28 PM, Andrew Foss wrote:
>>         > Here's our situation;
>>         >
>>         > ios ipsec clients, they each have a certificate with a
>>         unique common
>>         > name.
>>         >
>>         > I want to configure strongswan to give them a different ip
>>         address for
>>         > each client/CN, regardless of what public ip address they
>>         may arrive
>>         > from at the moment, it is a road warrior config.
>>         >
>>         > I am thinking I can write a plugin like dhcp to do it for
>>         sure, but
>>         > seems like I may have something in the config that is
>>         wrong. I have to
>>         > set uniqueids=no to get two clients to connect, which makes
>>         me think I
>>         > am using something else for the id, other than the cert
>>         subject name.
>>         >
>>         > This error line seems to indicate the peer is referred to
>>         as 'actmobile'
>>         >
>>         > destroying duplicate IKE_SA for peer 'actmobile', received
>>         > INITIAL_CONTACT
>>         >
>>         > in the updown scripts the PLUTO_PEER_ID does show up
>>         properly as
>>         > [C=US, O=strongSwan, CN=IDE-4B53-E547-4C2A-A2B7-78D2BA436307]
>>         >
>>         > All my clients seem to get 172.20.0.1 as their ip address
>>         and ipsec
>>         > statusall shows just one SA even when I have 3 dvices
>>         connected.
>>         >
>>         > here's the config;
>>         >
>>         > conn ios
>>         > keyexchange=ikev1
>>         > #esp=null-sha1!
>>         > authby=xauthrsasig
>>         > xauth=server
>>         > #left=%defaultroute
>>         > leftsubnet=0.0.0.0/0 <http://0.0.0.0/0>
>>         > #leftsubnet=10.66.0.0/16 <http://10.66.0.0/16>
>>         > #leftfirewall=yes
>>         > #lefthostaccess=yes
>>         > leftupdown=/opt/actmobile/accelerator/actmobile_ipsec_updown
>>         > leftcert=serverCert.pem
>>         > #right=%any
>>         > rightsourceip=172.20.0.0/16 <http://172.20.0.0/16>
>>         > #rightsourceip=10.100.255.0/28 <http://10.100.255.0/28>
>>         > #rightcert=clientCert.pem
>>         > #pfs=no
>>         > auto=add
>>         > rekey=yes
>>         > fragmentation=yes
>>         > lifetime=24h
>>         > dpddelay=0
>>         > dpdtimeout=24h
>>         >     compress=yes
>>         >
>>         > here's the log output of clients connecting;
>>         >
>>         > IKE_SA ios[6] established between 10.199.65.236[C=US,
>>         ST=California,
>>         > L=New York, O=Internet Widgits Pty Ltd, OU=ActMobile,
>>         > CN=ipsec.corp.actmobile.com <http://ipsec.corp.actmobile.com>,
>>         > E=support at actmobile.com
>>         <mailto:support at actmobile.com>]...50.197.174.157[C=US,
>>         O=strongSwan,
>>         > CN=IDE-4B53-E547-4C2A-A2B7-78D2BA436307]
>>         > Apr 25 00:12:43 accel charon: 12[IKE] IKE_SA ios[6] state
>>         change:
>>         > CONNECTING => ESTABLISHED
>>         > Apr 25 00:12:43 accel charon: 12[IKE] scheduling
>>         reauthentication in
>>         > 10094s
>>         > Apr 25 00:12:43 accel charon: 12[IKE] maximum IKE_SA
>>         lifetime 10634s
>>         > Apr 25 00:12:43 accel charon: 12[IKE] activating new tasks
>>         > Apr 25 00:12:43 accel charon: 12[IKE] nothing to initiate
>>         > Apr 25 00:12:43 accel charon: 12[IKE] destroying duplicate
>>         IKE_SA for
>>         > peer 'actmobile', received INITIAL_CONTACT
>>         > Apr 25 00:12:43 accel charon: 12[IKE] IKE_SA ios[5] state
>>         change:
>>         > ESTABLISHED => DESTROYING
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting SAD entry
>>         with SPI
>>         > c1648e6d  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleted SAD entry
>>         with SPI
>>         > c1648e6d (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting SAD entry
>>         with SPI
>>         > 0d133ab7  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleted SAD entry
>>         with SPI
>>         > 0d133ab7 (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting policy
>>         0.0.0.0/0 <http://0.0.0.0/0> ===
>>         > 172.20.0.1/32 <http://172.20.0.1/32> out  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] policy still used by
>>         another
>>         > CHILD_SA, not removed
>>         > Apr 25 00:12:43 accel charon: 12[KNL] updating policy
>>         0.0.0.0/0 <http://0.0.0.0/0> ===
>>         > 172.20.0.1/32 <http://172.20.0.1/32> out  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting policy
>>         172.20.0.1/32 <http://172.20.0.1/32>
>>         > === 0.0.0.0/0 <http://0.0.0.0/0> in  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] policy still used by
>>         another
>>         > CHILD_SA, not removed
>>         > Apr 25 00:12:43 accel charon: 12[KNL] updating policy
>>         172.20.0.1/32 <http://172.20.0.1/32>
>>         > === 0.0.0.0/0 <http://0.0.0.0/0> in  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting policy
>>         172.20.0.1/32 <http://172.20.0.1/32>
>>         > === 0.0.0.0/0 <http://0.0.0.0/0> fwd  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] policy still used by
>>         another
>>         > CHILD_SA, not removed
>>         > Apr 25 00:12:43 accel charon: 12[KNL] updating policy
>>         172.20.0.1/32 <http://172.20.0.1/32>
>>         > === 0.0.0.0/0 <http://0.0.0.0/0> fwd  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] getting a local
>>         address in
>>         > traffic selector 0.0.0.0/0 <http://0.0.0.0/0>
>>         > Apr 25 00:12:43 accel charon: 12[KNL] using host %any
>>         > Apr 25 00:12:43 accel charon: 12[KNL] using 10.199.65.193
>>         as nexthop
>>         > to reach 166.170.42.208
>>         > Apr 25 00:12:43 accel charon: 12[KNL] 10.199.65.236 is on
>>         interface eth0
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting policy
>>         0.0.0.0/0 <http://0.0.0.0/0> ===
>>         > 172.20.0.1/32 <http://172.20.0.1/32> out  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting policy
>>         172.20.0.1/32 <http://172.20.0.1/32>
>>         > === 0.0.0.0/0 <http://0.0.0.0/0> in  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] deleting policy
>>         172.20.0.1/32 <http://172.20.0.1/32>
>>         > === 0.0.0.0/0 <http://0.0.0.0/0> fwd  (mark 0/0x00000000)
>>         > Apr 25 00:12:43 accel charon: 12[KNL] getting iface index
>>         for eth0
>>         > Apr 25 00:12:43 accel charon: 12[CFG] lease 172.20.0.1 by
>>         'actmobile'
>>         > went offline
>>         > _______________________________________________
>>         > Dev mailing list
>>         > Dev at lists.strongswan.org <mailto:Dev at lists.strongswan.org>
>>         > https://lists.strongswan.org/mailman/listinfo/dev
>>
>>         _______________________________________________
>>         Dev mailing list
>>         Dev at lists.strongswan.org <mailto:Dev at lists.strongswan.org>
>>         https://lists.strongswan.org/mailman/listinfo/dev
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150425/abe88965/attachment-0001.html>


More information about the Dev mailing list