yahoo-eng-team team mailing list archive

[Patryk Jakuszew <1921514@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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 configuration 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 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.

** Affects: neutron
     Importance: Undecided
         Status: New

** Patch added: "neutron_vpnaas_strongswan_rereadsecrets.patch"
   https://bugs.launchpad.net/bugs/1921514/+attachment/5481174/+files/neutron_vpnaas_strongswan_rereadsecrets.patch

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1921514

Title:
  VPNaaS strongSwan driver does not reload secrets

Status in neutron:
  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 configuration 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 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