VPNaas-IPsec site connection is still active evenif IPsec service on Host OS is stopped and VM across the site are still able to ping each other
Bug #1440650 reported by
Neeti Munshi
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Expired
|
Undecided
|
Unassigned |
Bug Description
In the devstack setup with VPNaas enabled:
1. Establish a IPsec site connection between 2 devstack clouds.
2. Verify that the connection is active from both ends.
3. Now run "service ipsec stop" on either of the cloud.
4. Now check the status of IPsec site connection, it will still show active on both ends, and the VMs launched on both clouds are still accessible using the private IP. -issue 1
5. If we kill Pluto process also, then the IPsec site connection goes down.
6. If before creating the IPsec site connection IPsec service was stopped, after that if we create IPsec site connection it doesnot become active even after starting the IPsec service.-issue 2
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Changed in neutron: | |
assignee: | nobody → Aniruddha Singh Gautam (aniruddha-gautam) |
To post a comment you must log in.
I guess I'm wondering why you're using host commands to manipulate the IPSec service/process. Can you elaborate on the intent of the test?
The IPSec process is run in a namespace. I don't know the impact of using the host "service ipsec stop" in that case (step 3 and 4). Step 5 makes sense and is expected. Step 6, I'm not sure of the interaction of stopping and starting the service, independent of the connection creation.
I don't think we can ensure that VPN operates correctly, if there is manipulation outside of openstack. Again, I'd like to understand the objective of this test, and how it could naturally occur with openstack setup.