Package Details: openswan 3.0.0-1

Git Clone URL: (read-only, click to copy)
Package Base: openswan
Description: Open Source implementation of IPsec for Linux
Upstream URL:
Licenses: GPL, custom
Conflicts: ipsec-tools, strongswan
Submitter: Allan
Maintainer: severach
Last Packager: severach
Votes: 142
Popularity: 0.000018
First Submitted: 2009-11-07 14:39 (UTC)
Last Updated: 2022-01-30 19:36 (UTC)

Latest Comments

lano1106 commented on 2021-02-26 22:21 (UTC)

Here is some heads up about v3.0.0. I had issue with it. I use openswan for a VPN connection as described here:

IPSec will only be established with the VPN gateway if I do use IPSec transport mode.

With v3.0.0, I have this error msg when doing: ipsec auto --up L2TP-PSK

003 "L2TP-PSK" #3: NAT-Traversal: Transport Mode not allowed due to security concerns -- using Tunnel mode. Rebuild Openswan with USE_NAT_TRAVERSAL_TRANSPORT_MODE=true in to support transport mode.

I did try to recompile by following the warning message but it doesn't change anything.

I have tried to grep the source code to see where this define was used and it doesn't seem to be used anywhere except in the error text msg.

So IOW, as of right now, 3.0.0 appears broken for my application of it.

xexaxo commented on 2020-12-01 05:04 (UTC) (edited on 2020-12-21 03:27 (UTC) by xexaxo)

Please consider pulling my fix on the next update. Upstream has merged it, although it not in any release yet.

Edit: fix has been included in

xexaxo commented on 2020-09-28 16:43 (UTC)

You may want to include Otherwise "self-proposal" errors may occur as seen in

buzz commented on 2020-07-09 17:59 (UTC)

Could you support aarch64?

I successfully compiled for this architecture by adding aarch64 to arch in PKGINFO.

Thank you

greenlean commented on 2020-05-21 09:40 (UTC) (edited on 2020-05-21 09:41 (UTC) by greenlean)

The package does not build on gcc 10-1. A workaround is to downgrade to gcc 9.2 and then build it.

$ yay -S downgrade # downgrade gcc gcc-libs

There are also issues with xmlto, is better to remove it: # pacman -R xmlto

lineage commented on 2020-01-30 19:24 (UTC) (edited on 2020-01-30 19:24 (UTC) by lineage)

One of the makefiles tries to remove a real system file during packaging. Non-root builds where a version is already installed barf. root builds would silently remove the file. This will fix it

--- programs/Makefile.program.orig      2019-06-14 20:35:45.000000000 +0100
+++ programs/Makefile.program   2020-01-30 18:54:31.226501106 +0000
@@ -112,7 +112,7 @@

 # note: remove any old vendor file installed previously
-       @rm -f $(FINALLIBEXECDIR)/vendor
+       @rm -f $(LIBEXECDIR)/vendor
        @if [ -n "$(PROGRAM)" ]; then $(INSTALL) $(INSTBINFLAGS) $(PROGRAM) $(PROGRAMDIR); fi
        @$(foreach f, $(addsuffix .8, $(PROGRAM)), \

amdg commented on 2020-01-21 09:26 (UTC)

This package is missing the following build dependencies:

  • inetutils (hostname command used during build)
  • xmlto (used to generate man pages)
  • docbook-xsl (required to have xmlto working correctly)

severach commented on 2019-08-10 01:04 (UTC) (edited on 2019-08-10 01:06 (UTC) by severach)

The "normal" diff format isn't very good. It won't apply if everything isn't exact. The context and unified will apply. Unified are the easiest to read.

Subtracting 1 isn't enough. That may shut the compiler up but it will earn us a CVE. strncpy() does not guarantee a nul end of string. The referenced patch has a decent way to guarantee a nul but I like my way better because it also guarantees no random text can appear after the nul.

The real answer is to write a custom strncpy() that has all the behavior we want, guaranteed nul and all nul to end of buffer.

mickybart commented on 2019-08-09 19:26 (UTC)


I have the same issue when I copy/paste it from my comment.

Here is base64 version to avoid that as I don't know how to share it in a proper way.

echo "MjMzYzIzMwo8IAkJCXN0cm5jcHkoaWZyLmlmcl9uYW1lLCBvcHRhcmcsIHNpemVvZihpZnIuaWZyX25hbWUpKTsKLS0tCj4gCQkJc3RybmNweShpZnIuaWZyX25hbWUsIG9wdGFyZywgc2l6ZW9mKGlmci5pZnJfbmFtZSktMSk7CjIzNmMyMzYKPCAJCQlzdHJuY3B5KHNoYy5jZl9uYW1lLCBvcHRhcmcsIHNpemVvZihzaGMuY2ZfbmFtZSkpOwotLS0KPiAJCQlzdHJuY3B5KHNoYy5jZl9uYW1lLCBvcHRhcmcsIHNpemVvZihzaGMuY2ZfbmFtZSktMSk7Cg==" | base64 -d > gcc9-fix.patch

the sha512sum is d4b5c8418cb623fc720d9e401cbbaf1668c172af8b5c658f95efadcce165840fd35c3f4dbb62925de73c1c3e212093e2cb427424b0db4e92ff96eb1c83cd84c4

stramaz commented on 2019-08-09 14:35 (UTC) (edited on 2019-08-09 14:39 (UTC) by stramaz)

Unfortunately the patch of @mickybart doesn't work for me...:

==> Starting prepare()...
patching file programs/tncfg/tncfg.c
Hunk #1 FAILED at 233.
Hunk #2 FAILED at 236.
2 out of 2 hunks FAILED -- saving rejects to file programs/tncfg/tncfg.c.rej
==> ERROR: A failure occurred in prepare().
:: Unable to build openswan - makepkg exited with code: 4

mickybart commented on 2019-07-17 14:50 (UTC) (edited on 2019-07-17 15:08 (UTC) by mickybart)

That need to be fixed upstream but the patch should look something like that to fix the compilation:

# cat gcc9-fix.patch 
<                       strncpy(ifr.ifr_name, optarg, sizeof(ifr.ifr_name));
>                       strncpy(ifr.ifr_name, optarg, sizeof(ifr.ifr_name)-1);
<                       strncpy(shc.cf_name, optarg, sizeof(shc.cf_name));
>                       strncpy(shc.cf_name, optarg, sizeof(shc.cf_name)-1);

You can add the patch in PKGBUILD/prepare():

  # GCC 9 fix
  patch "programs/tncfg/tncfg.c" "$srcdir/gcc9-fix.patch"

It works for me but that need to be discussed with upstream team.

EDIT: similar code issue:

gally commented on 2019-07-10 13:32 (UTC)

downgrading gcc to 8.3.0 didn't work at all for me. Same result as before.

elgs commented on 2019-07-05 06:28 (UTC)

Thank you!! Downgrading both gcc and gcc-libs to 8.3.0 and it worked!!

GPereira commented on 2019-07-04 19:17 (UTC)

Thank you for sending me reports but since I am not able to solve it and I am not using Arch Linux as my daily driver currently it's only logical I orphan this package. PS: Maybe something to do with glibc or gcc version? Try downgrading to GCC 8.2.x and try to compile just to check if that's the issue.

elgs commented on 2019-07-04 09:05 (UTC)

Building failed with the following message:

In function 'strncpy',
    inlined from 'main' at /home/elgs/.cache/yay/openswan/src/openswan-
/usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'strncpy',
    inlined from 'main' at /home/elgs/.cache/yay/openswan/src/openswan-
/usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 12 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [/home/elgs/.cache/yay/openswan/src/openswan- tncfg.o] Error 1
make[3]: Leaving directory '/home/elgs/.cache/yay/openswan/src/openswan-'
make[2]: *** [/home/elgs/.cache/yay/openswan/src/openswan- programs] Error 1
make[2]: Leaving directory '/home/elgs/.cache/yay/openswan/src/openswan-'
make[1]: *** [Makefile:10: programs] Error 1
make[1]: Leaving directory '/home/elgs/.cache/yay/openswan/src/openswan-'
make: *** [Makefile:186: programs] Error 2
==> ERROR: A failure occurred in build().
Error making: openswan

skawikk commented on 2019-07-03 15:11 (UTC)

@GPereira Tried this, still it didn't work.

GPereira commented on 2019-06-28 08:02 (UTC)

Can you try to downgrade python to the version arch Linux had in 14th of June and check if the problem is still there?

GPereira commented on 2019-06-28 08:00 (UTC)

This appears to be an issue upstream. I'll check this

gally commented on 2019-06-28 06:27 (UTC)

Same issue here. No custom compilation flags and same python version as previous comments.

skawikk commented on 2019-06-27 12:27 (UTC)


I have the same problem as Martchus;(

No custom compilation flags in /etc/makepkg.conf
Python 3.7.3


kristian commented on 2019-06-21 07:31 (UTC) (edited on 2019-06-21 07:31 (UTC) by kristian)

I'm having the same issue as Martchus.

  • No custom compilation flags in /etc/makepkg.conf
  • Python 3.7.3

GPereira commented on 2019-06-18 14:21 (UTC)

I can't reproduce your error. Do you have custom compilation flags on /etc/makepkg.conf? If so which ones? what's your default python version?

Martchus commented on 2019-06-18 13:52 (UTC)

It doesn't compile due to some warnings treated as errors:

make[3]: Entering directory '/build/openswan/src/openswan-'
which: no xmlto in (/usr/lib/ccache/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
CC tncfg.c
In file included from /usr/include/string.h:494,
                 from /build/openswan/src/openswan-
In function ‘strncpy’,
    inlined from ‘main’ at /build/openswan/src/openswan-
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 16 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘strncpy’,
    inlined from ‘main’ at /build/openswan/src/openswan-
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 12 equals destination size [-Werror=stringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [/build/openswan/src/openswan- tncfg.o] Error 1

GPereira commented on 2019-06-15 12:02 (UTC)

@lonaowna Done :)

lonaowna commented on 2019-04-08 15:14 (UTC)

Please add conflicts=('strongswan')

lineage commented on 2017-03-03 15:59 (UTC)

I've been having trouble with this version (2.6.49) failing to re-key. Connects ok initially but then the tunnel fails when the keylife expires. xelerance has released a version. I'm now running that and the tunnel seems stable. You might want to update the package to the new version.

bidulock commented on 2016-09-09 08:10 (UTC)

Note that the package cannot install to the /run directory. Remove the entire $pkgdir/var directory and add the following two lines to the [Service] section of the openswan.service file: RuntimeDirectory=pluto RuntimeDirectoryMode=0700 Also, the usr/share/man/man3 directory is empty, remove it in package()

bidulock commented on 2016-09-09 08:07 (UTC)

Note that the update to 2.6.49 commit is still stuck at 2.6.47.

RubenKelevra commented on 2015-10-26 19:59 (UTC)

options=(!makeflags) should be added to the makefile, since setting -j n is very common.

American_Jesus commented on 2015-10-22 23:06 (UTC)

Please revert Notice from the website: "If you have downloaded version 2.6.45 or 2.6.44, please revert to version, as 2.6.44 and 2.6.45 have been found to be unstable in certain environments. We are working on a fix."

yochaigal commented on 2015-10-21 20:29 (UTC)

I had to add "-UNSTABLE" to the pkgver call in order to get this to build properly.

ReLaxLex commented on 2015-09-25 13:59 (UTC)

Nice catch BombStrike I was using -j8, using anything lower than 8 fixes the issue. Had set MAKEFLAGS="-j8" in /etc/makepkg.conf because 'nproc' returned 8 on my laptop ;-) Thx

BombStrike commented on 2015-09-09 04:56 (UTC)

For those hitting the "fatal error: No such file or directory" error. Seems like the issue comes from parallel builds on fast CPUs, my guess is that in some rare cases make tries to compile the lexer before bison is done generating it. Just setting "options=(!makeflags)" in the PKGBUILD should help with those cases.

adambot commented on 2015-08-19 01:54 (UTC)

2.6.44 is released:

dacoit commented on 2015-08-13 13:32 (UTC)

I was able to reproduce the error on gcc-multilib 5.2.0-2 but not on gcc 5.2.0-2 on my x86_64 machine. Not at all sure of the cause.. some kind of bison thing?

ReLaxLex commented on 2015-08-10 06:42 (UTC)

Hi, version 2.6.43 fails to build with error: openswan/src/openswan-2.6.43/lib/libipsecconf/parser.y: warning: 2 shift/reduce conflicts [-Wconflicts-sr] openswan/src/openswan-2.6.43/lib/libipsecconf/parser.y: warning: 4 reduce/reduce conflicts [-Wconflicts-rr] openswan/src/openswan-2.6.43/lib/libipsecconf/keywords.c:37:24: fatal error: No such file or directory Any else seeing this error? I'm using gcc version 5.2.0 (gcc-multilib 5.2.0-1) Thanks, -Lex

JohRest commented on 2015-01-04 19:33 (UTC)

Hi! I'm trying to install openswan from the AUR, but when attempting to deploy the final package via pacman -U I get the following: Pakete (1) openswan-2.6.42-2 + deleted some german text with no relevance.. Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien) openswan: /var/run existiert im Dateisystem The message says; unable to complete (conflict) openswan: /var/run is existing in filesystem. Any hints what to do? The directory indeed does exist... I'm a little bit cautions to simply delete it in order to succeed... Any advice? Thanks in advance! Johannes

uuwe commented on 2014-11-25 02:50 (UTC)

/usr/lib/openswan/setup is an invalid symlink to /etc/rc.d/ipsec. it's causing some programs that use "ipsec setup" to fail. here's a patch:

tuxfanou commented on 2014-10-29 14:52 (UTC)

An update is avable from october 21th (2.6.42). Can you update it ?

yan12125 commented on 2014-09-06 14:28 (UTC)

Please separate build commands from package() and put them in build()

xjpvictor commented on 2013-08-14 13:03 (UTC)

@caspian Just refer to the README file in the openswan source.

caspian commented on 2013-08-14 09:03 (UTC)

Can anybody please tell me how to enable KLIPS support? I couldn't find any arch related documentation regarding this...

x33a commented on 2013-07-12 06:20 (UTC)

Send a mail to aur-general mailing list, asking them to merge this package with openswan.

xjpvictor commented on 2013-06-16 05:41 (UTC)

@gtmanfred Any benefit of doing so? I mean the ipsec startup script is provided by upstream, so why not using it, easier to maintain.

gtmanfred commented on 2013-06-16 05:06 (UTC) better systemd service that doesn't require using the old rc.d file from /usr/lib/systemd/scripts

xjpvictor commented on 2013-06-14 16:17 (UTC)

rc.d scripts removed. @dreur Updated with python2 although I believe upstream should do something to solve it.

commented on 2013-06-13 23:23 (UTC)

1) Should depend on python2 2) /usr/lib/openswan/verify should have a she bang point to python2: #!/usr/bin/python2 Thanks :)

commented on 2013-06-11 23:38 (UTC)

I would say using "conflict"[1] [1] Thanks!

fcolista commented on 2013-06-08 15:31 (UTC)

Ok, what's the best way to do it?

commented on 2013-06-08 15:27 (UTC)

Flagging it out of date - could you make it clearer to use Openswan instead. Also I am updatig the wiki that is still mentioning this package.

xjpvictor commented on 2013-06-04 12:42 (UTC)

Updated to use /usr/bin

fukawi2 commented on 2013-06-04 01:10 (UTC)

Please update PKGBUILD to install binaries to /usr/bin instead of /usr/sbin in line with recent changes:

fcolista commented on 2013-05-24 18:03 (UTC)

Bah, now actually there's no difference. Looking at seemst that it hasn't been updated since over a year, i took the package since it was orphan. Now seems to be alive. There's no need, then, to use this package.

fauno commented on 2013-05-24 16:56 (UTC)

what's the difference with the "openswan" package?

xjpvictor commented on 2013-04-03 14:17 (UTC)

Dropped and adopted openswan instead.

fcolista commented on 2013-01-18 13:04 (UTC)

Please try this last package. Thanks

Severus commented on 2013-01-18 03:09 (UTC)

It doesn't support systemd yet.

fcolista commented on 2012-11-21 21:49 (UTC)

Build correctly. Need test on the road.

dreieck commented on 2012-07-02 15:33 (UTC)

Conflicts with 'ipsec-tools' (file '/etc/rc.d/ipsec'). If openswan's '/etc/rc.d/ipsec' gets renamed, also edit /etc/rc.d/openswan ('openswan.rc.d' in the source tarball) accordingly.

commented on 2012-04-12 01:21 (UTC)

pay attention to your comments plz, md5sum is bad though download url worked for me.

commented on 2012-03-02 14:14 (UTC)

today on a freshly installed server box (kernel 3.2.8) the compilation did fail unless the package gnupg2 was also installed

xjpvictor commented on 2012-02-26 02:31 (UTC)

The md5 is wrong, it should be e5c948555088df06cfadcfbe6c13adfe Download url is not working. Package flex is needed.

slinkygn commented on 2012-02-06 08:06 (UTC)

If that is the case, please add a makedepends=('docbook-xsl') line. (Tested with this modification; builds fine.)

commented on 2012-02-05 01:46 (UTC)

@cambid: Are you active? This package hasn't been updated in over a year, and people want to update it. I'll give you a few days to answer, and if I don't hear anything, I'll orphan it.

lineage commented on 2012-01-27 22:13 (UTC)

I've just managed to build this package. There are quire a few errors like the one listed by jintian. Having fixed them it builds and version 2.6.32 works with NETKEY on linux version 3.1.9-2-ARCH. By works I mean it connects to an existing system (also openswan, but a different version/platform) using x509 certs. The fixes are 'lint' issues in openswan so I need to push it back there.

kennytm commented on 2011-11-03 15:46 (UTC)

This package depends on docbook-xsl to build. Otherwise you'll get fail with 'I/O error : Attempt to load network entity'.

commented on 2011-09-10 03:43 (UTC)

compilation error: /openswan-2.6.32/programs/showpolicy/showpolicy.c:121:19: error: variable ‘tolen’ set but not used [-Werror=unused-but-set-variable]

intgr commented on 2011-08-25 10:52 (UTC)

cambid, if you can't be bothered to update this package, then please disown it so someone else could do it.

fzerorubigd commented on 2011-08-17 05:08 (UTC)

2.6.35 is compilable to. just change the version and update the md5 array

commented on 2011-07-05 14:21 (UTC)

2.6.34 is compilable.

ambala commented on 2011-06-09 09:20 (UTC)

compilation error: /openswan-2.6.32/programs/showpolicy/showpolicy.c:121:19: error: variable ‘tolen’ set but not used [-Werror=unused-but-set-variable]

slot commented on 2010-09-27 09:23 (UTC)

Does not compile here: compilation error: file /tmp/xmlto-xsl.xMBsHo line 4 element import xsl:import : unable to load make[3]: *** [ipsec.conf.5] Fejl 1

fukawi2 commented on 2010-07-29 22:45 (UTC)

Why should they not be added as make-depends? Not everyone installs the 'base-devel' group to be able to use the AUR.

commented on 2010-07-29 16:56 (UTC)

do not add flex and bison. it's part of base-devel

fukawi2 commented on 2010-07-15 06:35 (UTC)

And flex too

fukawi2 commented on 2010-07-14 06:24 (UTC)

bison should be a depends too

parky6 commented on 2010-06-24 07:28 (UTC)

You may add docbook-xml and docbook-xsl to dependences, otherwise xml validation fails

commented on 2010-05-08 01:20 (UTC)

Compile bombs out: cc1: warnings being treated as errors In file included from /tmp/yaourt-tmp-refujee/aur-openswan/openswan/src/openswan-2.6.25/programs/addconn/addconn.c:51:0: /tmp/yaourt-tmp-refujee/aur-openswan/openswan/src/openswan-2.6.25/include/ipsecconf/confread.h:37:19: error: comparison between ‘enum keyword_string_config_field’ and ‘enum keyword_string_conn_field’