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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
