src: Implement changes for dmvpn

[Thermi]

Test suite and test scenarios passe with the changes.

[sarthurdev]

It would be great to see support for dmvpn, we've been having to use these patches in local builds.

[Thermi]

@sarthurdev Exactly these patches?

[sarthurdev]

Not exactly your fork, but the patches by Timo Teras.

[Thermi]

Could you kindly test my fork? Then I can be sure it's working alright. I don't have an existing test setup for DMVPN.

[zendulkaj]

Could you kindly test my fork? Then I can be sure it's working alright. I don't have an existing test setup for DMVPN.

I also welcome these patches. I asked for it in the past at ticket https://wiki.strongswan.org/issues/3643. I going to test it with FRR/NHRP as well. When will it be part of the Strongswan release?

[Thermi]

I don't know that. Probably when they are merged. :P
I adapted the changes to the latest version. They did not apply cleanly to 5.9.2 because of changes in the upstream code.

[tobiasbrunner]

As far as I remember, these patches were rejected years ago. And I've never seen a design document that describes the problem they are trying to solve, what alternatives were considered and why were dismissed, and why this set of patches should be the best approach.

[Thermi]

Which patches exactly? The ones for VICI?

[sarthurdev]

Found the original messages on the topic: https://lists.strongswan.org/pipermail/dev/2014-August/001017.html

Might actually be able to approach this differently now, for example vici does seem to support creating dynamic connections now with load-conn().

[Thermi]

Found the original messages on the topic: https://lists.strongswan.org/pipermail/dev/2014-August/001017.html

That is extremely outdated, because all of these things already happened.
dmvpn is part of quagge and FRR.

Might actually be able to approach this differently now, for example vici does seem to support creating dynamic connections now with load-conn().
That's just for loading configs.
The issue is that the config lookup is linear, so it slows down with an increasing number of conns.
People with stupidly large amounts of sites to interconnect will get slowdowns if new connections are explicitely new configurations.
The patch instead allows overriding the remote and local addresses when initiating the connections. That way a common configuration can be used.

[sarthurdev]

root@swan-dev# swanctl -i -c dmvpn -S 192.0.2.2 -R 192.0.2.1
[DMN] thread 13 received 11
[LIB]  dumping 7 stack frame addresses:
[LIB]   /lib/x86_64-linux-gnu/libpthread.so.0 @ 0x7fdca3c1f000 [0x7fdca3c31730]
[LIB]     -> 
[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7fdca3dcb000 [0x7fdca3e03575]
[LIB]     -> 
[LIB]   /usr/lib/ipsec/libcharon.so.0 @ 0x7fdca3dcb000 [0x7fdca3de0b9a]
[LIB]     -> 
[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fdca3e6a000 [0x7fdca3ea66eb]
[LIB]     -> 
[LIB]   /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fdca3e6a000 [0x7fdca3eb917b]
[LIB]     -> 
[LIB]   /lib/x86_64-linux-gnu/libpthread.so.0 @ 0x7fdca3c1f000 [0x7fdca3c26fa3]
[LIB]     -> 
[LIB]   /lib/x86_64-linux-gnu/libc.so.6 @ 0x7fdca3a59000 (clone+0x3f) [0x7fdca3b524cf]
[LIB]     -> 
initiate request failed: Success

I'm facing the above problem, you should be able to reproduce and test this without a dmvpn setup, by defining a connection in swanctl.conf and initiate it like above command.

[Thermi]

Thank you for your quick response. I'll fix it when I have time allocated for it. :)

[sarthurdev]

@Thermi It seems that Alpine Linux have working 5.9 patches for dmvpn support: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/strongswan

[Thermi]

@Thermi It seems that Alpine Linux have working 5.9 patches for dmvpn support: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/strongswan

That's the patches that I based the changes in this commit on. Because of changes in strongSwan, the patches in that branch don't apply anymore. And strongSwan on Alpine already crashes when the the conns are reloaded using swanctl (if it's used in cojunction with quagga's nhrpd). So that's no good.

[Thermi]

I fixed a bug and rebased for 5.9.3. See #502 please.