Thanks rosenboom, but it seems one needs more than just that. As just with the following it won't trigger: 1. new Xenial KVM Guest 2. $ apt install strongswan neutron-vpn-netns-wrapper 3. $ ip netns add testns 4. $ ip netns exec testns neutron-vpn-netns-wrapper --mount_paths "/var/run:/tmp/test" --cmd "ipsec,status" 5. sudo ipsec status Neither 4 nor 5 trigger the issue.
So it really seems to come down to "with an established ipsec connection, issue the following". So we might need to mix that into the repro. I tried with all four (ike1psk, ike1cert, ike2psk, ike2cert) modes of [1] but in none of those cases the issue shows up. I guess some more special setup - that in your cases are set by either neutron-vpn-netns-wrapper (last case) or network-manager-l2tp (original case) setup to trigger it. When we are doing proposed verification it will be important that you can do the verifications as well. I'd be even more convinced if we could find a step-by-step solution from a fresh KVM guest or such. Maybe the original reporter would have a few steps cmdline based to set up network-manager-l2tp in a way to trigger. [1]: https://code.launchpad.net/~paelzer/+git/strongswan-test-wrapper -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1587886 Title: strongswan ipsec status issue with apparmor To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1587886/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
