VPNaaS strongSwan driver does not reload secrets

[Patryk Jakuszew]

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.

[Patryk Jakuszew (pjakuszew)]

Patch uploaded for review here: https://review.opendev.org/c/openstack/neutron-vpnaas/+/783331

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "neutron_vpnaas_strongswan_rereadsecrets.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Lajos Katona (lajos-katona)]

Hi, Do you need to work in Neutron as well or patch https://review.opendev.org/c/openstack/neutron-vpnaas/+/783331 in neutron-vpnaas is enough to fix this issue?

[Patryk Jakuszew (pjakuszew)]

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.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron-vpnaas/+/795884

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron-vpnaas/+/795885

[Slawek Kaplonski (slaweq)]

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Slawek Kaplonski <email address hidden>" 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.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron-vpnaas 19.0.0.0rc1 release candidate.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron-vpnaas/+/795884
Committed: https://opendev.org/openstack/neutron-vpnaas/commit/21c38f07c2dd4672e431fddd81e31784af15a88b
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 21c38f07c2dd4672e431fddd81e31784af15a88b
Author: Patryk Jakuszew <email address hidden>
Date: Fri Mar 26 07:43:08 2021 +0100

    Add ipsec.secrets reload function to strongSwan driver

    Currently, strongSwan driver only triggers "ipsec reload" command
    when a new IPsec Site Connection configuration is received. If that
    configuration uses a different PSK, it will not be picked up upon
    reload called by restart() function. This change introduces a separate
    reload_secrets() function which will call "ipsec rereadsecrets" before
    "ipsec reload".

    Closes-Bug: #1921514
    Change-Id: Ia5458bbbb38b1d645547baf56ce3bb5ee2a97781
    (cherry picked from commit 2297098875f24289259f12012ab5f077d6051383)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron-vpnaas 18.0.1 release.

[Bernard Cafarelli (bcafarel)]

Patch was merged a while ago and backported in neutron-vpnaas, and does not affect neutron itself, updating status