Github user swill commented on the issue:
https://github.com/apache/cloudstack/pull/872
Hey @jayapalu, thanks for the follow up. Here are a couple things to note.
- In order to get Remote Access VPN to work you need to update the L2TP
conf file to include `type=transport`.
- In order to get 3des working for S2S VPN, you will need to install the
`libstrongswan-extra-plugins` package as well.
- Running `ipsec restart` seems to get rid of the discrepancy between the
running config and the config files, but I think one of the main issues is a
missing `ipsec rereadsecrets` when the S2S config changes.
Here is some basic stuff you can do to reproduce the problems. You can use
two VPCs as a test environment and create a S2S VPN connection between them to
do tests.
- Remove all the S2S VPN connections and gateways.
- Manually remove the `/etc/ipsec.d/ipsec.vpn-vv.xx.yy.zz.conf` and
`/etc/ipsec.d/ipsec.vpn-vv.xx.yy.zz.secrets` files from the VRs.
- Create a S2S VPN configuration with `dpd=true` and `pfs=modp1024` and set
a PSK of something like `1234567890`. This configuration should work. If it
doesn't, do an `ipsec restart` and it will probably start working. Even if it
does not work, we can continue the tests sequence.
- Remove the entire configuration through ACS (connections and gateways).
-- Note the files `/etc/ipsec.d/ipsec.vpn-vv.xx.yy.zz.conf` and
`/etc/ipsec.d/ipsec.vpn-vv.xx.yy.zz.secrets` are not removed from the VRs.
-- Note the `conf` file includes dpd and psk details previously configured.
- Create a new S2S VPN configuration with `dpd=false` and without PFS. For
now, don't change the PSK from what it was before.
-- Note that the `conf` file on the VRs still includes the `dpd`
configuration. Also note that `pfs=no` now, but the `esp` config still
includes the `modp1024` to specify `pfs=yes`.
-- If the connection was working before, this configuration, which is very
much broken, will still work because what ipsec has in memory does not reflect
what is in the config files.
- Remove the entire configuration through ACS again.
- Recreate it again, but this time change the PSK to something different
like `0987654321`.
-- Note that now the connection breaks and you get an authentication error.
-- At this point to get it working again you will have to run `ipsec
restart` because the old PSK is still in the ipsec memory.
-- You may have to manually clean up your config files at this point
because they may be polluted by bad configuration since they are never deleted
and configuration options are never deleted in a config, only added or edited.
That should get you going. If you have questions, let me know. I will
isolate the problem more on monday.
I think the majority of these problems will go away if the config files get
deleted when the configuration is deleted through ACS. I think the logic will
then flow the way it is expected. Right now, things like `ipsec reload` are
never called because they are showing as not changed, even though the config
has actually changed. I think that is the first step and then we go from
there. I also think we will need to run `ipsec rereadsecrets` after updating
the s2s config in order to check if the PSK has changed and load it into the
running config if it did change.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
