yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #90616
[Bug 1921514] Re: VPNaaS strongSwan driver does not reload secrets
Patch was merged a while ago and backported in neutron-vpnaas, and does
not affect neutron itself, updating status
** Changed in: neutron-vpnaas (Ubuntu)
Status: New => Fix Released
** No longer affects: neutron
--
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-vpnaas package in Ubuntu:
Fix Released
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/ubuntu/+source/neutron-vpnaas/+bug/1921514/+subscriptions
References