[Bug 1921514] Re: VPNaaS strongSwan driver does not reload secrets

[Patryk Jakuszew]

Hi! I think that patching neutron-vpnaas should be enough - I can see it
in charon logs that "ipsec rereadsecrets" command is indeed called when
a new connection is configured. The unit tests that you mentioned in
review discussion probably will be limited to neutron-vpnaas repo too.

-- 
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:
  In Progress

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