[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