vpnaas problem --- strongswan on rocky 9

[Ian Kumlien]

It seems like this is written exclusively for some dist..

On rocky, it's named strongswan just like in the man page, and it uses /etc/strongswan

So setting:
[strongswan]
default_config_area = /etc/strongswan/strongswan.d

should be enough according to the configuration, but there are some issues:
1. Configuration is copied with cp -a and thus still owned by root
2. It seems it doesn't even attempt to put the configuration in the right path -- i patched this manually nd got error that a normal run doesn't get (ie permission denied for the temporary file)

Why not ask the binary?

strongswan --confdir
/etc/strongswan

Or set the paths using the environment variables documented?

[Ian Kumlien (pomac)]

Replacing /usr/sbin/ipsec with:
#!/bin/bash
export STRONGSWAN_CONF="/etc/strongswan.conf"

ARGS=()

while [[ $# -gt 0 ]]; do
        case $1 in
                start|restart)
                        ARGS+=("$1")
                        ARGS+=("--conf /etc/ipsec.conf")
                        shift
                        ;;
                *)
                        ARGS+=($1)
                        shift
                        ;;
        esac
done
/usr/sbin/strongswan ${ARGS[@]}
---

Seems to make things work...

[Dmitriy Rabotyagov (noonedeadpunk)]

Hey there,

I think, you actually should be able to provide a custom template of config for both ipsec.conf and strongswan.conf through appropriate config options:
https://docs.openstack.org/neutron-vpnaas/latest/configuration/l3_agent.html#strongswan

However, if memory does not fail me, EL are supposed to be using libreswan, which is quite outdated at the moment.

There is a patch though [1], which potentially fixes state of libreswan

[1] https://review.opendev.org/c/openstack/neutron-vpnaas/+/895824

[Ian Kumlien (pomac)]

So, I started trying strongswan since libreswan doesn't work at all, even with the patch.

Changing the settings on strongswan doesn't work - the only way to get this to work is to try to simulate ubuntus environment.

This is all trough empirical testing btw.

[Ian Kumlien (pomac)]

Also see https://bugs.launchpad.net/neutron/+bug/1938571 filled with frustration for years..

Had to do the following modifications to make this work:
diff --git a/neutron_vpnaas/services/vpn/device_drivers/strongswan_ipsec.py b/neutron_vpnaas/services/vpn/device_drivers/strongswan_ipsec.py
index 708952a1f..1d073d135 100644
--- a/neutron_vpnaas/services/vpn/device_drivers/strongswan_ipsec.py
+++ b/neutron_vpnaas/services/vpn/device_drivers/strongswan_ipsec.py
@@ -180,7 +180,7 @@ class StrongSwanProcess(ipsec.BaseSwanProcess):
         ipsec.conf. Currently established connections are not affected by
         configuration changes.
         """
- self._execute([self.binary, 'reload'])
+ self._execute([self.binary, 'reload'], extra_ok_codes=[7])

     def start(self):
         """Start the process for only auto=route mode now.
diff --git a/neutron_vpnaas/services/vpn/device_drivers/template/strongswan/strongswan.conf.template b/neutron_vpnaas/services/vpn/device_drivers/template/strongswan/strongswan.conf.template
index 9cd5fda57..2470cbb5e 100644
--- a/neutron_vpnaas/services/vpn/device_drivers/template/strongswan/strongswan.conf.template
+++ b/neutron_vpnaas/services/vpn/device_drivers/template/strongswan/strongswan.conf.template
@@ -2,6 +2,9 @@ charon {
         load_modular = yes
         plugins {
                 include strongswan.d/charon/*.conf
+ stroke {
+ socket = unix:///var/run/charon.ctl
+ }
         }
 }
---

The extra_ok_codes=[7] is a bit dodgy, can't see anything about non-zero return codes :/

[Ian Kumlien (pomac)]

Additional things done to make this work:
cp -a /etc/strongswan/strongswan.d /etc/

I also edited /etc/strongswan.d/chaorn/stroke.conf:
secrets_file = /etc/ipsec.secrets
socket = unix:///var/run/charon.ctl
---

The sockets bit was grasping for straws since charon.ctl wasn't created.... Howevver, I now actually have two VPNs connected and working

[Lajos Katona (lajos-katona)]

Hi, is it possible to somehow add these finding to the documentation, perhaps with some tooling if possible?

[Brian Haley (brian-haley)]

Will need to get someone from neutron-vpnaas team to take ownership of this.

[Christian Rohmann (christian-rohmann)]

I worked on improving the reconciling of VPNaaS a while back in https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745. Looking at that one again now, I should rebase it and respond to the review remarks ...

In any case, I also tried to improve the invocation of `stroke`, as this currently does not really check for success. But as I stated in my changeset, a switch to the VCI (https://docs.strongswan.org/docs/5.9/plugins/vici.html) is likely the best approach as it's a proper control interface, intended for such use cases and not some wrapped call to some binary ;-)

[Lajos Katona (lajos-katona)]

Hi @Christian Rohmann, thanks for checking and rethinking https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745 .
Do you think that 875745 & https://review.opendev.org/c/openstack/neutron-vpnaas/+/895824 together can make vpnaas to a more future (and user) proof situation with some extra documentation to avoid such situations?

[Ian Kumlien (pomac)]

So all of this started here:
https://bugs.launchpad.net/neutron/+bug/1938571

[Christian Rohmann (christian-rohmann)]

@Lajos @Ian ...

 Sorry for the delay. I reworked https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745 again and pushed a fresh patchset just now.

If you can please take a look at let's discuss!