[Bug 1921514] Change abandoned on neutron-vpnaas (stable/victoria)

OpenStack Infra 1921514 at bugs.launchpad.net
Sun Aug 15 08:29:21 UTC 2021


Change abandoned by "Slawek Kaplonski <skaplons at redhat.com>" on branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron-vpnaas/+/795885
Reason: This review is > 4 weeks without comment, and failed Zuul jobs the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron-vpnaas in Ubuntu.
https://bugs.launchpad.net/bugs/1921514

Title:
  VPNaaS strongSwan driver does not reload secrets

Status in neutron:
  Confirmed
Status in neutron-vpnaas package in Ubuntu:
  New

Bug description:
  When a new IPsec Site Connection is added to VPN Service which already
  hosts a connection, it is not being properly propagated to L3 Agent
  with vpnaas plugin using strongSwan driver.

  See following fragment: https://opendev.org/openstack/neutron-
  vpnaas/src/branch/master/neutron_vpnaas/services/vpn/device_drivers/strongswan_ipsec.py#L159-L171

  `ipsec reload` command only reloads the ipsec.conf configuration. If a
  new connection is added with different PSK credentials, then we also
  need to run `ipsec rereadsecrets`, otherwise charon will try to use
  "%any - <remote peer>" credentials.

  Preparations:
  1. Enable charon filelog in StrongSwan template. Add the following lines to /etc/neutron/l3_agent.ini:
  [strongswan]
  strongswan_config_template = /etc/neutron/strongswan.conf.template
  2. Create /etc/neutron/strongswan.conf.template: http://paste.openstack.org/show/803952/
  3. AppArmor systems only - temporarily place charon in complain mode in order to allow it to write logs to /var/log/neutron directory: aa-complain /usr/lib/ipsec/charon
  4. Restart neutron-l3-agent so it will regenerate all VPN configurations with logging enabled.

  Steps to reproduce the problem:
  1. Create a new router.
  2. Create a VPN service associated with new router.
  3. Create a IPsec Site Connection and associate it with VPN service.
  4. Create another IPsec Site Connection, with different PSK in the same VPN service.

  Expected behavior:
  New IPsec Site Connection should be in Active state.

  Actual behavior:
  New IPsec Site Connection does not start. Authentication errors can be seen on both sides. See the following log snippet which should be present in /var/log/neutron/neutron-vpnaas-charon-<router_id>.log: http://paste.openstack.org/show/803954/

  Discovered on OpenStack Rocky-based deployment, but this issue still
  seems to be present in master branch of neutron-vpnaas (see the
  opendev.org link above)

  I am attaching a patch which should fix the issue, I have deployed it
  in a test environment and initial tests show that it works correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1921514/+subscriptions




More information about the Ubuntu-openstack-bugs mailing list