Public bug reported:
Summary:
On OpenStack Dalmatian, creating a second IPsec site connection on the same VPN
service / router remains in PENDING_CREATE indefinitely. The L3 agent (with
VPNaas extension) is alive, hosting the router as master, but produces no logs
for the second connection and renders no config updates. Repeating the same
steps with only the L3 agent switched to a Zed image makes the second
connection render immediately (a new conn in ipsec.conf and PSK in
ipsec.secrets), and the tunnel comes up. This looks like a Dalmatian regression
in the L3/VPNaas handling of multiple connections under one VPN service.
Environment:
Deployment: OpenStack services running in Kubernetes (OpenStack-Helm style)
Neutron L3 agent with VPNaas extension, driver: strongSwan
What works:
One IPsec site connection (conn #1) on the VPN service is rendered and active.
On Zed L3 agent (same environment), adding conn #2 on the same VPN
service/router renders correctly and comes up.
What fails (Dalmatian):
Adding conn #2 on the same VPN service/router:
API status: PENDING_CREATE (no progress).
No new lines in neutron L3/VPNaas pod logs for the event; no strongSwan
(charon.log) activity.
No changes to files:
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.conf (still only the first conn
stanza)
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.secrets (no second secret)
Steps to Reproduce:
Create router with external gateway; create VPN service on that router.
Create IKE and IPsec policies (strongSwan driver).
Create first IPsec site connection (conn #1) on the VPN service.
→ Result: ACTIVE; files and SAs are rendered.
Create second IPsec site connection (conn #2) on the same VPN service/router
(different peer).
→ Dalmatian result: PENDING_CREATE; no agent logs; no file changes under
/var/lib/neutron/ipsec/<router>/etc.
Repeat (3)-(4) with only the neutron-l3-agent running a Zed image.
→ Zed result: second conn and secret are rendered; tunnel comes up.
Expected Result:
Creating conn #2 adds another conn <uuid> stanza to ipsec.conf, appends the
secret, and brings up an additional IKE/CHILD SA (supported multi-connection
“hub-and-spoke” on one router).
Actual Result (Dalmatian):
conn #2 stuck in PENDING_CREATE, no L3/VPNaas processing, no config rendering,
no logs.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2120316
Title:
Dalmatian: Second IPsec site connection on same VPN service/router
stays PENDING_CREATE; no agent-side rendering (works on Zed L3 agent)
Status in neutron:
New
Bug description:
Summary:
On OpenStack Dalmatian, creating a second IPsec site connection on the same
VPN service / router remains in PENDING_CREATE indefinitely. The L3 agent (with
VPNaas extension) is alive, hosting the router as master, but produces no logs
for the second connection and renders no config updates. Repeating the same
steps with only the L3 agent switched to a Zed image makes the second
connection render immediately (a new conn in ipsec.conf and PSK in
ipsec.secrets), and the tunnel comes up. This looks like a Dalmatian regression
in the L3/VPNaas handling of multiple connections under one VPN service.
Environment:
Deployment: OpenStack services running in Kubernetes (OpenStack-Helm style)
Neutron L3 agent with VPNaas extension, driver: strongSwan
What works:
One IPsec site connection (conn #1) on the VPN service is rendered and active.
On Zed L3 agent (same environment), adding conn #2 on the same VPN
service/router renders correctly and comes up.
What fails (Dalmatian):
Adding conn #2 on the same VPN service/router:
API status: PENDING_CREATE (no progress).
No new lines in neutron L3/VPNaas pod logs for the event; no strongSwan
(charon.log) activity.
No changes to files:
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.conf (still only the first
conn stanza)
/var/lib/neutron/ipsec/<router_uuid>/etc/ipsec.secrets (no second secret)
Steps to Reproduce:
Create router with external gateway; create VPN service on that
router.
Create IKE and IPsec policies (strongSwan driver).
Create first IPsec site connection (conn #1) on the VPN service.
→ Result: ACTIVE; files and SAs are rendered.
Create second IPsec site connection (conn #2) on the same VPN service/router
(different peer).
→ Dalmatian result: PENDING_CREATE; no agent logs; no file changes under
/var/lib/neutron/ipsec/<router>/etc.
Repeat (3)-(4) with only the neutron-l3-agent running a Zed image.
→ Zed result: second conn and secret are rendered; tunnel comes up.
Expected Result:
Creating conn #2 adds another conn <uuid> stanza to ipsec.conf, appends the
secret, and brings up an additional IKE/CHILD SA (supported multi-connection
“hub-and-spoke” on one router).
Actual Result (Dalmatian):
conn #2 stuck in PENDING_CREATE, no L3/VPNaas processing, no config
rendering, no logs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2120316/+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
