Talk:StrongSwan

Client side configuration?

I followed the article and set up the server. But how do I connect from the client? Qian (talk) 13:29, 17 December 2018 (UTC)

For example, with ipsec up name of the connection. (Yes, it's missing from the article. Add it?). --Indigo (talk) 19:49, 20 December 2018 (UTC)

Sorry I still have trouble setting up the connection, not to mention contributing to the article! I'd love to help though if I eventually get it working. The current article is unclear on a few points:

1. There's only one configuration example on the server. How do I configure on the client? How do I supply the server address when bring up the connection?
2. How is authentication done on the server? Presumably I keep the server certificate on the server, and client certificate on the client (wrong?). And only the host key is configured in /etc/ipsec.secrets. How does the server know anything about the client? Qian (talk) 07:15, 21 December 2018 (UTC)

Starting the service: replace legacy with new starter?

According to some articles on the Internet, since v5.8.0 the systemd services have been renamed. Shouldn't the service starter become the new [strongswan.service] instead of the (by now) legacy [strongswan-starter.service]?

Version 5.8.0

The systemd service units have been renamed. The modern unit, which was called strongswan-swanctl,

is now called strongswan (the previous name is configured as alias in the unit, for which a symlink is

created when the unit is enabled). The legacy unit is now called strongswan-starter.

In fact, the article might be more outdated. The configuration style /etc/ipsec.conf belongs to the legacy starter (starter) and the new style /etc/swanctl/conf.d/myconf.conf to the modern starter (swanctl).

For example this is the migration from ipsec.conf to swanctl.conf

https://wiki.strongswan.org/projects/strongswan/wiki/Fromipsecconf

ArthurBorsboom (talk) 15:09, 22 April 2020 (UTC)

Rewrite of the article

At the moment, the article discusses the setup for an IPsec server with the long since deprecated and obsolete ipsec.conf system and very problematic DH proposals like modp1024.

I don't believe there's really much interest in the server part, and the contents of the certificates section are mostly redundant with the strongSwan documentation, which discusses that in much more up to date form.

We should probably remove the ancient, and by now dangerous information and focus the article on connecting as a VPN client. The server part can be touched on a little, but realistically, strongSwan's documentation is excellent and has really good step by step instructions including screenshots of what's discussed in the article. This should be rather referred to than unnecessarily duplicating the information from the documentation in a way that it would inevitable become outdated and incorrect again.

I'm willing to rewrite the article with a focus on the client side and add pointers to the server side. The strongswan documentation also has tons of hands-on examples for all kinds of setups, including roadwarrior, IPv4, IPv6, and even the recent multiple key exchanges for using ML-KEM + X25519 as KEX for example. We should aim to point to that so that people can find what they need.

Also, setting up an IPsec server can be tricky due to interoperability concerns. For example, Windows has certain non-obvious requirements to its certificates that go beyond what's described right now. The strongswan documentation has loads of information on this. The same goes for iOS clients. There should be pointers where this information can be found rather than duplicating their documentation. ChrisTX (talk) 21:23, 10 March 2025 (UTC)

This article did not get many updates over the last years, yes. You added a archival template yesterday. Do you propose to start fresh, or update it according to what you write? If you want to start fresh, it might be better to do so in your user-page and meanwhile mark individual sections with out-of-date notices, until a revision to bring to mainspace is reached. If you propose to update it in place (you are certainly right about the very good upstream doc to link to), that could be done section by section (and you could of course start with a roadwarrior client setup, if you want to). In both cases we should first remove the archive template again. --Indigo (talk) 21:11, 11 March 2025 (UTC)

I added the archive template due to a discussion in #archlinux-wiki on how to proceed. I did add the archive template because it's somewhat unclear how to proceed with this: As it were, the article describes a completely obsolete configuration format, and as of such is not any useful. What the article describes - the server side - is also most likely not very interesting for most people. So, a section by section rewrite, I don't think is appropriate.

I'm willing to write a new article, and for that I'd definitely describe the client part. There were at least people on IRC that are running this aspect. However, I would only cover the server side if there's any actual interest in that. If nobody cares to run that on Arch due to it being too niche, then there's no need to document it either. Or rather, I have such a setup myself, but I've never encountered anyone else with it - and the state of the article would also support there not really being interest in this. Most people just run WireGuard I reckon (I do both for certain reasons).

It's a bit of an odd situation to have a wiki article that's completely obsolete content wise, but that would still make sense to cover. As said, I'm up for doing this, just let me know how to best proceed in such a situation. ChrisTX (talk) 21:22, 11 March 2025 (UTC)

Well, a server section at least pointing to the right upstream doc would be valuable, IMHO. Did you see Openswan_L2TP/IPsec VPN client setup? I was just wondering how much your suggestion would overlap with that (or if it's a better base to update in place, and condense this down to merge them later possibly). --Indigo (talk) 22:28, 11 March 2025 (UTC)

Yes, I've seen that. L2TP/IPsec is a quite specific combination that's only really used with Windows Servers as VPN host. The article is specific to that as well, "This guide is primarily targeted for clients connecting to a Windows Server machine, as it uses some settings that are specific to the Microsoft implementation of L2TP/IPsec." Nothing that's in there is really how you'd set up strongSwan normally. The entire article is basically about scripting how to integrate xl2tp with it, and that's a completely separate thing, and the combination isn't standardised, it's really Microsoft specific. For a strongSwan setup you don't need any scripting, nothing of that.

L2TP/IPsec is pretty much obsolete as an idea since IKEv2 has been a thing. IKEv1 is very limited and profited from this combination in certain ways. Nowadays you'd only consider setting something like this up if you needed protocols other than IP tunneled.

I should also point out that the Microsoft implementation is ancient - Windows has long since implemented IKEv2 as a standard solution, and this is compatible with strongSwan, too. Windows with IKEv2 can achieve modern security (ECDH with P-384, AES-GCM, SHA2), but this L2TP/IPsec solution is cryptographically broken. It uses IKEv1 with up to 1024-bit DH (broken due to LogJam attack, this can be decrypted by intelligence services in real time), 3DES (broken due to Sweet32 attack) and SHA1 (broken due to SHAttered). (see Default encryption settings for the Microsoft L2TP/IPSec VPN client - Windows Client | Microsoft Learn) I would strongly recommend never to run such a setup as this is cryptographically a pointless exercise nowadays.

Oh and lastly, the article focuses on openswan, which has not seen any development or commits since 2021. Libreswan - which RHEL uses - has been forked of that, but neither is comparable in feature set and security to strongswan. I'd leave that article be, and maybe add a note as well that it's outdated and indeed this L2TP/IPsec construct being very insecure. But if somebody really finds themselves having to connect to such a network, it might yet be useful information, as xl2tp hasn't really changed. ChrisTX (talk) 00:39, 12 March 2025 (UTC)

Ok, thanks for elaboration. It is always welcome and important to add Template:Out of date or Template:Accuracy to specific sections/parts of sections, the more specific, the better. Back to your proposal: From what you describe what you have in mind to improve this article, I personally think it should be more efficient to edit it in place, but in the end it's more important about how/what you want to contribute - as I wrote earlier. Nothing wrong in drafting a new TOC and then just one (e.g. client) section in your user page, and merge the section over for starters. I can help with merging or shuffling this article a bit later, if needed. It's difficult to say more without a new TOC structure. In any case, the Archive template is wrong to use when we want to keep a topic article. Whether its updated as regular or totally restructured makes no difference. See, archiving redirects every "strongswan" search away to ArchWiki:Archive - which makes no sense with the proposals, but only when we don't want to cover it at all. I follow your technical arguments, but standards play a role on what's considered depcrecated or not as well. That said, there's no need to care about it too much, as our primary use-case for instructions should be "an Arch client connects to an Arch server". So, if OS xyz does not support IKEv2 (or >=3072), is foremost relevant for a troubleshooting item (for this wiki). --Indigo (talk) 22:00, 12 March 2025 (UTC)

> So, if OS xyz does not support IKEv2 (or >=3072), is foremost relevant for a troubleshooting item (for this wiki).

That's true, but this should be warned about in such an article. The article so far only covers IKEv2, and tbh, it's quite difficult expanding beyond that in a useful manner as IKEv1 almost always depends on some proprietary implementation that strongSwan might be compatible to, might not be. This L2TP/IPsec combination is the best example. That's really not something that could be covered by us outside of specific scenarios like that article.

> That said, there's no need to care about it too much, as our primary use-case for instructions should be "an Arch client connects to an Arch server".

I sort of disagree as I've spoken to some people on IRC that use this to connect to work systems. Imho it should be explained how this interoperates, and a proper setup should also be able to easily handle proprietary clients like Windows or iOS. Mine does and it's just a matter of offering the right crypto proposals, really. IKEv1 in this Arch-to-Arch scenario is not much more for strongswan than using `version=1`, but this would not really work in most practical cases where you would want this.

> In any case, the Archive template is wrong to use when we want to keep a topic article.

Right, I might have not properly explained the situation on IRC and that's why this was suggested to me. What we could also do is to make a more generic IPsec article or since strongSwan is the only IPsec implementation Arch ships (although an AUR for libreswan exists AUR (en) - libreswan ), maybe this is worth moving into such an article?

> but in the end it's more important about how/what you want to contribute - as I wrote earlier.

Mhm, well I don't mind covering everything, really. The contents of the article only work for now because --enable-stroke is being used to compile strongSwan, which is not a default argument, has been deprecated for many years now, and removed from the documentation, so this will stop being even a recognised config format soon. My only concern was covering this server side when there would be no interest in such an article. But to be honest, it might be easiest to just cover this, as IPsec doesn't really have a strong contrast as to what a server and what a client is. I think that's the best way forward, to just do it. ChrisTX (talk) 23:15, 12 March 2025 (UTC)

We're on the same page regarding different OS clients (yes, Arch is not an obvious platform choice for the purpose for a number of reasons), and yes, config examples are always prone to go out of date but upstream doc links do that too and are harder to follow. I like your IPsec proposal. See OpenPGP and Stateless OpenPGP, both created with a similar approach and maybe giving you ideas to draft a User:ChrisTX/IPSec TOC. It's very easy to move later and also easier to critique/check dedup with this one prior. --Indigo (talk) 19:16, 13 March 2025 (UTC)

Right, I've gone a bit through what's available as documentation and realised that the documentation as to what IPsec actually is very technical, i.e. Introduction to the IPsec Protocol :: strongSwan Documentation or IPsec - Wikipedia. Knowing how this works is actually very crucial in order to know what one would like to set up, so I've tried writing a first draft explaining what IPsec is and the components.

I'll also add some interoperability notes in there, as configuration of Windows and iOS for example would be independent of strongSwan and work the same with e.g. libreswan. ChrisTX (talk) 03:45, 14 March 2025 (UTC)

That was a quick start! Your Wg-comparison section would better be covered in another (not yet existent) overview article on VPN technologies (tbd later). Other than that give a pointer when you are happy with the TOC. --Indigo (talk) 18:18, 14 March 2025 (UTC)

Comparing other VPNs to either WG or IPsec is a bit challenging, as they do fulfill other roles - but WG and IPsec are both sort of modern and especially fast choices, which is why I felt it was a good idea to specifically compare them. OpenVPN in comparison is more complicated to set up than WG, delivers less flexibility than IPsec and is painfully slow in comparison to both. The speed difference comes from WG and IPsec being in the kernel, whereas OVPN and others aren't. (although ovpn is working on their DCO module so maybe in the future) ChrisTX (talk) 02:43, 15 March 2025 (UTC)

Yes, but a reader of an IPsec article is not primarily interested in a WG comparison. When comparing technologies, some overview including OVPN, WG-complimentary add-ons (we have articles for), or alternatives like Nebula may be useful. Have a look at the table structure in Data-at-rest encryption#Comparison table. A slim structured table for VPN technologies, plus some verbose sections like the one you wrote, or Nebula#Basic concepts and terminology, would make a good overview article. It's tricky to come up with a meaningful table, but there's plenty information to cover - that's why you wrote about it. For example, the "interoperatibility" section you just started could also initially be dealt with table rows (and then crosslink to the article/sections covering it). Just rolling thoughts how to include it best atm, that's why I wrote TBD later. --Indigo (talk) 19:30, 16 March 2025 (UTC)

The actual reason I even started writing about WireGuard there is because this needs some further expansion about how IPsec is different from it, or any other VPN for that matter.

You see, IPsec normally does not use a "route-based VPN", i.e. it doesn't have an interface like WireGuard would have with its wg0, etc. interfaces. It uses policies, which is very different and needs contrasting to other VPNs to be really understandable. Basically, you normally have the system route as it would and then look up whether a target address is in its Security Policy Database (SPD). This determines the actual processing then if there is a matching IPsec SA. This allows for pretty advanced and creative things, as having multiple SAs active at the same time for different locations.

It is possible to create XFRM interfaces ( Route-based VPN :: strongSwan Documentation ) but this isn't the norm and strongSwan won't even do it for you. I personally use a connection between two servers that has two CHILD_SAs, one a policy-based transport mode for host-to-host encryption and a tunnel mode XFRM interface that I use in a different network namespace to allow some containers to be routed exclusively via VPN as a remote access scenario.

I don't really think this fits a table form, as there's many, many aspects to cover. I am generally of the opinion that WireGuard should be the preferred VPN for most home users due to its ease of use, and IPsec is more for advanced users and advanced scenarios like mine. But you're also right that because IPsec is so flexible, it should be compared to OpenVPN, too: OpenVPN allows for scenarios where WireGuard's limited feature set isn't sufficient, but IPsec can probably handle that and can handle it faster due to it being kernel mode.

Either way, sort of understanding the logic of IPsec is key in using it. If you know what you're doing, it's not much more work than WG or OpenVPN would be. My config is still pretty small despite the complex setup I have. But if you don't know what all this policy stuff and the various IPsec modes are, or this IKE_SA/CHILD_SA distinction, it can be really confusing.

Networkmanager-strongswan conceals most of the complexity, as it creates XFRM interfaces. ChrisTX (talk) 13:36, 20 March 2025 (UTC)

Again interesting points. FWIW the table reference only was an example, because you wrote a lot about the wg comparison already in the draft and such comparisons are better in a general topic article than individual sections. Such are usually doubling up and inconsistent across articles. I've not used Networkmanager-strongswan. It may be a good example to determine whether a client subsection is suited for this article, IPsec in general, or covering it suffices as is. --Indigo (talk) 13:28, 23 March 2025 (UTC)