16:04:11 <pc_m> #startmeeting vpnaas
16:04:11 <openstack> Meeting started Tue Sep  8 16:04:11 2015 UTC and is due to finish in 60 minutes.  The chair is pc_m. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:14 <openstack> The meeting name has been set to 'vpnaas'
16:04:29 <pc_m> #topic announcements
16:05:09 <pc_m> The endpoint-groups code is out for review, along with the neutron-client changes.
16:05:49 <beagles> o/
16:06:06 <pc_m> I *may* have a version of the scripts working that will allow for VPN functional tests on Neutron jobs.
16:06:17 <pc_m> Testing, but it works pretty good so far.
16:06:44 <pc_m> There is a fix out for review for coverage testing.
16:07:11 <pc_m> Finally, the neutron client experimental job is out for review. Needs core review and then infra review.
16:07:14 <pc_m> beagles: hi
16:07:25 <pc_m> Anyone have any other big announcements?
16:08:21 <beagles> I have an potential issue I would like to bring up - is this the appropriate time or is there a better spot in the agenda?
16:08:35 <pc_m> beagles: wait for open discussion.
16:08:40 <beagles> right
16:08:57 <pc_m> #topic Endpoint Groups
16:09:34 <pc_m> Please help review the code #link https://review.openstack.org/#/c/212692/ and neutron-client https://review.openstack.org/#/c/219455/
16:10:13 <pc_m> The developer reference doc on this (and the multiple local subnet feature) has been upstreamed.
16:10:38 <pc_m> #topic Multiple Local Subnets
16:10:46 <pc_m> The dev ref is #link https://review.openstack.org/#/c/191944
16:11:14 <pc_m> Will start on this, as soon as the endpoints code is upstreamed.
16:11:41 <pc_m> #topic VPN Functional Tests
16:11:56 <pc_m> So it looks like #link https://review.openstack.org/#/c/203201/14 may do the trick.
16:12:20 <pc_m> I tested a neutron fix with a bug and without a bug and the VPN tests failed/passed, as expected.
16:12:44 <pc_m> Will likely wait for dougwig to get back and work on core reviews.
16:13:10 <pc_m> #topic Reviews
16:13:21 <pc_m> Please help out... https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas,n,z
16:13:54 <pc_m> For bugs, we have https://goo.gl/XNtnLX for the latest.
16:14:14 <pc_m> I think most have people assigned (Yay!)
16:15:02 <pc_m> Any particular bugs we need to discuss here?
16:15:33 <madhu_ak> yes. https://bugs.launchpad.net/neutron/+bug/1491679
16:15:35 <openstack> Launchpad bug 1491679 in neutron "ipsec-site-connection is not back to ACTIVE state after updating admin_state_up from True -> False -> True" [Undecided,New]
16:16:33 <pc_m> madhu_ak: go ahead...
16:16:57 <madhu_ak> based on my research, I concluded that, when using openswan vs strongswan, I found it is working well when using later than former
16:17:36 <madhu_ak> With strongswan, its is minutes longer to see the respective status..
16:17:48 <madhu_ak> s/its is/its taking
16:18:43 <pc_m> so you are changing the admin status of the connection, right?
16:18:52 <madhu_ak> Righ
16:18:55 <madhu_ak> Right
16:19:13 <pc_m> With both OpenSwan and Strongswan are they stopping and then resuming status?
16:19:23 <pc_m> On their own, or with traffic?
16:19:33 <madhu_ak> with openswan, it dont..with strongswan it does
16:20:10 <pc_m> Let's take one at a time...
16:20:24 <pc_m> With OpenSwan, does it work if you admin stop/start both sides?
16:20:42 <madhu_ak> nope..
16:21:10 <pc_m> what about when DPD is changed?
16:21:15 <pc_m> (mode)
16:21:39 <madhu_ak> with openswan, I changed the dp action to restart, the traffic still flows when changing admin state as stop
16:21:40 <pc_m> I know there are several different settings.
16:22:07 <pc_m> madhu_ak: that's bad.
16:22:27 <pc_m> Did you find any bug reports on OpenSwan
16:22:29 <pc_m> ?
16:22:48 <madhu_ak> have seen people discussiong about dpd status with openswan..
16:23:04 <pc_m> There are other modes too, not sure if any help there.
16:23:18 <madhu_ak> I *understood* that, dpd actions does not work proper with openswan
16:23:20 <pc_m> For StrongSwan, does it work, but takes longer than expected?
16:23:45 <madhu_ak> yep, for strongswan, its works, but taking longer time than expected..
16:24:09 <madhu_ak> even with dpd action, interval and timeout, stringswan takes time to update
16:24:34 <pc_m> more than a minute beyond setting?
16:24:40 <madhu_ak> yep
16:24:48 <madhu_ak> roughly, 15-20 minutes
16:24:52 <pc_m> wow
16:25:06 <pc_m> Did you happen to try IKEv2?
16:25:17 <pc_m> I hear that has the DPD built in.
16:25:46 <madhu_ak> I think yes, its uses psk
16:26:08 <pc_m> ?
16:26:33 <madhu_ak> its uses psk, and ikev2
16:26:45 <madhu_ak> I can still confirm and comment on the bug
16:27:14 <pc_m> There is differences between using IKE policy with v1 vs v2
16:27:20 <pc_m> s/is/are
16:27:47 <pc_m> My understanding is that IKE policy v2 has DPD built in
16:28:31 <pc_m> So, do you think the issues are problems with the underlying *Swan packages or with the reporting of status by the OpenStack drivers?
16:28:57 <pc_m> IOW, does the traffic actually start/stop on time, and the status is just wrong.
16:29:27 <madhu_ak> *Swan packages...the traffic actually doesn't stop with start/stop on time
16:29:40 <pc_m> If it's a *Swan issue, there's not much we can do, unless they have some workarounds that we can deploy.
16:30:11 <madhu_ak> maybe if anyone can reproduce and comment on that bug would be helpful
16:30:38 <pc_m> anyone able to confirm?
16:30:53 <madhu_ak> so we can get to know the clear info - meaning, having different views should be good
16:31:50 <pc_m> Can anyone try this?
16:33:05 <madhu_ak> I can retry again and post comment accordingy
16:33:12 <pc_m> Well, hopefully someone can get some time to try it. I may be able later this week or next week. Pretty tied up right now.
16:33:36 <beagles> any value to trying with libreswan?
16:33:38 <pc_m> #action People to try to confirm 1491679 bug
16:33:55 <Aish> I shall try this today or tomo and let u know.. madhu_ak
16:33:56 <pc_m> Any other bugs to discuss, before open discussion?
16:33:59 <madhu_ak> havent tried with that driver beagles
16:34:03 <beagles> (sorry, my network has been hiccuping)
16:34:32 <pc_m> Aish: Thanks!
16:34:38 <madhu_ak> sure
16:34:53 <beagles> I ran into an issue with libreswan where its use of the capabilities library prevents it from establishing connections because ipsec.secrets isn't owned by root
16:34:55 <Aish> np pc_m
16:34:55 <beagles> fun!
16:34:56 <pc_m> beagles: Can't hurt, I guess it is similar to openswan.
16:35:00 <beagles> yeah
16:35:33 <pc_m> #topic Open Discussion
16:35:39 <pc_m> beagles: You had an item...
16:35:52 <beagles> yeah, kind of jumped the gun... see above
16:36:07 <beagles> that led me to do some research and discovered that most of the references (manpages, etc) indicate the file should be owned by root/super-suer
16:37:00 <beagles> does this indicate a general problem or should a fix be localized to libreswan driver?
16:38:06 <pc_m> beagles: I haven't seen that with open/strongswan
16:39:07 <beagles> pc_m yeah I figured that was likely the case. What are the implications of having not restricting it to root/super-user?
16:39:59 <beagles> I guess outside of devstack, it would be whatever UID the deployment runs the agent as - which is restricted itself in a way
16:40:08 <ajmiller> beagles There could possibly be some interaction here with the fix I just made for https://bugs.launchpad.net/neutron/+bug/1488320
16:40:09 <openstack> Launchpad bug 1488320 in neutron "neutron-vpnaas uses bad file permissions on PSK file" [Undecided,In progress] - Assigned to Al Miller (al-miller)
16:40:19 <pc_m> beagles: not sure. Usually the template is copied to the UUID of the process for the driver.
16:40:50 <pc_m> ajmiller: Is this the same file?
16:40:53 <ajmiller> yes
16:40:57 <ajmiller> I beleive so
16:41:33 <pc_m> beagles: Do you have ajmiller's fix? ajmiller did you see connection issues?
16:41:54 <pc_m> #link https://review.openstack.org/216810
16:42:22 <pc_m> ajmiller: More correctly, did you try end-to-end connection?
16:43:29 <beagles> pc_m yes: I think I have that fix.. it is quite likely he is seeing something different. Basically I get a permission error when reading ipsec.secrets when starting to listen for connections
16:43:39 <beagles> pc_m : same file though
16:43:40 <ajmiller> pc_m, Yes, I did do a full set of manual tests.  I will go back and double-check though.
16:44:33 <beagles> it is most likely libreswan specific because of that capabilities library thing - same root cause as the recent .ctl/.pid file cleanup patch
16:44:44 <pc_m> ajmiller: May be worth two setup two routers and ensure traffic passes (though scenario test should do that).
16:44:52 <beagles> (really bizarre actually... but what can you do)
16:45:43 <pc_m> Corrected #link https://review.openstack.org/#/c/216812/
16:46:10 <beagles> ajmiller, I think in my case things worked *before* your patch because the perms would've been more permissive
16:46:11 <pc_m> beagles: wondering if it works w/o ajmiller's fix?
16:46:26 <beagles> pc_m: yeah.. was just thinking that.
16:46:30 <pc_m> beagles: yeah, that is what I'm wondering.
16:47:02 <pc_m> ajmiller: Is your fix for sswan?
16:47:10 <pc_m> only?
16:47:24 <beagles> pc_m, I suspect ajmiller's patch is more correct from a security standpoint however
16:47:30 <pc_m> looking at code, it appears to be both.
16:47:36 <ajmiller> beagles pc_m It started out for openswan only, then based on review feedback made it more broad, for the other drivers that used that code.
16:47:57 <ajmiller> i.e. drivers that called replace_file()
16:47:59 <pc_m> beagles: So you may want to confirm if the permissions change anything.
16:48:10 <beagles> pc_m: will do
16:48:26 <pc_m> beagles: Does sound like a libreswan only fix though.
16:48:42 <beagles> pc_m: I'm cool with that
16:49:42 <pc_m> OK. Anything else to discuss?
16:50:55 <pc_m> Thanks for joining in everyone.
16:51:07 <pc_m> #endmeeting