libreswan / libreswan Goto Github PK

libreswan

License: Other

Shell 23.34% Makefile 2.77% C 65.69% Perl 0.13% Python 6.45% Yacc 0.19% Lex 0.12% Awk 0.07% HTML 0.06% JavaScript 0.51% CSS 0.02% Roff 0.23% sed 0.35% Dockerfile 0.07% XSLT 0.01%

ipsec

libreswan's Introduction

Libreswan

The Libreswan Project https://libreswan.org/

Libreswan is an Internet Key Exchange (IKE) implementation for Linux, FreeBSD, NetBSD and OpenBSD. It supports IKEv1 and IKEv2 and has support for most of the extensions (RFC + IETF drafts) related to IPsec, including IKEv2, X.509 Digital Certificates, NAT Traversal, and many others.

Libreswan was forked from Openswan 2.6.38, which was forked from FreeS/WAN 2.04. See the CREDITS files for contributor acknowledgments.

It can be downloaded from:

https://download.libreswan.org/

A Git repository is available at:

https://github.com/libreswan/libreswan/

License

The bulk of libreswan is licensed under the GNU General Public License version 2; see the LICENSE and CREDIT.* files. Some smaller parts have a different license.

Installing

A pre-built Libreswan package is available on the following OS distributions: RHEL, Fedora, CentOS, Ubuntu, Debian, Arch, Apline, OpenWrt and FreeBSD. On NetBSD the package sources are in wip/libreswan.

Unless a source-based build is truly needed, it is often best to use the pre-built version of the distribution you are using.

Installing from Source

Requirements

There are a few packages required for Libreswan to compile from source:

For Debian/Ubuntu

apt-get install net-tools make build-essential \
  libnss3-dev pkg-config libevent-dev libunbound-dev \
  bison flex libsystemd-dev libcurl4-nss-dev \
  libpam0g-dev libcap-ng-dev libldns-dev xmlto

For Fedora/CentOS-Stream/RHEL/AlmaLinux/RockyLinux etc.

dnf install audit-libs-devel bison curl-devel flex \
  gcc ldns-devel libcap-ng-devel libevent-devel \
  libseccomp-devel libselinux-devel make nspr-devel \
  nss-devel pam-devel pkgconfig systemd-devel \
  unbound-devel xmlto

Alpine Linux:

aph add mandoc mandoc-doc apk-tools-doc bison \
  bison-doc bsd-compat-headers coreutils coreutils-doc \
  curl-dev curl-doc flex flex-doc gcc gcc-doc git git-doc \
  gmp-dev gmp-doc ldns-dev ldns-doc libcap-ng-dev \
  libcap-ng-doc libevent-dev linux-pam-dev linux-pam-doc \
  make make-doc musl-dev nspr-dev nss-dev nss-tools \
  pkgconfig sed sed-doc unbound-doc unbound-dev \
  xmlto xmlto-doc

FreeBSD:

pkg install gmake git pkgconf nss libevent unbound bison \
  flex ldns xmlto gcc

NetBSD:

pkgin install git gmake nss unbound bison flex ldns xmlto pkgconf

OpenBSD:

pkg_add gmake nss libevent libunbound bison libldns xmlto \
  curl git llvm%16

Building for RPM based systems

Install requirements for rpm package building:

dnf install rpm-build rpmdevtools

The packaging/ directory is used to find the proper spec file for your distribution. Simply issue the command:

make rpm

You can also pick a specific spec file. For example, to build for CentOS8, use:

rpmbuild -ba packaging/centos/8/libreswan.spec

Building for DEB based systems

The packaging/debian directory is used to build deb files. Simply issue the command:

make deb

Building from scratch into /usr/local

GNU Make is used:

gmake
sudo gmake install

If you want to build without creating and installing manual pages, run:

gmake base
sudo gmake install-base

Starting Libreswan

The install will detect the init system used (systemd, upstart, sysvinit, openrc) and should integrate with the linux distribution. The service name is called "ipsec". For example, on CentOS Stream 9, one would use:

systemctl enable ipsec.service
systemctl start ipsec.service

If unsure of the specific init system used on the system, the "ipsec" command can also be used to start or stop the ipsec service. This command will auto-detect the init system and invoke it:

ipsec start
ipsec stop

Status

For a connection status overview, use:

ipsec trafficstatus

For a brief status overview, use:

ipsec briefstatus

For a machine readable global status, use:

ipsec globalstatus

Configuration

Most of the libreswan configuration is stored in /etc/ipsec.conf and /etc/ipsec.secrets . Include files may be present in /etc/ipsec.d/ See the respective man pages for more information.

NSS initialisation

Libreswan uses NSS to store private keys and X.509 certificates. The NSS database should have been initialised by the package installer. If not, the NSS database can be initialised using:

ipsec initnss

PKCS#12 certificates (.p12 files) can be imported using:

ipsec import /path/to/your.p12

See README.NSS and certutil --help for more details on using NSS and migrating from the old Openswan /etc/ipsec.d/ directories to using NSS.

Upgrading

If you are upgrading from older Libreswan versions, Libreswan 5.x you might need to adjust your config files, although great care has been put into making the configuration files full backwards compatible.

See 'man ipsec.conf' for the list of options to find any new features.

You can run make install on top of your old version - it will not overwrite your your /etc/ipsec.* configuration files. The default install target installs in /usr/local. Ensure you do not install libreswan twice, one from a distribution package in /usr and once manually in /usr/local.

Note that for rpm based systems, the NSS directory changed from /etc/ipsec.d to /var/lib/ipsec/nss/

Help

Mailing lists:

The mailing lists, including archives are at https://lists.libreswan.org/

Wiki:

Libreswan's wiki is at https://libreswan.org/wiki/Main_Page. It contains documentation, interop guides and other useful information.

IRC:

Libreswan developers and users can be found on IRC, on irc.libera.chat #libreswan

Bugs

Bugs can be reported on the mailing list [email protected] or using our bug tracking system, at:

https://github.com/libreswan/libreswan/issues

Security Information

All security issues found that require public disclosure will receive proper CVE tracking numbers (see https://www.mitre.org/) and will be co-ordinated via the vendor-sec / oss-security lists. A complete list of known security vulnerabilities is available at:

https://libreswan.org/security/

Please contact [email protected] or:

https://github.com/libreswan/libreswan/security

if you suspect you have found a security issue or vulnerability in libreswan. Encrypted email can be received encrypted to the libreswan OpenPGP key. We strongly encourage you to report potential security vulnerabilities to us before disclosing them in a public forum or in a public security paper or conference.

Development

Those interested in the development, patches, and beta releases of Libreswan can join the development mailing list [email protected] or talk to the development team on IRC in #libreswan on irc.libera.chat

For those who want to track things a bit more closely, the [email protected] mailing list will mail all the commit messages when they happen. This list is quite busy during active development periods.

Documentation

The most up to date documentation consists of the man pages that come with the software. Further documentation can be found at:

https://libreswan.org/

and the wiki at:

https://libreswan.org/wiki/

libreswan's People

Contributors

Stargazers

Watchers

Forkers

st3fan mndambuki hydromet floppym jgimenez dotmark saaros hami-san mkj lkundrak mcr reetp yottanami aveshagarwal networkmanager roelvanmeer zizifu magicbane nawien-sharma turkelb solemnwarning intliang doctaweeks shuixi2013 rgbriggs fatenever teotikalki dkg ibotty paddydoyle gvsurenderreddy kaie tjcarlin-iol thomsh doyzfly rthille hu19891110 dcbw yvshri quancao frankieyin hnutank163 jonaslab antonyantony vukasink ericcurtin sahanaprasad07 mtotale exhesham supair sinbadfreedom gezidan tisj lzbgt afranchuk bharathmeduri gotoolkits qiumike 123kayi 0x6773 valor7 dstw vitorhugop huangzhuohua vaskravchuk autowire aseter elysiumltd thermeon fengjiang96 ttimpe royowor vadorovsky pks-os wujcheng brozs giorni thepro-dot-xyz hongruixing tobhe almosttoolate ayousir lanxbrad zhaodan2000 izhax wuw92 yybysj wfranzini hotmanlee fahedhijazi telmate vpn-v2ray kmansoft erezbuchnikethernity olafmanczak fcntl johnmah dev-cdmm ed-os choppsv1

libreswan's Issues

libreswan on GCE(Google Compute Engine) CentOS 6.3 instance

GCE CentOS has a harden kernel to change /proc directory's file content, log showing as follows

[root@ks3c63 ~]# ipsec version;ipsec setup stop
Linux Libreswan 3.0 (netkey) on 2.6.39-gcg-201210301000
Redirecting to: service ipsec stop
Missing control file /var/run/pluto/pluto.ctl - is pluto still running?
Opening /proc/modules: No such file or directory
Opening /proc/modules: No such file or directory
[root@ks3c63 ~]#

Is there a way for libreswan to work with this limitation ?

Another GCE instance running openswan has no attempt to access /proc/modules.

[root@ks4c64 ~]# ipsec version;ipsec setup stop
Linux Openswan U2.6.32/K2.6.39-gcg-201210301000 (netkey)
See `ipsec --copyright' for copyright information.
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: stop ordered, but IPsec appears to be already stopped!
ipsec_setup: doing cleanup anyway...
[root@ks4c64 ~]#

IKEv2 NAT (both sides) and multiple initiators

Hi,

I am trying to get multiple clients working from behind same NAT and so far the only way I got it working is with using separate multiple public IPs for the server.

From looking at NAT router (Linux box) and pluto logs it looks like it is replaying to initial IKE packets always to port 500 event if the request came from NAT'ed port (264 in my case). This obviously makes the NAT router to forward the packet to wrong host (the first initiator):

udp      17 177 src=192.168.1.115 dst=54.229.59.193 sport=4500 dport=4500 src=54.229.59.193 dst=89.100.95.78 sport=4500 dport=4500 [ASSURED] mark=0 secmark=0 use=2
udp      17 151 src=192.168.1.115 dst=54.229.59.193 sport=500 dport=500 src=54.229.59.193 dst=89.100.95.78 sport=500 dport=500 [ASSURED] mark=0 secmark=0 use=2
udp      17 1 src=192.168.2.149 dst=54.229.59.193 sport=500 dport=500 [UNREPLIED] src=54.229.59.193 dst=89.100.95.78 sport=500 dport=264 mark=0 secmark=0 use=2

while the second initiator connection state sees no reply (UNREPLIED).

So question here is: Is there any setting or patch that would make libreswan to reply to actual initiator source port and nat always stick with port 500?

Now even if I wait or delete state from the router to let the second initiator communicate with the server and I end up with two connections established they can't still use the connection simultaneously. This time I observe that xfrm state is not matching source port but generically source IP only:

src 89.100.95.78 dst 10.1.0.22
    proto esp spi 0x6218a96b reqid 16389 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha1) 0x787551aee52e090dbf8e2be2c3382a9e8365d966 96
    enc cbc(des3_ede) 0xf7b883c90d343385ebe8a32c280578b808e3266bb2efe8ce
    encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
src 10.1.0.22 dst 89.100.95.78
    proto esp spi 0x0e126df6 reqid 16389 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha1) 0x3bea73fd690b05922c3044df5975d2e028d84fe3 96
    enc cbc(des3_ede) 0x5abe13e8f306e762ba3137d21b94b979dd226dc068f404fc
    encap type espinudp sport 4500 dport 4500 addr 0.0.0.0

src 89.100.95.78 dst 10.1.0.22
    proto esp spi 0x28dedf89 reqid 16389 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha1) 0x39a2f21c4d53c287495089271215837bf84bbe75 96
    enc cbc(des3_ede) 0x84ddeec147324c9732ac73ad74835263dae3e62f171bc330
    encap type espinudp sport 2818 dport 4500 addr 0.0.0.0
src 10.1.0.22 dst 89.100.95.78
    proto esp spi 0xafbf5fbc reqid 16389 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha1) 0xb9e9a532ad6ff129f14d526893d441fe01287dc2 96
    enc cbc(des3_ede) 0x491913309ed670d941cb9d62f01d9d5050ef641ae4363c50
    encap type espinudp sport 4500 dport 2818 addr 0.0.0.0

I was expecting to see something like src 10.1.0.22 dst 89.100.95.78 proto udp sport 2818.

So question is: Is there any hope in getting this working?
I know you can't get this working with L2TP since L2TP layer has no way distinguishing the SAs but with IKEv2 this is not a problem.

My current workaround is to assign multiple public IP addresses so that NAT router can distinguish flows based on destination IP address and also get separate xfrm entries.
I still need to do more testing to see if this is stable.

I am using libreswan 3.16:

version 2.0

config setup
    # none all raw crypt parsing emitting control lifecycle kernel pfkey nat-t dpd dns oppo oppoinfo whackwatch private x509
    #plutodebug="control parsing x509"
    plutodebug="none"
    nat_traversal=yes
    uniqueids=no
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10

conn %default
    # This may come handy if fragmented IP packets are dropped or DF'ed
    ike_frag=yes

    # x509
    authby=rsasig
    leftcert="example.com - example.com"
    leftsendcert=always
    leftid=%fromcert
    rightid=%fromcert

    pfs=no
    # we cannot rekey for %any, let client rekey
    rekey=no

    # Timeouts
    ## Set ikelifetime and keylife to same defaults windows has
    ikelifetime=8h
    keylife=1h
    rekeymargin=3m
    keyingtries=3

    # Dead node detection
    dpddelay=4
    dpdtimeout=30
    dpdaction=clear

    # ID
    left=%eth0
    right=%any

    # listen for auto keying connections
    auto=add

conn RoadWarrior-IKEv2
    ikev2=insist
    rightaddresspool=10.224.1.97-10.224.1.128
    # Changed default in libreswan 3.16
    ike=3des-sha1;modp1024
    # Subnet that is accessible for the client (NOTE: leftsubnets= does not work with rightaddresspool...)
    leftsubnet=10.0.0.0/8
    # See: https://github.com/libreswan/libreswan/issues/47
    rightid=%myid
    forceencaps=yes

Regards,
Jakub

"/etc/ipsec.d/{ca|aa}certs: No such file or directory" after "ipsec setup start"

Anyway to silence the following errors ? For a basic PSK setup without certificate creation, following error messages in pluto log file.

Could not change to directory '/etc/ipsec.d/cacerts': No such file or directory
Could not change to directory '/etc/ipsec.d/aacerts': No such file or directory
Could not change to directory '/etc/ipsec.d/crls': 2 No such file or directory

My current workaround is to create those directories manually.

Thanks

Package ldns-1.6.16-7.el6.1.x86_64.rpm is not signed

Installing libreswan using rpms from libreswan.org fails with ldns package not signed error.
/etc/yum.repos.d/libreswan.repo

[libreswan]
name=Libreswan $releasever - $basearch
failovermethod=priority
baseurl=http://download.libreswan.org/binaries/rhel/$releasever/$basearch/
enabled=1
metadata_expire=1d
skip_if_unavailable=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-libreswan

gpg file is in path

$ ll /etc/pki/rpm-gpg/
total 16
-rw-r--r-- 1 root root  987 Mar 10 23:04 RPM-GPG-KEY-amazon-beta
-rw-r--r-- 1 root root  984 Mar 10 23:04 RPM-GPG-KEY-amazon-ga
-rw-r--r-- 1 root root 1649 Mar  1  2013 RPM-GPG-KEY-EPEL-6
-rw-r--r-- 1 root root 3511 Jan  3  2013 RPM-GPG-KEY-libreswan

gpg is imported

$ rpm -qi gpg-pubkey-b30fc6f9-50e38a57
Name        : gpg-pubkey
Version     : b30fc6f9
Release     : 50e38a57
Architecture: (none)
Install Date: Thu 08 Jun 2017 12:20:31 AM UTC
Group       : Public Keys
Size        : 0
License     : pubkey
Signature   : (none)
Source RPM  : (none)
Build Date  : Wed 02 Jan 2013 01:16:07 AM UTC
Build Host  : localhost
Relocations : (not relocatable)
Packager    : Libreswan (Signing Key) <[email protected]>
Summary     : gpg(Libreswan (Signing Key) <[email protected]>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.11.3 (NSS-3)

mQINBFDjilcBEAChkfasfBKTzGys9DwgBsmDVsPConW60uyKnu16+wO1kIKMFWi6
wGllwKUJmCBY2FSQHbOBy5eHPPT1ijJhYt4j7WU+YJVh5Ca5RE3trFt31FX0vzp+
KMqdQ8HOofA7jO6bgyHUwOJ539YkqYj1jHKfrdRqOnzB9fFyEb7485sq1F8j/rHk
cSar1Hd9QfGAZHxXqgncgHFobB/xXEGRJIi+4kNL5SYasbw9tfYUGPrUXVol1+pn
tsG92736O5Qe5K+wH2nAS4hwPJ1Xr4XIKeNNwxQW25wWqn4mLa4Vly+PA2uSE7ZP
RcxE3yBCaLFMlw4rLhFAzd6TeslQONZ+9K51yfBYm7m0vWM3Ixq8yuD8E49OkKr8
QRMaA2g89NW3AuNLExiTE0zQzAs/g6eX8WZdeWCvKxhRTAUYkw0QTimFgv6LXIeS
//5DOAAO9WwzlseTGmUgek3BbnnJJiGHVLBgnLaqWLOZ1Y8ON1uC8lQnbIeYbTQq
EE5R0cbVLVXBJoKakBF8gwHF51HC2pSBYmHNZsSbjMuHpJWJM4fVldNWPNaqriKC
OkL8QgvNoapgk20k1ajLl/ibv32k7QBKy3cTMtbQYPdreXcoZuMw38ysQcgFxPCs
Zh92aaWW0ceWowkJ7CFnes2jdPcMSOYE37wodmV3/VV7cusmTD8wikyUdQARAQAB
tCxMaWJyZXN3YW4gKFNpZ25pbmcgS2V5KSA8dGVhbUBsaWJyZXN3YW4ub3JnPokC
OAQTAQIAIgUCUOOKVwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQhf9L
Q7MPxvkHyRAAgSq/QhdBurBaIjzqM4jZpaHEOURPlL38wHTBBeH4U5IZcwiPul9X
Et1HqwHLDv89YjljHj76oOLt5xR14exgV0xWolZaLVpji3S6/NbCh37UMoWIBCSP
j6/S6oAXxtX+oCI1lXmS4w60ZDDuYgVUrtAv77ODlQoPVf5TM0tU7Gb2Y3WB47DS
XioIzwjFwJmtK3RzDRtF4oC2YFN3DBovVHmv6hbIt7NDNp7+NYRlx+wdi+XYFcNv
+ZIARFkoc1Sr4HDk+lA2qx5jfvgZvabTn7OCTlCKwkSwO5sK0ICNcLmG9nb4ZNrU
C2GXryTNQOMLcdvZAyBvxtgNzI7qqMAxeipsyCz5ypp5S3SwzHjqeCUJJ4pv7Ebn
BnYIOgdLkq/WPsS6om7qwr3EdkR8iTZnuTi2Fejw7WnQP8dYLVXwG/90vNCU/HTE
IYhal4ob7p0SsyLYF47U/iKl/b6ZErOcbq3YF0fMe8iusAtNLeIN4BLk9tpclGde
weTPuB+MhRuDsLCF764ZB/R5v0CjWFVcBxnRXQbjlrm6dMlEXPFKjjV1fHL1HZhB
GXopPmsw+NIf9sTSjcgNnLZGJFGGBsIxQD18AN6nzi2vtGRksB/FqLY7gIeGWaPu
HlUI1qHdRLS7aus9nrS/RQTTUdCOsn1fRVozX2eVklAWgLuoz58oPhiJARwEEAEI
AAYFAlDlHbkACgkQ5xgGprXMJ+Hc8Qf/Sd4NJMJifpU8hYET7IzMSgAdGZkkFV7/
3/YCoEIVQS18xx+66L/TrUrAtJnlHLpmNUMA1wVFTtGJ/CRwFt3LsZYVM1jCwdRe
AF492OHxEWXAboVnGRnGfJ3yhfCTd3XgRbthqBwR/8BSWCzs9Gy9YA5N6oceNf6q
QkkLKk3YwdSNnW3b7o/AVdNcFbwkE+amNQ2mhWUtzzuvlsmgOrnCpUlq3djhnEKs
pbl+T/apqvn7JRsOvuy/26kjoTbVrb7OpFmAjlIqbbxokaONFuDpqn/mtgG7Bk0r
3Pv501mRItACslhaKPJ02oPufAmzBrphjzzhCYlR1TeEek++9qoHyLkCDQRQ44pX
ARAA1wzfaN4nMg8vorcuOQrEH6NX/OMS+qCSIAixhsJt0RT4Ds3YMWhO04i81tjQ
bovsh8sOPFkU8WfVwuh7Riox+lz7z+ZxePMLLO7Y80Tc5jYE6exuOx5Ft5Q9FWF+
DanwpsUCvYE16G9fiRZlpBF5F5mWINnW59URLR29N8d+9GeeO6473aaKUFuo2ksN
AueegzsW/cHiai6gHdrmTuJ8Ibg7P1TPkMsvvzJR0257Jp2CDKMwyzJh2dTzHiZU
xTzH2qWrsfVA04EOXcC49hYkP7hDM731b1tt4cZaVlR7HHMGUe+zzA7eDW4/+0JT
iCqYIndq/EsgZoYxE9rv1EksxWMyvCdlo6C3MYrjE8K5zOm926orkg1DABKDTfNe
Am6c+siwdsMirOTe2QP5VSzRPDFe7aPDg8MNZ0tmww3+fyTDbeWlrv4jtmwa2BN9
C6h0d20lekD+eyZ87pzPWOFdQZxCmFteAPfq0R9ZNXuQrkubasaUrm54hfNAHVMj
4xfK1zmNFEQ+s2NLOPONzX/Uza/JHv9ZmqixJFABdNwMAUfKM9uO8pbu+aveMraW
FBSQJDXqqZPF8qaiiTFXJeDXxD/d9CUfNrBozcpVbv2+BLKin5pKFPFRTNZX7mql
9btmQ6FKRtiKP86XldO0UNCkx3SgXo84sdiDdE+1uBtCV3MAEQEAAYkCHwQYAQIA
CQUCUOOKVwIbDAAKCRCF/0tDsw/G+SkfD/43VjVVcO+P6Aj7be/Vda9FzeCNGQU0
GYCqdyZmXXGZUtlM8eLtVYcXHrw0O34f2eWNcQwYfiCsBfN4SSl8uevjyQZWCBo3
NhkxJlNcqOBPYrnT6uehRW+nnpV9agX8SNGR3VoM1pq7Zwheucxk5nmDKXJOGbin
SQF9gDOpFnAYpLeI0/0qq3EvLf3blkUklYopMFw/Gj3sQM/V7nsyPstxMbqbf5al
MlbQld7dP4FkQDLsKzB/0QARD02kHZsSs4tDpDA5R4cHl2VoNP7d9ly4YZsuH/99
DYSmJ57Tev6XTQ2/L4p+Tj9jEciQxyMpANh2XGL43WUuN/j24rqgwkyCzL8VA2I8
R7M4BIXi2q4kb5kcBNR0Y2VjU8xk41IMr/N11IayKAJYDFctrUAGrSmzVWAJ+XZg
NDQgyp0rM2rON4AKUko4dlF5qv6MMKVY+s2B3KFdIHQriydQTy7LTdGRjvoPnkaU
yPe/v9OLIM/4SJg7Juxtw4p3q7PxQ2nm7aTEc1bIYeZSIFQZwk9+oXR1vG7sogIE
ULY6u21/CSzeBK5sZauGt9zmHO0xjQt4xUZuF0mOkVAzHeroUQ+YSmQdjfGs9O/e
tNyu53Pd8d9grmpRwiQ/jO2dv4/a90903MuvaDPqYD+PMMkqPlxBhwjOThu2DTYi
fMUPyfgigsi0FQ==
=X982
-----END PGP PUBLIC KEY BLOCK-----

yum fails

$ sudo yum install libreswan
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main                                                                                                | 2.1 kB  00:00:00     
amzn-updates                                                                                             | 2.3 kB  00:00:00     
epel/x86_64/metalink                                                                                     |  12 kB  00:00:00     
epel                                                                                                     | 4.3 kB  00:00:00     
libreswan                                                                                                | 2.9 kB  00:00:00     
(1/4): epel/x86_64/group_gz                                                                              | 150 kB  00:00:00     
(2/4): epel/x86_64/updateinfo                                                                            | 749 kB  00:00:00     
(3/4): epel/x86_64/primary_db                                                                            | 5.9 MB  00:00:00     
(4/4): libreswan/latest/x86_64/primary_db                                                                |  21 kB  00:00:00     
(1/5): amzn-main/latest/group                                                                            |  35 kB  00:00:00     
(2/5): amzn-updates/latest/group                                                                         |  35 kB  00:00:00     
(3/5): amzn-updates/latest/updateinfo                                                                    | 390 kB  00:00:00     
(4/5): amzn-updates/latest/primary_db                                                                    | 322 kB  00:00:00     
(5/5): amzn-main/latest/primary_db                                                                       | 3.6 MB  00:00:00     
1004 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package libreswan.x86_64 0:3.20-1.el6 will be installed
--> Processing Dependency: libunbound.so.2()(64bit) for package: libreswan-3.20-1.el6.x86_64
--> Running transaction check
---> Package unbound-libs.x86_64 0:1.4.20-23.el6.1 will be installed
--> Processing Dependency: libpython2.6.so.1.0()(64bit) for package: unbound-libs-1.4.20-23.el6.1.x86_64
--> Processing Dependency: libldns.so.1()(64bit) for package: unbound-libs-1.4.20-23.el6.1.x86_64
--> Processing Dependency: libevent-1.4.so.2()(64bit) for package: unbound-libs-1.4.20-23.el6.1.x86_64
--> Running transaction check
---> Package compat-libevent.x86_64 0:1.4.13-4.10.amzn1 will be installed
---> Package ldns.x86_64 0:1.6.16-7.el6.1 will be installed
--> Processing Dependency: libpcap.so.1()(64bit) for package: ldns-1.6.16-7.el6.1.x86_64
---> Package python26-libs.x86_64 0:2.6.9-2.88.amzn1 will be installed
--> Processing Dependency: python26 = 2.6.9-2.88.amzn1 for package: python26-libs-2.6.9-2.88.amzn1.x86_64
--> Running transaction check
---> Package libpcap.x86_64 14:1.4.0-1.20130826git2dbcaa1.10.amzn1 will be installed
---> Package python26.x86_64 0:2.6.9-2.88.amzn1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved


================================================================================================================================
 Package                     Arch               Version                                             Repository             Size
================================================================================================================================
Installing:
 libreswan                   x86_64             3.20-1.el6                                          libreswan             1.6 M
Installing for dependencies:
 compat-libevent             x86_64             1.4.13-4.10.amzn1                                   amzn-main             115 k
 ldns                        x86_64             1.6.16-7.el6.1                                      libreswan             443 k
 libpcap                     x86_64             14:1.4.0-1.20130826git2dbcaa1.10.amzn1              amzn-main             144 k
 python26                    x86_64             2.6.9-2.88.amzn1                                    amzn-main             5.8 M
 python26-libs               x86_64             2.6.9-2.88.amzn1                                    amzn-main             697 k
 unbound-libs                x86_64             1.4.20-23.el6.1                                     libreswan             302 k

Transaction Summary
================================================================================================================================
Install  1 Package (+6 Dependent packages)

Total download size: 9.1 M
Installed size: 28 M
Is this ok [y/d/N]: y
Downloading packages:
(1/7): libpcap-1.4.0-1.20130826git2dbcaa1.10.amzn1.x86_64.rpm                                            | 144 kB  00:00:00     
(2/7): compat-libevent-1.4.13-4.10.amzn1.x86_64.rpm                                                      | 115 kB  00:00:00     
(3/7): python26-libs-2.6.9-2.88.amzn1.x86_64.rpm                                                         | 697 kB  00:00:00     
Package ldns-1.6.16-7.el6.1.x86_64.rpm is not signed% [==================-                    ] 1.3 MB/s | 4.3 MB  00:00:03 ETA 
(4/7): ldns-1.6.16-7.el6.1.x86_64.rpm                                                                    | 443 kB  00:00:01     
(5/7): python26-2.6.9-2.88.amzn1.x86_64.rpm                                                              | 5.8 MB  00:00:01     
(6/7): unbound-libs-1.4.20-23.el6.1.x86_64.rpm                                                           | 302 kB  00:00:00     
(7/7): libreswan-3.20-1.el6.x86_64.rpm                                                                   | 1.6 MB  00:00:02     
--------------------------------------------------------------------------------------------------------------------------------
Total                                                                                           4.3 MB/s | 9.1 MB  00:00:02     


Package ldns-1.6.16-7.el6.1.x86_64.rpm is not signed

nogpgcheck works

sudo yum --nogpgcheck install libreswan

Am I missing something or ldns is not really signed?

/usr/bin/ld: Warning: size of symbol `cavp_ikev2' changed from 48 in cavp.o to 64 in cavp_ikev2.o

during a build on a debian system, i'm seeing this warning from the linker while it's trying to build cavp:

cc -o cavp cavp.o cavp_print.o cavp_stubs.o cavp_ikev1.o cavp_ikev2.o cavp_sha.o cavp_hmac.o cavp_gcm.o connections.o initiate.o terminate.o ike_alg_nss_cbc.o cbc_test_vectors.o ctr_test_vectors.o gcm_test_vectors.o test_buffer.o pending.o cookie.o crypto.o defs.o foodgroups.o log.o state.o plutoalg.o server.o state_entry.o timer.o hmac.o hostpair.o myid.o ipsec_doi.o ikev1.o ikev1_main.o ikev1_quick.o ikev1_dpd.o ikev1_spdb_struct.o ikev1_msgid.o ikev2.o ikev2_parent.o ikev2_child.o ikev2_spdb_struct.o ikev2_rsa.o ikev2_psk.o ikev2_crypto.o crypt_dbg.o crypt_symkey.o crypt_prf.o ikev1_prf.o ikev2_prf.o crypt_hash.o kernel.o kernel_netlink.o kernel_pfkey.o kernel_noklips.o rcv_whack.o demux.o msgdigest.o keys.o pluto_crypt.o crypt_utils.o crypt_ke.o crypt_dh.o crypt_start_dh.o rnd.o spdb.o spdb_struct.o vendor.o nat_traversal.o virtual.o ike_alg_aes.o ike_alg_dh.o ike_alg_camellia.o ike_alg_nss_hash_ops.o ike_alg_hmac_prf_ops.o ike_alg_nss_prf_ops.o ike_alg_nss_gcm.o ike_alg_null.o ike_alg_serpent.o ike_alg_twofish.o ike_alg_cast.o ike_alg_ripemd.o ike_alg_sha1.o ike_alg_md5.o ike_alg_3des.o ike_alg_sha2.o ike_alg.o db_ops.o ikev1_xauth.o addresspool.o pam_conv.o ikev1_aggr.o pluto_sd.o x509.o fetch.o sysdep_linux.o packet.o pluto_constants.o readwhackmsg.o nss_cert_load.o pem.o nss_cert_vfy.o nss_ocsp.o nss_crl_import.o nss_err.o udpfromto.o \
	-Wl,-z,relro -lnss3 -lnspr4 -lnss3 -lnspr4 -Wl,-z,relro,-z,now -g -pie   /home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/lib/libswan/libswan.a     /home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/lib/libcrypto/libserpent/libserpent.a /home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/lib/libcrypto/libtwofish/libtwofish.a   -lsystemd /home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/lib/libwhack/libwhack.a  -lnss3 -lnspr4 -lpthread -lcap-ng /home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/lib/libipsecconf/libipsecconf.a /home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/lib/libswan/libswan.a   -lrt -lunbound -levent -levent_pthreads -llber -lldap -llber -lcurl -lpthread -lcrypt -lpam -lnss3 -lnspr4 
/usr/bin/ld: Warning: size of symbol `cavp_ikev1_psk' changed from 48 in cavp.o to 64 in cavp_ikev1.o
/usr/bin/ld: Warning: size of symbol `cavp_ikev1_sig' changed from 48 in cavp.o to 64 in cavp_ikev1.o
/usr/bin/ld: Warning: size of symbol `cavp_ikev2' changed from 48 in cavp.o to 64 in cavp_ikev2.o
make[5]: Leaving directory '/home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/programs/pluto'

I'm afraid i don't know what the warning means, but i thought i'd raise it here in case anyone from upstream knows and has an idea what to do about it.

A minor packaging issue on /etc/ipsec.d/examples

A minor packaging issue, /etc/ipsec.d/examples directory is not included.
If this intentional then please update /etc/ipsec.conf to remove examples directory reference

[root@mlab-centos6-01 etc]#ipsec version
Linux Libreswan U3.0/K(no kernel code presently loaded) on 2.6.32-279.22.1.el6.x86_64
[root@mlab-centos6-01 etc]# grep examples /etc/ipsec.conf

for more examples, see /etc/ipsec.d/examples/

[root@mlab-centos6-01 etc]# ls /etc/ipsec.d/examples
ls: cannot access /etc/ipsec.d/examples: No such file or directory
[root@mlab-centos6-01 etc]#

resolve_defaultroute_one fails when a conn uses %defaultroute and a named peer

When resolve_defaultroute_one is called for a connection that has left=%defaultroute and right=, it determines that it does not have an IP for the peer, source, or gateway. However, under this set of condition it can not populate any of these field and fails to bring up the resulting connection ("We cannot identify ourselves [...]"). If either left or right is replaced with an appropriate IP address the connection will succeed.

Multiple PSK in ipsec.secrets

Hello,

There's a problem with multiple PSK (ipsec.secrets dump):

%any %any : PSK "ABC"
%any %any : PSK "123"
%any %any : PSK "XYZ"

Only the first PSK will be valid (clients cannot connect with the following PSK: "123" and "XYZ").

Libreswan 3.20 segfault

Hello!

Libreswan segfaults frequently (1-2min uptime). Details below. When i remove the "conn customer" everything is ok.

2017-06-01T20:24:17+02:00 firewall1 pluto[15095]: packet from 1.2.3.4:500: phase 1 message is part of an unknown exchange
2017-06-01T20:24:17+02:00 firewall1 pluto[15095]: "customer" #1492: responding to Main Mode
2017-06-01T20:24:17+02:00 firewall1 pluto[15095]: "customer" #1492: Oakley Transform [OAKLEY_AES_CBC (128), OAKLEY_MD5, OAKLEY_GROUP_MODP2048] refused
2017-06-01T20:24:17+02:00 firewall1 kernel: [14472502.617889] pluto[15095]: segfault at 3c ip 00007f1e8530013c sp 00007fff63ba7f60 error 4 in pluto[7f1e8528d000+11a000]
2017-06-01T20:24:17+02:00 firewall1 logger: file core_pluto_pid_15095_killed_with_11 created
2017-06-01T20:24:17+02:00 firewall1 ipsec__plutorun: !pluto failure!: exited with error status 139 (signal 11)
2017-06-01T20:24:17+02:00 firewall1 ipsec__plutorun: restarting IPsec after pause...
2017-06-01T20:24:17+02:00 firewall1 logger: file /var/crash/core_pluto_pid_17774_killed_with_11 deleted

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/ipsec/pluto --config /etc/ipsec.conf --nofork'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f1e8530013c in ike_alg_ok_final (alg_info_ike=, group=, prf=0x0, key_len=0, ealg=)
at /root/libreswan-3.20/programs/pluto/ikev1_spdb_struct.c:859
859 libreswan_log(
(gdb) bt
#0 0x00007f1e8530013c in ike_alg_ok_final (alg_info_ike=, group=, prf=0x0, key_len=0, ealg=)
at /root/libreswan-3.20/programs/pluto/ikev1_spdb_struct.c:859
#1 parse_isakmp_sa_body (sa_pbs=sa_pbs@entry=0x7f1e864725f8, sa=sa@entry=0x7f1e86472638, r_sa_pbs=r_sa_pbs@entry=0x7fff63ba8660, selection=selection@entry=0,
st=st@entry=0x7f1e86231530) at /root/libreswan-3.20/programs/pluto/ikev1_spdb_struct.c:1405
#2 0x00007f1e852f6986 in main_inI1_outR1 (md=0x7f1e86472450) at /root/libreswan-3.20/programs/pluto/ikev1_main.c:807
#3 0x00007f1e852f308a in process_packet_tail (mdp=mdp@entry=0x7fff63ba8a38) at /root/libreswan-3.20/programs/pluto/ikev1.c:2094
#4 0x00007f1e852f3819 in process_v1_packet (mdp=mdp@entry=0x7fff63ba8a38) at /root/libreswan-3.20/programs/pluto/ikev1.c:1591
#5 0x00007f1e8532315b in process_packet (mdp=mdp@entry=0x7fff63ba8a38) at /root/libreswan-3.20/programs/pluto/demux.c:162
#6 0x00007f1e853232f0 in comm_handle (ifp=) at /root/libreswan-3.20/programs/pluto/demux.c:234
#7 comm_handle_cb (fd=, event=, arg=) at /root/libreswan-3.20/programs/pluto/demux.c:193
#8 0x00007f1e8394ff24 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
#9 0x00007f1e852eb668 in main_loop () at /root/libreswan-3.20/programs/pluto/server.c:663
#10 call_server () at /root/libreswan-3.20/programs/pluto/server.c:798
#11 0x00007f1e852afb75 in main (argc=, argv=) at /root/libreswan-3.20/programs/pluto/plutomain.c:1710

(gdb) bt full
#0 0x00007f1e8530013c in ike_alg_ok_final (alg_info_ike=, group=, prf=0x0, key_len=0, ealg=)
at /root/libreswan-3.20/programs/pluto/ikev1_spdb_struct.c:859
ealg_insecure =
#1 parse_isakmp_sa_body (sa_pbs=sa_pbs@entry=0x7f1e864725f8, sa=sa@entry=0x7f1e86472638, r_sa_pbs=r_sa_pbs@entry=0x7fff63ba8660, selection=selection@entry=0,
st=st@entry=0x7f1e86231530) at /root/libreswan-3.20/programs/pluto/ikev1_spdb_struct.c:1405
life_type =
attr_start = 0x7f1e864d79ac "\200\004"
seen_attrs =
ta = {encrypt = 0, enckeylen = 0, integ_hash = 0, auth = 1, doing_xauth = 0, esn_enabled = 0, life_seconds = {delta_secs = 28800}, life_kilobytes = 0,
encrypter = 0x0, prf = 0x0, integ = 0x0, group = 0x7f1e855b4340 <oakley_group_modp2048>, ei = 0x0}
ugh = 0x0
trans = {isat_np = 0 '\000', isat_reserved = 0 '\000', isat_length = 24, isat_transnum = 2 '\002', isat_transid = 1 '\001', isat_reserved2 = 0}
trans_pbs = {container = 0x7fff63ba8060, desc = 0x7f1e855a7dd0 <isakmp_isakmp_transform_desc>, name = 0x7f1e8537f9a8 "ISAKMP Transform Payload (ISAKMP)",
start = 0x7f1e864d79a4 "", cur = 0x7f1e864d79bc "\r", roof = 0x7f1e864d79bc "\r", lenfld = 0x0, lenfld_desc = 0x0}
attr_len =
seen_durations =
c =
xauth_init = 0
xauth_resp = 0
role = 0x7f1e8536fd1a "responder"
func = "parse_isakmp_sa_body"
spd =
ipsecdoisit = 1
proposal = {isap_np = 0 '\000', isap_reserved = 0 '\000', isap_length = 68, isap_proposal = 0 '\000', isap_protoid = 1 '\001', isap_spisize = 0 '\000',
isap_notrans = 2 '\002'}
proposal_pbs = {container = 0x7f1e864725f8, desc = 0x7f1e855a7df0 <isakmp_proposal_desc>, name = 0x7f1e8537f21f "ISAKMP Proposal Payload",
start = 0x7f1e864d7978 "", cur = 0x7f1e864d79bc "\r", roof = 0x7f1e864d79bc "\r", lenfld = 0x0, lenfld_desc = 0x0}
last_transnum = 2
no_trans_left = 1
#2 0x00007f1e852f6986 in main_inI1_outR1 (md=0x7f1e86472450) at /root/libreswan-3.20/programs/pluto/ikev1_main.c:807
res =
sa_pd = 0x7f1e864725f8
st = 0x7f1e86231530
c = 0x7f1e86435980
r_sa_pbs = {container = 0x7f1e864725a0, desc = 0x7f1e855a7e30 <isakmp_sa_desc>, name = 0x7f1e8537f9d0 "ISAKMP Security Association Payload",
start = 0x7f1e855c3b1c <reply_buffer+28> "\r", cur = 0x7f1e855c3b24 <reply_buffer+36> '\372' <repeats 200 times>..., roof = 0x7f1e855d3b00 <reply_stream> "",
lenfld = 0x7f1e855c3b1e <reply_buffer+30> "\372\372", lenfld_desc = 0x7f1e855b0470 <isasa_fields+48>}
numvidtosend = 3
func = "main_inI1_outR1"
#3 0x00007f1e852f308a in process_packet_tail (mdp=mdp@entry=0x7fff63ba8a38) at /root/libreswan-3.20/programs/pluto/ikev1.c:2094
md = 0x7f1e86472450
st =
from_state = STATE_MAIN_R0
---Type to continue, or q to quit---
smc = 0x7f1e855ae140 <v1_state_microcode_table>
new_iv_set =
self_delete =
func = "process_packet_tail"
#4 0x00007f1e852f3819 in process_v1_packet (mdp=mdp@entry=0x7fff63ba8a38) at /root/libreswan-3.20/programs/pluto/ikev1.c:1591
md = 0x7f1e86472450
smc = 0x7f1e855ae140 <v1_state_microcode_table>
new_iv_set = 0
st = 0x0
from_state = STATE_MAIN_R0
func = "process_v1_packet"
FUNCTION = "process_v1_packet"
#5 0x00007f1e8532315b in process_packet (mdp=mdp@entry=0x7fff63ba8a38) at /root/libreswan-3.20/programs/pluto/demux.c:162
md =
vmaj =
vmin =
#6 0x00007f1e853232f0 in comm_handle (ifp=) at /root/libreswan-3.20/programs/pluto/demux.c:234
md = 0x7f1e86472450
#7 comm_handle_cb (fd=, event=, arg=) at /root/libreswan-3.20/programs/pluto/demux.c:193
No locals.
#8 0x00007f1e8394ff24 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
No symbol table info available.
#9 0x00007f1e852eb668 in main_loop () at /root/libreswan-3.20/programs/pluto/server.c:663
r =
pluto_evs = {ev_ctl = 0x7f1e85365bff, ev_sig_hup = 0x7f1e85365c07, ev_sig_sys = 0x7f1e855b53a2 <ctl_addr+2>, ev_sig_term = 0x7f1e85365c11, ev_sig_chld = 0x0}
#10 call_server () at /root/libreswan-3.20/programs/pluto/server.c:798
func = "call_server"
#11 0x00007f1e852afb75 in main (argc=, argv=) at /root/libreswan-3.20/programs/pluto/plutomain.c:1710
log_to_stderr_desired =
log_to_file_desired = 0
keep_alive = 0
virtual_private = 0x0
func = "main"

Build KLIPS for linux-4.1

$make module

 Building module for a 2.6 kernel
make[1]: Entering directory `/usr/src/slapt-src/libreswan/libreswan'
make[2]: Entering directory `/usr/src/slapt-src/libreswan/libreswan'
make[2]: `/usr/src/slapt-src/libreswan/libreswan/modobj/Makefile' is up to date.
make[2]: Leaving directory `/usr/src/slapt-src/libreswan/libreswan'
make -C /lib/modules/4.1.6/build  BUILDDIR=/usr/src/slapt-src/libreswan/libreswan/modobj SUBDIRS=/usr/src/slapt-src/libreswan/libreswan/modobj MODULE_DEF_INCLUDE=/usr/src/slapt-src/libreswan/libreswan/packaging/linus/config-all.h MODULE_DEFCONFIG=/usr/src/slapt-src/libreswan/libreswan/linux/net/ipsec/defconfig  MODULE_EXTRA_INCLUDE= ARCH=x86_64 V= modules
make[2]: Entering directory `/usr/src/linux-4.1.6'
  CC [M]  /usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.o
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c: In function ‘klips_rebuild_header’:
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:354:26: error: ‘const struct header_ops’ has no member named ‘rebuild’
      prv->dev->header_ops->rebuild == NULL) {
                          ^
In file included from /usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:36:0:
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:360:28: error: ‘const struct header_ops’ has no member named ‘rebuild’
        prv->dev->header_ops->rebuild : 0);
                            ^
/usr/src/slapt-src/libreswan/libreswan/linux/include/libreswan/ipsec_param.h:164:40: note: in definition of macro ‘KLIPS_PRINT’
  ((flag) ? printk(KERN_INFO format, ## args) : 0)
                                        ^
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:376:28: error: ‘const struct header_ops’ has no member named ‘rebuild’
  ret = prv->dev->header_ops->rebuild(skb);
                            ^
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c: At top level:
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:479:2: error: unknown field ‘rebuild’ specified in initializer
  .rebuild        = klips_rebuild_header,
  ^
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:479:2: warning: initialization from incompatible pointer type
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:479:2: warning: (near initialization for ‘klips_header_ops.cache’)
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c: In function ‘ipsec_tunnel_rebuild_header’:
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:1226:22: error: ‘const struct header_ops’ has no member named ‘rebuild’
  if (!prv->header_ops->rebuild)
                      ^
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:1255:23: error: ‘const struct header_ops’ has no member named ‘rebuild’
  ret = prv->header_ops->rebuild(skb);
                       ^
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c: At top level:
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:1374:2: error: unknown field ‘rebuild’ specified in initializer
  .rebuild        = ipsec_tunnel_rebuild_header,
  ^
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:1374:2: warning: initialization from incompatible pointer type
/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.c:1374:2: warning: (near initialization for ‘ipsec_tunnel_header_ops.parse’)
make[3]: *** [/usr/src/slapt-src/libreswan/libreswan/modobj/ipsec_tunnel.o] Error 1
make[2]: *** [_module_/usr/src/slapt-src/libreswan/libreswan/modobj] Error 2
make[2]: Leaving directory `/usr/src/linux-4.1.6'
make[1]: *** [module26] Error 2
make[1]: Leaving directory `/usr/src/slapt-src/libreswan/libreswan'
make: *** [module] Error 2

Add libgmp3-dev to dependencies list

Looks like libgmp3 is now a dependency; it should be added to the package install commands in your README.md.

opportunistic IPSec doesn't seem to work

I've installed libreswan 3.18 and am trying to follow the instructions at https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec from a machine that has a public IP address and is not behind a NAT.

After copying oe-upgrade-authnull.conf into /etc/ipsec.d/, i tried:

0 root@machine:~# systemctl restart ipsec
0 root@machine:~# ipsec whack --trafficstatus
000  
000  
0 root@machine:~# ping -c2 oe.libreswan.org
PING oe.libreswan.org (193.110.157.124) 56(84) bytes of data.
64 bytes from oe.libreswan.org (193.110.157.124): icmp_seq=1 ttl=48 time=98.0 ms
64 bytes from oe.libreswan.org (193.110.157.124): icmp_seq=2 ttl=48 time=98.4 ms

--- oe.libreswan.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 98.042/98.246/98.451/0.374 ms
0 root@machine:~# ipsec whack --trafficstatus
000  
0 root@machine:~#

It's not clear to me what i should expect to see, but it doesn't look to me like anything useful is happening there. Maybe the documentation is out of date? or maybe the test server is down? or maybe there's a step that's missing? I don't know how to debug.

Build instructions for OSX

Sorry if I have missed some docs, but I really couldn't find any instructions on how to build libreswan on OSX. I've tried to install the missing header files via brew (nss, pkg-config, nspr, unbound, gmp). As well as manually copy tcpd.h to /usr/include. However, I'm stuck on the error "pfkey.c:38:10: fatal error: 'netkey/key_var.h' file not found". I'm running OSX 10.10.2 (14C94b).

Thanks for the great work on openswan/libreswan. It's working great! But would llike to get this running on OSX too :)

upload deb-packages for actual Ubuntu to download.libreswan.org

Now latest supported Ubuntu version is 15.04, but actual LTS is 16.04 and there is no deb packages for that.

Pluto crashed/restarted by remote side during connection termination (IKEv2). Affected version: >= 3.15

If remote side send two (>=2) SA delete payload where IKE SA delete payload is last
pluto crashed.
Libreswan assumes that IKE SA delete payload can be the only one in message.
There are check about multiple delete payload which works when IKE SA is not last - in that case libreswan does not crash but return failure, but if IKE SA delete payload is last in list of payloads pluto crashed with abort.

It looks bad that remote side can crash the service via INVALID packet.
It seems assumption is wrong - RFCs (4306, 5996) does not state that IKE SA delete payload should be only payload in message, it allows multiple delete payloads for different type of SA's. https://tools.ietf.org/html/rfc5996#section-3.11 From RFC: It is permitted, however, to include multiple Delete payloads in a single INFORMATIONAL exchange where each Delete payload lists SPIs for a different protocol.

Part of debug log:
Jul 27 17:04:45: | Now let's proceed with payload (ISAKMP_NEXT_v2D)
Jul 27 17:04:45: | *_parse IKEv2 Delete Payload:
Jul 27 17:04:45: | next payload type: ISAKMP_NEXT_v2D (0x2a)
Jul 27 17:04:45: | flags: none (0x0)
Jul 27 17:04:45: | length: 12 (0xc)
Jul 27 17:04:45: | protocol ID: PROTO_IPSEC_ESP (0x3)
Jul 27 17:04:45: | SPI size: 4 (0x4)
Jul 27 17:04:45: | number of SPIs: 1 (0x1)
Jul 27 17:04:45: | processing payload: ISAKMP_NEXT_v2D (len=12)
Jul 27 17:04:45: | Now let's proceed with payload (ISAKMP_NEXT_v2D)
Jul 27 17:04:45: | *_parse IKEv2 Delete Payload:
Jul 27 17:04:45: | next payload type: ISAKMP_NEXT_v2NONE (0x0)
Jul 27 17:04:45: | flags: none (0x0)
Jul 27 17:04:45: | length: 8 (0x8)
Jul 27 17:04:45: | protocol ID: PROTO_ISAKMP (0x1)
Jul 27 17:04:45: | SPI size: 0 (0x0)
Jul 27 17:04:45: | number of SPIs: 0 (0x0)
Jul 27 17:04:45: | processing payload: ISAKMP_NEXT_v2D (len=8)
...
Jul 27 17:04:45: "enb" #1: ASSERTION FAILED at /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c:4083: p == md->ch
ain[ISAKMP_NEXT_v2D]

Code:
programs/pluto/ikev2_parent.c:process_encrypted_informational_ikev2

...
                        switch (v2del->isad_protoid) {
                        case PROTO_ISAKMP:
                                /*
                                 * There can be only one Delete Payload
                                 * if it is ISAKMP
                                 */
                                passert(p == md->chain[ISAKMP_NEXT_v2D]);
                                break;
...

SAref patches for 2.6.32 CentOS 6.4

I'm trying to setup CentOS 6.4 with SAref support, but there are some problems.

I'm trying to build a kernel linux-2.6.32-358.2.1.el6.centos.plus with:
0001-SAREF-add-support-for-SA-selection-through-sendmsg.patch
0002-SAREF-implement-IP_IPSEC_BINDREF.patch

$ cd linux-2.6.32-358.2.1
$ patch -p1 < ../../libreswan-3.1/patches/kernel/2.6.32/0001-SAREF-add-support-for-SA-selection-through-sendmsg.patch 
patching file include/linux/in.h
patching file include/net/ip.h
patching file include/net/xfrm.h
Hunk #1 succeeded at 918 (offset 11 lines).
patching file net/ipv4/Kconfig
Hunk #1 succeeded at 411 (offset 14 lines).
patching file net/ipv4/icmp.c
Hunk #1 succeeded at 363 (offset 1 line).
Hunk #2 succeeded at 426 (offset 1 line).
patching file net/ipv4/ip_output.c
Hunk #2 succeeded at 427 (offset 16 lines).
Hunk #3 succeeded at 924 (offset -31 lines).
Hunk #4 succeeded at 1468 (offset 95 lines).
patching file net/ipv4/ip_sockglue.c
Hunk #5 succeeded at 539 (offset 6 lines).
Hunk #6 succeeded at 640 (offset 9 lines).
Hunk #7 succeeded at 1074 (offset 22 lines).
Hunk #8 succeeded at 1106 (offset 22 lines).
Hunk #9 succeeded at 1191 (offset 25 lines).
patching file net/ipv4/raw.c
Hunk #1 succeeded at 461 with fuzz 2 (offset 1 line).
patching file net/ipv4/udp.c
Hunk #1 succeeded at 614 with fuzz 2 (offset 21 lines).
Hunk #2 succeeded at 814 (offset 43 lines).

$ patch -p1 < ../../libreswan-3.1/patches/kernel/2.6.32/0002-SAREF-implement-IP_IPSEC_BINDREF.patch 
patching file include/linux/in.h
patching file include/net/sock.h
Hunk #1 FAILED at 293.
1 out of 1 hunk FAILED -- saving rejects to file include/net/sock.h.rej
patching file include/net/xfrm.h
Hunk #1 succeeded at 962 (offset 11 lines).
patching file net/core/sock.c
Hunk #1 succeeded at 1475 with fuzz 1 (offset 67 lines).
patching file net/ipv4/ip_sockglue.c
Hunk #1 succeeded at 542 (offset 6 lines).
Hunk #2 succeeded at 648 (offset 9 lines).
Hunk #3 succeeded at 1080 (offset 22 lines).
Hunk #4 succeeded at 1113 (offset 22 lines).
Hunk #5 succeeded at 1201 (offset 25 lines).
patching file net/ipv4/tcp.c
Hunk #1 succeeded at 688 (offset 3 lines).
patching file net/ipv4/tcp_output.c
Hunk #2 succeeded at 646 (offset 5 lines).
Hunk #3 succeeded at 2398 (offset 19 lines).

The second (0002) patch is not applied correctly.

Here's a fix for it:

--- a/patches/kernel/2.6.32/0002-SAREF-implement-IP_IPSEC_BINDREF.patch
+++ b/patches/kernel/2.6.32/0002-SAREF-implement-IP_IPSEC_BINDREF.patch
@@ -32,12 +32,12 @@ diff --git a/include/net/sock.h b/include/net/sock.h
 index 9f96394..19e9caf 100644
 --- a/include/net/sock.h
 +++ b/include/net/sock.h
-@@ -293,7 +293,7 @@ struct sock {
+@@ -293,6 +293,7 @@ struct sock {
        void                    *sk_security;
  #endif
        __u32                   sk_mark;
--      /* XXX 4 bytes hole on 64 bit */
 +      __u32                   sk_saref;
+       u32                     sk_classid;
        void                    (*sk_state_change)(struct sock *sk);
        void                    (*sk_data_ready)(struct sock *sk, int bytes);
        void                    (*sk_write_space)(struct sock *sk);

474f26897 broke the build for pre-3.5.0 kernels

The CONFIG_USER_NS compilation option goes back at least as far as the 2.6 kernel series. However the kuid_t type and from_kuid function were only added in 3.5.0. This problem was mentioned in issue #11.

diff --git a/linux/include/libreswan/ipsec_kversion.h b/linux/include/libreswan/ipsec_kversion.h
index 2854a11..8bd9bf7 100644
--- a/linux/include/libreswan/ipsec_kversion.h
+++ b/linux/include/libreswan/ipsec_kversion.h
@@ -517,8 +517,10 @@
#endif

/* CONFIG_USER_NS is now on in Fedora 20 kernels */
-#if defined(CONFIG_USER_NS)
-# define HAVE_USER_NS
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 5, 0)
+# if defined(CONFIG_USER_NS)
+# define HAVE_USER_NS
+# endif
#endif

#endif /* _LIBRESWAN_KVERSIONS_H */

reapchild failed with errno=10 No child processes

When started under systemd, pluto produces this output in the journal:

Aug 07 23:37:23 machine pluto[7748]: reapchild failed with errno=10 No child processes

presumably something is calling reapchild when it shouldn't be called

prcpucfg.h: No such file or directory compilation terminated

Hi,

I'm on ubuntu 12.04 and I'm getting this error. Any idea?

Thank you

In file included from /opt/src/libreswan-3.17/lib/libswan/alg_info.c:34:0: /opt/src/libreswan-3.17/include/constants.h:107:45: fatal error: prcpucfg.h: No such file or directory compilation terminated. make[3]: *** [alg_info.o] Error 1 make[3]: Leaving directory/opt/src/libreswan-3.17/OBJ.linux.x86_64/lib/libswan'
make[2]: *** [local-base] Error 2
make[2]: Leaving directory /opt/src/libreswan-3.17/lib/libswan' make[1]: *** [all] Error 2 make[1]: Leaving directory/opt/src/libreswan-3.17/lib'
make: *** [all] Error 2

Error when Make Program

sr/local/lib/libevent_pthreads.so: undefined reference to event_mm_malloc_' /usr/local/lib/libevent_pthreads.so: undefined reference toevent_mm_free_'
/usr/local/lib/libevent_pthreads.so: undefined reference to evthread_set_id_callback' /usr/local/lib/libevent_pthreads.so: undefined reference toevthread_set_lock_callbacks'
collect2: ld returned 1 exit status
make[3]: *** [pluto] Error 1
make[3]: Leaving directory /root/libreswan/OBJ.linux.x86_64/programs/pluto' make[2]: *** [local-base] Error 2 make[2]: Leaving directory/root/libreswan/programs/pluto'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/libreswan/programs'
make: *** [all] Error 2

Mac OS IKEv2 missing payload(s) (ISAKMP_NEXT_v2AUTH)

Hi,

I am trying to configure Mac OS IKEv2 with libreswan (v3.13 or v3.16) using X.509 certificates on both sides.
After adding ike=3des-sha1;modp1024 to v3.16 config (apparently the default has changed) and using Remote ID (the CN of server cert) and Local ID (the CN of client cert) I could get as far as server sending cert and client sending it's own cert back in the response. Server than says missing payload(s) (ISAKMP_NEXT_v2AUTH):

Feb 22 16:12:42 dublin.dev.router pluto[5691]: | keysize is NOT required - NOT sent key length attribute
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | going to send a certreq
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | #3 complete v2 state transition from STATE_PARENT_R1 with STF_OK
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | transition from state STATE_IKEv2_BASE to state STATE_PARENT_R1
Feb 22 16:12:42 dublin.dev.router pluto[5691]: "RoadWarrior-IKEv2"[2] 89.100.95.78 #3: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=sha group=MODP1024}
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | sending V2 reply packet to 89.100.95.78:500 (from port 500)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | sending 297 bytes for STATE_IKEv2_BASE through eth0:500 to 89.100.95.78:500 (using #3)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | inserting event EVENT_v2_RESPONDER_TIMEOUT, timeout in 200.000000 seconds for #3
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | *received 364 bytes from 89.100.95.78:4500 on eth0 (port=4500)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse ISAKMP Message:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    initiator cookie:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   52 7c 82 69  58 e1 5c ca
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    responder cookie:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   c8 2c 93 b8  13 3a 31 95
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2SK (0x2e)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    ISAKMP version: IKEv2 version 2.0 (rfc4306/rfc5996) (0x20)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    exchange type: ISAKMP_v2_AUTH (0x23)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: ISAKMP_FLAG_v2_IKE_INIT (0x8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    message ID:  00 00 00 01
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 364 (0x16c)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |  processing version=2.0 packet with exchange type=ISAKMP_v2_AUTH (35)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | I am receiving an IKE Request
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | I am the IKE SA Original Responder
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | finding hash chain in state hash table
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   ICOOKIE:  52 7c 82 69  58 e1 5c ca
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   RCOOKIE:  c8 2c 93 b8  13 3a 31 95
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | found hash chain 4
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | parent v2 peer and cookies match on #3
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | v2 state object #3 found, in STATE_PARENT_R1
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | found state #3
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | from_state is STATE_PARENT_R1
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Unpacking clear payload for svm: respond to IKE_AUTH
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2SK)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | ***parse IKEv2 Encryption Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2IDi (0x23)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 336 (0x150)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2SK (len=336)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | selected state microcode respond to IKE_AUTH
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing connection "RoadWarrior-IKEv2"[2] 89.100.95.78
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now lets proceed with state specific processing
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | calling processor respond to IKE_AUTH
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing connection "RoadWarrior-IKEv2"[2] 89.100.95.78
Feb 22 16:12:42 dublin.dev.router pluto[5691]: "RoadWarrior-IKEv2"[2] 89.100.95.78 #3: new NAT mapping for #3, was 89.100.95.78:500, now 89.100.95.78:4500
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing connection "RoadWarrior-IKEv2"[2] 89.100.95.78
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | crypto helper 0: pcw_work: 0
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | asking crypto helper 0 to do compute dh (V2); request ID 12 (len=2776, pcw_work=0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | crypto helper 0 read fd: 11
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | crypto helper 0 doing compute dh (V2); request ID 12
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | crypto helper 0 finished compute dh (V2)OAKLEY_GROUP_MODP1024; request ID 12 time elapsed 1307 usec
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | inserting event EVENT_CRYPTO_FAILED, timeout in 60.000000 seconds for #3
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | complete v2 state transition with STF_SUSPEND
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | crypto helper 0 has finished work (pcw_work now 1)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | crypto helper 0 replies to request ID 12
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | calling continuation function 0x7f6b0c4e8610
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | ikev2_parent_inI2outR2_continue for #3: calculating g^{xy}, sending R2
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing connection "RoadWarrior-IKEv2"[2] 89.100.95.78
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  52 7c 82 69  58 e1 5c ca  c8 2c 93 b8  13 3a 31 95
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  2e 20 23 08  00 00 00 01  00 00 01 6c  23 00 01 50
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  bf 4e 9a eb  a5 98 71 05  6a e9 a8 dd  b3 ee 81 60
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  cb 1c 85 46  03 81 53 2b  85 17 93 6b  15 07 2a fb
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  33 51 ad 71  7c 76 a2 6d  e6 44 d0 7e  6b 97 24 79
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  ab f8 0a 3f  6c 88 6f d3  53 e9 60 12  22 98 d8 98
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  a2 92 75 b7  37 b5 a7 74  9c 85 eb 73  80 f6 d7 ae
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  c3 b1 cf 14  fd 3d 89 e5  43 c9 79 d1  19 de f3 54
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  d6 a9 38 c2  ca 85 e4 f7  da e7 a4 f0  c2 b7 ff 29
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  7d 02 8d 53  d4 c1 23 dc  47 6b bc 0d  2f 09 a0 e4
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  12 c3 bb e4  9f 53 3a d7  ba e0 42 4f  f6 46 a0 13
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  78 9c 15 b2  35 8c d9 d2  d3 bf 74 56  28 6a 75 2e
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  94 ab 93 71  61 31 60 42  da 57 81 02  31 a2 56 bd
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  34 ae 4e 99  6b ce 72 21  70 e6 e1 d5  2e 2d bd a6
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  9f c2 c8 44  1e 2c 75 86  45 f4 ef b0  3c 0c 57 3f
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  d7 08 dd a4  20 b6 b1 07  20 6b 55 f1  e9 c2 f7 0e
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  15 b4 0d 23  db a7 63 b2  96 19 d7 98  cc 03 47 ff
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  c2 8d 77 19  f5 9f 71 f6  5b e4 3f 71  fa c1 42 5f
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  6c fd 3e 6d  58 cb 29 70  81 d0 c0 c7  da 03 06 a9
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  e3 77 78 f6  48 a7 86 cf  12 82 40 5c  cf 1e 8b c8
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  29 39 c1 66  ab 5e ea 30  79 2e af 8c  bd 1a 39 d9
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | data for hmac:  c1 cc 98 80  cd 0b 54 f5  89 7f ec 15  b8 0d 04 29
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | calculated auth:  f3 0f 49 7d  10 10 79 cd  78 71 c2 20
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |   provided auth:  f3 0f 49 7d  10 10 79 cd  78 71 c2 20
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | authenticator matched
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2IDi)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Identification Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 33 (0x21)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    id_type: ID_USER_FQDN (0x3)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2IDi (len=33)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_INITIAL_CONTACT (0x4000)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2IDr (0x24)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_MOBIKE_SUPPORTED (0x400c)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2IDr)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Identification Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2CP (0x2f)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 37 (0x25)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    id_type: ID_FQDN (0x2)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2IDr (len=37)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2CP)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Configuration Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 36 (0x24)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    ikev2_cfg_type: IKEv2_CP_CFG_REQUEST (0x1)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2CP (len=36)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2N (0x29)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_ESP_TFC_PADDING_NOT_SUPPORTED (0x400a)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2N)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Notify Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2SA (0x21)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 8 (0x8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Protocol ID: PROTO_RESERVED (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    SPI size: 0 (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    Notify Message Type: v2N_NON_FIRST_FRAGMENTS_ALSO (0x400b)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2N (len=8)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2SA)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Security Association Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2TSi (0x2c)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 40 (0x28)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2SA (len=40)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2TSi)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Traffic Selector Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2TSr (0x2d)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 64 (0x40)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    number of TS: 2 (0x2)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2TSi (len=64)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | Now let's proceed with payload (ISAKMP_NEXT_v2TSr)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | **parse IKEv2 Traffic Selector Payload:
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    next payload type: ISAKMP_NEXT_v2NONE (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    flags: none (0x0)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    length: 64 (0x40)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: |    number of TS: 2 (0x2)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | processing payload: ISAKMP_NEXT_v2TSr (len=64)
Feb 22 16:12:42 dublin.dev.router pluto[5691]: "RoadWarrior-IKEv2"[2] 89.100.95.78 #3: missing payload(s) (ISAKMP_NEXT_v2AUTH). Message dropped.
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | ikev2_parent_inI2outR2_tail returned STF_FAIL with v2N_INVALID_SYNTAX
Feb 22 16:12:42 dublin.dev.router pluto[5691]: | #3 complete v2 state transition from STATE_PARENT_R1 with v2N_INVALID_SYNTAX

and after few retries fails. I don't know how to debug it on Mac OS since logs are no longer written to racoon.log.

Is this supposed to work or am I missing something in my setup?
The Mac OS is at latest update.

My configuration is as follows (note that IKEv1/L2TP works); both ends are NAT'ed (AWS/EC2):

conn %default
    # This may come handy if fragmented IP packets are dropped or DF'ed
    ike_frag=yes

    # x509
    authby=rsasig
    leftcert="dublin.dev.vpn.example.com - example.com"
    leftsendcert=always
    leftid=%fromcert
    rightid=%fromcert

    # Perfect Forward Secrecy - off since M$ and Apple have it disabled by default, wonder why...
    pfs=no
    # we cannot rekey for %any, let client rekey
    rekey=no

    # Timeouts
    ## Set ikelifetime and keylife to same defaults windows has
    ikelifetime=8h
    keylife=1h
    rekeymargin=3m
    keyingtries=3

    # Dead node detection
    dpddelay=4
    dpdtimeout=30
    dpdaction=clear

    # ID
    left=%eth0
    right=%any

    # listen for auto keying connections
    auto=add

conn RoadWarrior-IKEv2
    ikev2=insist
    ike=3des-sha1;modp1024
    rightaddresspool=10.224.1.97-10.224.1.128
    # Subnet that is accessible for the client (NOTE: leftsubnets= does not work with rightaddresspool...)
    leftsubnet=10.0.0.0/8

conn RoadWarrior-IKEv1-L2TP
    ikev2=no
    leftprotoport=udp/l2tp
    rightprotoport=udp/%any

conn v6neighbor-hole-in
    left=::1
    leftsubnet=::0/0
    leftprotoport=58/34560
    rightprotoport=58/34816
    rightsubnet=::0/0
    right=::0
    connaddrfamily=ipv6
    authby=never
    type=passthrough
    auto=route
    priority=1

conn v6neighbor-hole-out
    left=::1
    leftsubnet=::0/0
    leftprotoport=58/34816
    rightprotoport=58/34560
    rightsubnet=::0/0
    right=::0
    connaddrfamily=ipv6
    authby=never
    type=passthrough
    auto=route
    priority=1

Thank you.

Libreswan 3.16 crash

Hi,

This is in relation to crasher I have reported with #48.
I have managed to get a core dump and gdb bt for it with debug symbols.

I don't know how to reproduce the crash but it happens once/twice a day.
I have 3-4 clients using the VPN in road warrior style. They would be using IKEv2/LT2P mostly.

I am running this configuration:

version 2.0

config setup
    # none all raw crypt parsing emitting control lifecycle kernel pfkey nat-t dpd dns oppo oppoinfo whackwatch private x509
    #plutodebug="control parsing x509"
    plutodebug="none"
    nat_traversal=yes
    uniqueids=no
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10

conn %default
    # This may come handy if fragmented IP packets are dropped or DF'ed
    ike_frag=yes

    # x509
    authby=rsasig
    leftcert="example.com - example.com"
    leftsendcert=always
    leftid=%fromcert
    rightid=%fromcert

    pfs=no
    # we cannot rekey for %any, let client rekey
    rekey=no

    # Timeouts
    ## Set ikelifetime and keylife to same defaults windows has
    ikelifetime=8h
    keylife=1h
    rekeymargin=3m
    keyingtries=3

    # Dead node detection
    dpddelay=4
    dpdtimeout=30
    dpdaction=clear

    # ID
    left=%eth0
    right=%any

    # listen for auto keying connections
    auto=add

conn RoadWarrior-IKEv1-L2TP
    ikev2=no
    leftprotoport=udp/l2tp
    rightprotoport=udp/%any

conn RoadWarrior-IKEv2
    ikev2=insist
    rightaddresspool=10.224.1.97-10.224.1.128
    # Changed default in libreswan 3.16
    ike=3des-sha1;modp1024
    # Subnet that is accessible for the client (NOTE: leftsubnets= does not work with rightaddresspool...)
    leftsubnet=10.0.0.0/8
    # See: https://github.com/libreswan/libreswan/issues/47
    rightid=%myid
    forceencaps=yes

Linux 3.4.43-43.43.amzn1.x86_64 (AWS/EC2)

Here is some gdb output; please let me know if you need more output from gdb:

(gdb) bt full
#0  fiddle_bare_shunt (src=src@entry=0x7fbc74c0e018, dst=dst@entry=0x7fbc74c0e038, policy_prio=policy_prio@entry=0, cur_shunt_spi=259, new_shunt_spi=new_shunt_spi@entry=256, repl=repl@entry=0, transport_proto=6,
    why=why@entry=0x7fbc73c557db "expire_bare_shunt") at /usr/src/debug/libreswan-3.16/programs/pluto/kernel.c:1259
        this_client = {addr = {u = {v4 = {sin_family = 2, sin_port = 5632, sin_addr = {s_addr = 2214658314}, sin_zero = "\000\000\000\000\000\000\000"}, v6 = {sin6_family = 2, sin6_port = 5632, sin6_flowinfo = 2214658314, sin6_addr = {
                  __in6_u = {__u6_addr8 = "\000\000\000\000\000\000\000\000!\231\306s\274\177\000", __u6_addr16 = {0, 0, 0, 0, 39201, 29638, 32700, 0}, __u6_addr32 = {0, 0, 1942395169, 32700}}}, sin6_scope_id = 1958595427}}},
          maskbits = 32}
        that_client = {addr = {u = {v4 = {sin_family = 2, sin_port = 22989, sin_addr = {s_addr = 1644175626}, sin_zero = "\000\000\000\000\000\000\000"}, v6 = {sin6_family = 2, sin6_port = 22989, sin6_flowinfo = 1644175626, sin6_addr = {
                  __in6_u = {__u6_addr8 = "\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000", __u6_addr16 = {0, 0, 0, 0, 1, 0, 0, 0}, __u6_addr32 = {0, 0, 1, 0}}}, sin6_scope_id = 1958049872}}}, maskbits = 32}
        null_host = <optimized out>
#1  0x00007fbc73bee3b6 in delete_bare_shunt (why=0x7fbc73c557db "expire_bare_shunt", cur_shunt_spi=<optimized out>, transport_proto=<optimized out>, dst=0x7fbc74c0e038, src=0x7fbc74c0e018)
    at /usr/src/debug/libreswan-3.16/programs/pluto/kernel.c:1366
No locals.
#2  expire_bare_shunts () at /usr/src/debug/libreswan-3.16/programs/pluto/kernel.c:3490
        bsp = 0x7fbc74c0e010
        age = <optimized out>
        bspp = 0x7fbc74c0f0f8
#3  0x00007fbc73bbfe75 in timer_event_cb (fd=<optimized out>, event=<optimized out>, arg=0x7fbc74b764e0) at /usr/src/debug/libreswan-3.16/programs/pluto/timer.c:589
        ev = 0x7fbc74b764e0
        type = EVENT_SHUNT_SCAN
        st = 0x0
        statenum = "X\303\363\006\377\177\000\000\001\230\265t\274\177\000\000\340h\264t\274\177\000\000 \002\264t\274\177\000\000\001\000\000\000\000\000\000\000I\273Lr\274\177\000\000\003\000\000\000\274\177\000\000\000 \000\000\000\000\000"
#4  0x00007fbc724cca3c in event_add () from /usr/lib64/libevent-2.0.so.5
No symbol table info available.
#5  0x00000000000e5f40 in ?? ()
No symbol table info available.
#6  0x00007fbc74b49f50 in ?? ()
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

(gdb) frame 0
#0  fiddle_bare_shunt (src=src@entry=0x7fbc74c0e018, dst=dst@entry=0x7fbc74c0e038, policy_prio=policy_prio@entry=0, cur_shunt_spi=259, new_shunt_spi=new_shunt_spi@entry=256, repl=repl@entry=0, transport_proto=6,
    why=why@entry=0x7fbc73c557db "expire_bare_shunt") at /usr/src/debug/libreswan-3.16/programs/pluto/kernel.c:1259
1259        const ip_address *null_host = aftoinfo(addrtypeof(src))->any;

Regards,
Jakub

How enable Klips for Openswan in Centos7

Hi. Please, help configure openswan with support klips in Centos7. In Default Openswan use Netkey, but it's not work for users in one network behind NAT to one enternal ip and need prostack=klips.
I have:
Linux 3.10.0-229.1.2.el7.x86_64
Linux Libreswan 3.12 (netkey)

Sorry for my English

Python error in ipsec verify

I have installed libreswan-3.17-1.fc23.x86_64,

And it outputs:

Pluto ipsec.secret syntax                        Traceback (most recent call last):
  File "/usr/libexec/ipsec/verify", line 477, in <module>
    main()
  File "/usr/libexec/ipsec/verify", line 466, in main
    plutocheck()
  File "/usr/libexec/ipsec/verify", line 121, in plutocheck
    ipsecsecretcheck()
  File "/usr/libexec/ipsec/verify", line 375, in ipsecsecretcheck
    output = output.decode(prefencoding)
AttributeError: 'str' object has no attribute 'decode'

Python version is Python 3.4.3

Is this a bug? if it is not how can I fix it?

Thanks in advance

"ipsec whack --oppohere" doesn't accept IPv6 addresses

debugging today on #swan, @letoams suggested that i run:

ipsec whack --oppohere $YOURIPv6 --oppothere 2a03:6000:1004:1::124

when i put my actual IPv6 address in for $YOURIPv6, i got:

whack error: IPv4 address may not contain `:' "bae:bae::1234"

Build on raspberry pi fails

When trying to compile the programm from source, I get this error on ARM

`cc -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-all -fno-strict-aliasing -fPIE -DPIE -DFORCE_PR_ASSERT -DDNSSEC -DKLIPS -DLIBCURL -DUSE_MD5 -DHAVE_NM -DUSE_SHA2 -DUSE_SHA1 -DFIPSPRODUCTCHECK="/etc/system-fips" -DIPSEC_CONF="/etc/ipsec.conf" -DIPSEC_CONFDDIR="/etc/ipsec.d" -DIPSEC_NSSDIR="/etc/ipsec.d" -DIPSEC_CONFDIR="/etc" -DIPSEC_EXECDIR="/usr/local/libexec/ipsec" -DIPSEC_SBINDIR="/usr/local/sbin" -DIPSEC_VARDIR="/var" -DPOLICYGROUPSDIR="/etc/ipsec.d/policies" -DSHARED_SECRETS_FILE="/etc/ipsec.secrets" -DRETRANSMIT_INTERVAL_DEFAULT="500" -DGCC_LINT -DALLOW_MICROSOFT_BAD_PROPOSAL -Werror -Wall -Wextra -Wformat -Wformat-nonliteral -Wformat-security -Wundef -Wmissing-declarations -Wredundant-decls -Wnested-externs -I/root/libreswan-3.16/ports/linux/include -I/root/libreswan-3.16/ports/linux/include -I/root/libreswan-3.16/ports/linux/include -I/root/libreswan-3.16/ports/linux/include -I/root/libreswan-3.16/programs/pluto/linux26 -I/root/libreswan-3.16/include -I/root/libreswan-3.16/lib/libcrypto -I/root/libreswan-3.16/linux/include -DNETKEY_SUPPORT -DKERNEL26_HAS_KAME_DUPLICATES -DPFKEY -DUSE_TWOFISH -DUSE_SERPENT -DKLIPS -DPFKEY -DUSE_AES -DUSE_3DES -DUSE_SHA2 -DUSE_SHA1 -DUSE_MD5 -DUSE_CAMELLIA -DXAUTH_HAVE_PAM -DLIBCURL -DHAVE_LIBCAP_NG -DHAVE_NM -I/usr/include/nss -I/usr/include/nspr \

    -MMD -MF ./crypt_dbg.d \

    -o ./crypt_dbg.o \

    -c /root/libreswan-3.16/programs/pluto/crypt_dbg.c

/root/libreswan-3.16/programs/pluto/crypt_dbg.c: In function ‘symkey_bytes’:

/root/libreswan-3.16/programs/pluto/crypt_dbg.c:102:2: error: implicit declaration of function ‘PK11_Decrypt’ [-Werror=implicit-function-declaration]

/root/libreswan-3.16/programs/pluto/crypt_dbg.c:102:2: error: nested extern declaration of ‘PK11_Decrypt’ [-Werror=nested-externs]

cc1: all warnings being treated as errors

../../../mk/depend.mk:28: recipe for target 'crypt_dbg.o' failed

make[3]: *** [crypt_dbg.o] Error 1
make[3]: Leaving directory '/root/libreswan-3.16/OBJ.linux.arm/programs/pluto'
Makefile:426: recipe for target 'local-base' failed
make[2]: *** [local-base] Error 2
make[2]: Leaving directory '/root/libreswan-3.16/programs/pluto'
../mk/subdirs.mk:33: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/root/libreswan-3.16/programs'
/root/libreswan-3.16/mk/subdirs.mk:33: recipe for target 'all' failed
make: *** [all] Error 2
`

Support for PEM encoded RSA keys

Referring to #98 i am hereby kindly requesting to add support for PEM encoded RSA key pairs.

Thanks a lot
Sascha

Pluto high cpu load and lost of connectivity

libreswan-3.15-5.3.el6.x86_64 from centos 6 base repo.

Sometimes, averagely once per 2-3 weeks, ipsec connections stop to work (no pings). pluto loads cpu 100%.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                         
27000 root      20   0  627m  10m 5352 R 99.9  0.1 762:47.58 pluto

Strace shows infinite loop like this:

[pid 27000] recvfrom(25, "d\0\0\0\2\0\0\0e\2\375\373[\350\377\377\376\377\377\377P\0\0\0\24\0\5\0e\2\375\373"..., 8228, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 100
[pid 27000] write(25, "P\0\0\0\24\0\5\0f\2\375\373\0\0\0\0\302\276\337\260\0\0\0\0\0\0\0\0\0\0\0\0"..., 80) = 80
[pid 27000] recvfrom(25, "d\0\0\0\2\0\0\0f\2\375\373[\350\377\377\376\377\377\377P\0\0\0\24\0\5\0f\2\375\373"..., 8228, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 100
[pid 27000] write(25, "P\0\0\0\24\0\5\0g\2\375\373\0\0\0\0\302\276\337\260\0\0\0\0\0\0\0\0\0\0\0\0"..., 80) = 80

Run of ipsec status hangs too.

Some Windows cannot connect

Hello,

I've deployed a VPN L2TP connection into my workgroup

I use libreswan 3.12

Some windows can connect (log :

`Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: received Vendor ID payload [RFC 3947]
Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: received Vendor ID payload [FRAGMENTATION]
Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: ignoring Vendor ID payload [Vid-Initial-Contact]
Apr 12 12:09:52 DHCP pluto[3978]: packet from 83.196.64.203:500: ignoring Vendor ID payload [IKE CGA version 1]
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: responding to Main Mode from unknown peer 83.196.64.203
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: I am behind NAT+peer behind NAT
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.32'
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[7] 83.196.64.203 #12: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: deleting connection "L2TP-PSK-NAT" instance with peer 83.196.64.203 {isakmp=#0/ipsec=#0}
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: new NAT mapping for #12, was 83.196.64.203:500, now 83.196.64.203:4500
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP2048}
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: the peer proposed: 62.210.127.211/32:17/1701 -> 192.168.1.32/32:17/0
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #12: NAT-Traversal: received 2 NAT-OA. Using first, ignoring others
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13: responding to Quick Mode proposal {msgid:01000000}
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13:     us: 10.0.1.201<10.0.1.201>:17/1701
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13:   them: 83.196.64.203[192.168.1.32]:17/1701===192.168.1.32/32
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Apr 12 12:09:52 DHCP pluto[3978]: "L2TP-PSK-NAT"[8] 83.196.64.203 #13: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x289e709f <0x09af960a xfrm=AES_128-HMAC_SHA1 NATOA=192.168.1.32 NATD=83.196.64.203:4500 DPD=active}

but some cannot (same config)

Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: received Vendor ID payload [RFC 3947]
Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: received Vendor ID payload [FRAGMENTATION]
Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: ignoring Vendor ID payload [Vid-Initial-Contact]
Apr 12 12:11:11 DHCP pluto[3978]: packet from 83.196.64.203:6: ignoring Vendor ID payload [IKE CGA version 1]
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: responding to Main Mode from unknown peer 83.196.64.203
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 6: I am behind NAT+peer behind NAT
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Apr 12 12:11:11 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.4'
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[11] 83.196.64.203 #18: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: deleting connection "L2TP-PSK-NAT" instance with peer 83.196.64.203 {isakmp=#0/ipsec=#0}
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP2048}
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: the peer proposed: 62.210.127.211/32:17/1701 -> 192.168.1.4/32:17/0
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: NAT-Traversal: received 2 NAT-OA. Using first, ignoring others
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19: responding to Quick Mode proposal {msgid:01000000}
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19:     us: 10.0.1.201<10.0.1.201>:17/1701
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19:   them: 83.196.64.203[192.168.1.4]:17/1701===192.168.1.4/32
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #19: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x4150b2af <0x4cd35b43 xfrm=AES_128-HMAC_SHA1 NATOA=192.168.1.4 NATD=83.196.64.203:6 DPD=active}
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: the peer proposed: 62.210.127.211/32:17/1701 -> 192.168.1.4/32:17/1701
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: NAT-Traversal: received 2 NAT-OA. Using first, ignoring others
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: responding to Quick Mode proposal {msgid:02000000}
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20:     us: 10.0.1.201<10.0.1.201>:17/1701
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20:   them: 83.196.64.203[192.168.1.4]:17/1701===192.168.1.4/32
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: keeping refhim=4294901761 during rekey
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #20: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x3c9d8457 <0xd61ad1a0 xfrm=AES_128-HMAC_SHA1 NATOA=192.168.1.4 NATD=83.196.64.203:6 DPD=active}
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: received Delete SA(0x4150b2af) payload: deleting IPSEC State #19
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: ESP traffic information: in=0B out=0B
Apr 12 12:11:12 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: received and ignored empty informational notification payload
Apr 12 12:11:13 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: received Delete SA(0x3c9d8457) payload: deleting IPSEC State #20
Apr 12 12:11:13 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: ESP traffic information: in=0B out=0B
Apr 12 12:11:13 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: received and ignored empty informational notification payload
Apr 12 12:11:13 DHCP pluto[3978]: "L2TP-PSK-NAT"[12] 83.196.64.203 #18: received Delete SA payload: self-deleting ISAKMP State #18

"make install" should not try to fiddle with the running systemd when targeting a $DESTDIR

During a debian package build, "make install" gets run targeting a $DESTDIR. however, initsystems/systemd/Makefile thinks that running make install means it's a good idea to try to talk to the local systemd services. This isn't a good idea, and the scripts embedded in the makefile don't cope with failures too cleanly either:

make[4]: Entering directory '/home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/initsystems/systemd'
install --mode=0644 ipsec.service /home/dkg/src/libreswan/libreswan/debian/libreswan//lib/systemd/system
Failed to get unit file state for ipsec.service: Connection reset by peer
Failed to retrieve unit: Connection reset by peer
Failed to retrieve unit: Connection reset by peer
/bin/bash: line 0: test: too many arguments
/bin/bash: line 6: test: =: unary operator expected
/bin/bash: line 10: test: =: unary operator expected
make[4]: Leaving directory '/home/dkg/src/libreswan/libreswan/OBJ.linux.x86_64/initsystems/systemd'

I think systemctl is-enabled ipsec.service and systemctl is-active ipsec.service are both failing and producing no output to stdout.

Is there a recommended way to avoid having make install try to do anything with the local systemd instance?

Supported features link leads to blank page

On the main site (https://libreswan.org/) the link to "Supported Features" leads to wiki page (https://libreswan.org/wiki/Features) that is empty

Weird connectivity issues, cannot connect until change LAN IP

I had a very weird issue with Libreswan 3.13(ipsec/l2tp, using pre-shared key and PAM authentication). Out of no where, suddenly a client will fail to connect, or disconnected(while connecting), if that client(Built in MAC OS 10.10.5 VPN client) try to connect again, they always get this generic error message:

The L2TP-VPN server did not respond. Try reconnecting. If the problem continues, verify your settings and contact your Administrator.

On server side, I see lots of this in /var/log/auth.log

37904 2015-08-20T04:26:26.904878+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: Main mode peer ID is ID_IPV4_ADDR: '10.0.1.7'

37905 2015-08-20T04:26:26.905007+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3

37906 2015-08-20T04:26:26.905016+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: new NAT mapping for #1026, was x.x.x.x:500, now x.x.x.x:32773

37907 2015-08-20T04:26:26.905046+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha gr oup=MODP1024}

37908 2015-08-20T04:26:26.905056+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: Dead Peer Detection (RFC 3706): enabled

37909 2015-08-20T04:26:27.791715+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: the peer proposed: 54.205.34.105/32:17/1701 -> 10.0.1.7/32:17/58409

37910 2015-08-20T04:26:27.791732+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: NAT-Traversal: received 2 NAT-OA. Using first, ignoring others

37911 2015-08-20T04:26:27.791784+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: responding to Quick Mode proposal {msgid:7bfc58a1}

37912 2015-08-20T04:26:27.791793+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: us: 10.142.233.238/32===10.142.233.238<10.142.233.238>[54.205.34.105]:17/1701

37913 2015-08-20T04:26:27.791799+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: them: x.x.x.x[10.0.1.7]:17/58409

37914 2015-08-20T04:26:27.792088+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1

37915 2015-08-20T04:26:27.792117+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2

37916 2015-08-20T04:26:27.904732+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: Dead Peer Detection (RFC 3706): enabled

37917 2015-08-20T04:26:27.905009+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2

37918 2015-08-20T04:26:27.905146+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1027: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x08fc7625 <0x99782ac9 xfrm=AES_ 256-HMAC_SHA1 NATOA=10.0.1.7 NATD=x.x.x.x:32773 DPD=active}

37919 2015-08-20T04:26:42.070695+00:00 localhost pluto[951]: packet from x.x.x.x:32773: ignoring informational payload INVALID_COOKIE, no corresponding state

37920 2015-08-20T04:26:42.070704+00:00 localhost pluto[951]: packet from x.x.x.x:32773: received and ignored informational message

37921 2015-08-20T04:26:47.905007+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: received Delete SA(0x08fc7625) payload: deleting IPSEC State #1027

37922 2015-08-20T04:26:47.905019+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: ESP traffic information: in=0B out=83B

37923 2015-08-20T04:26:47.911008+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: received and ignored empty informational notification payload

37924 2015-08-20T04:26:47.911188+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #1026: received Delete SA payload: self-deleting ISAKMP State #1026

37925 2015-08-20T04:26:47.911446+00:00 localhost pluto[951]: packet from x.x.x.x:32773: received and ignored empty informational notification payload

37931 2015-08-20T04:27:21.511007+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #994: IPsec SA expired (--dontrekey)

37932 2015-08-20T04:27:21.511017+00:00 localhost pluto[951]: "vpnpsk"[331] x.x.x.x #994: ESP traffic information: in=0B out=83B

37933 2015-08-20T04:27:41.949054+00:00 localhost pluto[951]: packet from x.x.x.x:32773: ignoring informational payload INVALID_COOKIE, no corresponding state

37934 2015-08-20T04:27:41.949062+00:00 localhost pluto[951]: packet from x.x.x.x:32773: received and ignored informational message

No matter how many times that person tries to re-connect, same messages show up both on client side and server side (/var/log/auth).

If that person tries to restart computer, they may eventually succeed to connect. If that person manually changes thier LAN IP address(eg change from 10.0.1.7 - > 10.0.1.12 in above example), they almost re-connect successfully(100% from my tests).

If I try to restart xl2tpd on server, the client can also connect/re-connect without changing their LAN IP.

When this happens, it affects that particular person, many other clients still succeed to connect to VPN.

Does anyone have any idea how to fix this?

Source doesn't compile in Debian "Wheezy"

Hi,

"make deb" (or "make programs") fails in Debian "Wheezy", with this message:

libreswan-master/programs/pluto/ike_alg.h:5:26: fatal error: nss3/pk11pub.h: No such file or directory

Creating a symbolic link "/usr/include/nss3" pointing to "/usr/include/nss" fixes it.

Libreswan 3.15 - Failed to compile

Operating System: CentOS 6.6
Kernel version: 2.6.32-504.30.3.el6.x86_64
LIbreswan version: 3.15

Compile error log:

root@server > make programs
... ...
In file included from /opt/src/libreswan-3.15/programs/pluto/demux.h:21,
                 from /opt/src/libreswan-3.15/programs/pluto/connections.c:60:
/opt/src/libreswan-3.15/programs/pluto/server.h:21:52: error: event2/event.h: No such file or directory
/opt/src/libreswan-3.15/programs/pluto/server.h:22:33: error: event2/event_struct.h: No such file or directory
In file included from /opt/src/libreswan-3.15/programs/pluto/demux.h:21,
                 from /opt/src/libreswan-3.15/programs/pluto/connections.c:60:
/opt/src/libreswan-3.15/programs/pluto/server.h:82: error: expected ‘)’ before ‘const’
/opt/src/libreswan-3.15/programs/pluto/server.h:83: error: expected ‘)’ before ‘ft’
In file included from /opt/src/libreswan-3.15/programs/pluto/connections.c:60:
/opt/src/libreswan-3.15/programs/pluto/demux.h:28: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘comm_handle_cb’
make[3]: *** [connections.o] Error 1
make[3]: Leaving directory `/opt/src/libreswan-3.15/OBJ.linux.x86_64/programs/pluto'
make[2]: *** [local-base] Error 2
make[2]: Leaving directory `/opt/src/libreswan-3.15/programs/pluto'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/src/libreswan-3.15/programs'
make: *** [all] Error 2

missing backslash at end of line

There is a missing backslash for line continuation at the end of line 40 of debian/rules:

         USE_LDAP=true

should be
USE_LDAP=true \

Libreswan 3.20 : make module fails with "implicit declaration of function" error on Debian 9

Hello,

Here is the errors displayed :
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c: In function 'setup_digest':
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:564:12: error: implicit declaration of function 'crypto_has_hash' [-Werror=implicit-function-declaration]
return crypto_has_hash(digestname, 0, 0);
^~~~~~~~~~~~~~~
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c: In function '_capi_hmac_new_key':
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:655:8: error: implicit declaration of function 'crypto_alloc_hash' [-Werror=implicit-function-declaration]
tfm = crypto_alloc_hash(dptr->digestname, 0, CRYPTO_ALG_ASYNC);
^~~~~~~~~~~~~~~~~
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:655:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
tfm = crypto_alloc_hash(dptr->digestname, 0, CRYPTO_ALG_ASYNC);
^
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:662:6: error: implicit declaration of function 'crypto_hash_setkey' [-Werror=implicit-function-declaration]
if (crypto_hash_setkey(tfm, key, keylen)<0)
^~~~~~~~~~~~~~~~~~
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:667:3: error: implicit declaration of function 'crypto_free_hash' [-Werror=implicit-function-declaration]
crypto_free_hash(tfm);
^~~~~~~~~~~~~~~~
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c: In function '_capi_hmac_hash':
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:687:19: error: storage size of 'desc' isn't known
struct hash_desc desc;
^~~~
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:710:8: error: implicit declaration of function 'crypto_hash_digest' [-Werror=implicit-function-declaration]
ret = crypto_hash_digest(&desc, &sg, len, hash_buf);
^~~~~~~~~~~~~~~~~~
/usr/src/libreswan-3.20/modobj/ipsec_alg_cryptoapi.c:687:19: warning: unused variable 'desc' [-Wunused-variable]
struct hash_desc desc;

Thanks for help
Francis

Strange behavior when Chromebook attempts to connect

Running ChromeOS 57 on a HP Chromebook 13 G1. When attempting to connect, I get the following in the log (using pastebin due to length): paste

To my untrained eyes, it seems like the connection is causing something to constantly restart? I am also using a Nexus 6P to connect to the same server, using the same credentials and have no issues connecting.

conn type=passthrough

test config:

conn passclear
    type=passthrough
    authby=never
    left=10.1.1.3
    leftnexthop=10.1.1.1
    leftsubnet=10.1.0.0/16
    right=10.2.1.2
    rightsubnet=10.1.0.0/16
    auto=route

conn ipsec-for-all
    type=tunnel
    authby=rsasig
    auth=esp
    leftrsasigkey=%cert
    pfs=yes
    rekey=yes
    left=10.1.1.3
    leftcert=test.cert
    leftnexthop=10.1.1.1
    right=10.2.1.2
    rightsubnet=10.0.0.0/8
    rightrsasigkey=%cert
    auto=start

In libreSwan 3.1 (OpenSwan 2.6.x) are following policies(ip xfrm policy):

src 10.1.1.3/32 dst 10.0.0.0/8 dir out priority 2104 tmpl src 10.1.1.3 dst 10.2.1.2 proto esp reqid 16389 mode tunnel
src 10.0.0.0/8 dst 10.1.1.3/32 dir fwd priority 2104 tmpl src 10.2.1.2 dst 10.1.1.3 proto esp reqid 16389 mode tunnel
src 10.0.0.0/8 dst 10.1.1.3/32 dir in priority 2104 tmpl src 10.2.1.2 dst 10.1.1.3 proto esp reqid 16389 mode tunnel
src 10.1.0.0/16 dst 10.1.0.0/16 dir fwd priority 2608
src 10.1.0.0/16 dst 10.1.0.0/16 dir in priority 2608
src 10.1.0.0/16 dst 10.1.0.0/16 dir out priority 2608

And on OpenSwan 2.4.x are following policies(ip xfrm policy):
src 10.1.1.3/32 dst 10.0.0.0/8 dir out priority 2104 tmpl src 10.1.1.3 dst 10.2.1.2 proto esp reqid 16389 mode tunnel
src 10.0.0.0/8 dst 10.1.1.3/32 dir fwd priority 2104 tmpl src 10.2.1.2 dst 10.1.1.3 proto esp reqid 16389 mode tunnel
src 10.0.0.0/8 dst 10.1.1.3/32 dir in priority 2104 tmpl src 10.2.1.2 dst 10.1.1.3 proto esp reqid 16389 mode tunnel
src 10.1.0.0/16 dst 10.1.1.3/32 dir fwd priority 1096
src 10.1.0.0/16 dst 10.1.1.3/32 dir in priority 1096
src 10.1.1.3/32 dst 10.1.0.0/16 dir out priority 1096

Apparently the problem in the priorities.

This is a bug in openswan #1131

Minor corrections for compiling in Debian Wheezy

Hi again,

sorry for not sending these in my previous issue. I've found a few minor bugs when building the deb package in Wheezy. Here's the patch, hope that it makes sense:

diff --git a/debian/control b/debian/control
index 95339d1..cfd08f5 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Paul Wouters [email protected]
Vcs-Browser: http://git.libreswan.org/libreswan.git/.git;a=summary
Vcs-Git: git://git.libreswan.org//libreswan.git
Standards-Version: 3.8.4
-Build-Depends: debhelper (>= 7.1), libgmp3-dev, libssl-dev (>= 0.9.8), htmldoc, man2html, libcurl4-openssl-dev, libldap2-dev, libpam0g-dev, libkrb5-dev, bison, flex, dpatch, bzip2, po-debconf, libunbound-dev, libnspr4-dev, libnss3-dev, libnss3-tools
+Build-Depends: debhelper (>= 7.1), libgmp3-dev, libssl-dev (>= 0.9.8), htmldoc, man2html, libcurl4-openssl-dev, libldap2-dev, libpam0g-dev, libkrb5-dev, bison, flex, dpatch, bzip2, po-debconf, libunbound-dev, libnspr4-dev, libnss3-dev, libnss3-tools, sudo, module-assistant
Homepage: https://www.libreswan.org/

Package: libreswan
diff --git a/debian/libreswan-doc.docs b/debian/libreswan-doc.docs
index c7988c8..9145e8f 100644
--- a/debian/libreswan-doc.docs
+++ b/debian/libreswan-doc.docs
@@ -1,4 +1,3 @@
-BUGS
README
CREDITS
TRADEMARK
diff --git a/debian/libreswan-modules-source.rules b/debian/libreswan-modules-source.rules
index c1cc35f..776e933 100755
--- a/debian/libreswan-modules-source.rules
+++ b/debian/libreswan-modules-source.rules
@@ -109,7 +109,7 @@ install: build
dh_installdirs

    mkdir -p $(MODDESTDIR)

```
  cp modobj26/ipsec.ko $(MODDESTDIR)
```

  cp `find $(CURDIR) -name ipsec.ko` $(MODDESTDIR)

Build architecture-independent files here.

KLIPS-Build fails on newer Kernels without CONFIG_USER_NS

My build on Linux 3.18 fails:

  CC [M]  ../modules/klips/pfkey_v2.o
../modules/klips/pfkey_v2.c: In function 'pfkey_create':
../modules/klips/pfkey_v2.c:750:14: error: incompatible types when assigning to type 'uint32_t' from type 'kuid_t'
scripts/Makefile.build:257: recipe for target '../modules/klips/pfkey_v2.o' failed

HAVE_USER_NS is only defined, if CONFIG_USER_NS is enabled in the kernel. IMO this is unecessary because init_user_NS and from_kuid are always defined.

So I propose the following change:

--- ipsec_kversion.h.orig       2015-11-06 08:51:07.167527341 +0100
+++ ipsec_kversion.h    2015-11-06 08:51:22.351489140 +0100
@@ -552,11 +552,8 @@
 # define DEFINE_RWLOCK(x) rwlock_t x = RW_LOCK_UNLOCKED
 #endif

-/* CONFIG_USER_NS is now on in Fedora 20 kernels */
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 5, 0)
-# if defined(CONFIG_USER_NS)
-#  define HAVE_USER_NS
-# endif
+# define HAVE_USER_NS
 #endif

 #endif /* _LIBRESWAN_KVERSIONS_H */

This works for me.

ipsec checknss, custom directory not recognized

I set up Openstack with VPNaaS.

During creation process of the VPN this command is executed:
ip netns exec qrouter-664940e8-6139-4c36-8fcc-ee9e06bd5212 ipsec checknss /var/lib/neutron/ipsec/664940e8-6139-4c36-8fcc-ee9e06bd5212/etc

The db files are always added to the directory /etc/ipsec.d
Looking at the bash script "ipsec" i saw that the variable IPSEC_NSSDIR_SQL is set only at the beginning of the script.
If a custom directory is specified, the variable IPSEC_NSSDIR_SQL is not changed.

Adding IPSEC_NSSDIR_SQL="sql:${IPSEC_NSSDIR}" resolved the issue.

        if [ -n "${2}" ]; then
            # A lot of nss commands use -d or --configdir to specify
            # NSS db location
            if [ "${2}" = "-d" -o "${2}" = "--configdir" ]; then
                IPSEC_NSSDIR="${3}"
            else
                IPSEC_NSSDIR="${2}"
            fi
       +IPSEC_NSSDIR_SQL="sql:${IPSEC_NSSDIR}"
        fi
        if [ ! -d "${IPSEC_NSSDIR}" ]; then
            mkdir -p "${IPSEC_NSSDIR}"
        fi
        # if we have old database
        if [ -f "${IPSEC_NSSDIR}/cert8.db" -o \

Broken .spec file

The spec files just had a bug introduced that causes the build to fail.

%global USE_SECCOMP false

false isn't false. I think the sketchy use of true earlier in the file misleads one to think that there are keywords with those names. From my experience, they both act as truthy strings.

I switched to this and got the build to succeed:

%global USE_SECCOMP 0

The vti interface vanishes when peer goes down and up

I was build and tested route based vpn(libreswan <-> libreswan) from master branch source.

    left=x.x.x.x
    leftid=y.y.y.y
    leftsubnet=0.0.0.0/0
    right=z.z.z.z
    rightid=z.z.z.z
    rightsubnet=0.0.0.0/0
    mark=1/0xffffffff
    vti-interface=vti01
    vti-routing=no
    vti-shared=no
    leftvti=169.254.252.XXX/30

Normal startup is not a problem.
But, when the connection peer goes down and up, the vti interface leave deleted.
This situation is fixed unless it is restarted.

In a little examination, _updown.netkey script receives the down-client, script got PLUTO_CONN_KIND was 'CK_PERMANENT'.
I wonder if we do not consider this situation.

ipsec rsasigkey and ipsec newhostkey store invalid public key in text file

Somehow the 5th character is different when using this command.

In the first example below its 0sAQG... vs 0sAQO..

Its kind of hard to spot.

Linux Libreswan 3.18 (netkey) on 4.4.33_bigmem_syn3
32-bits

[Syn-3] [email protected] ~#     ipsec newhostkey --output /tmp/newhost
Generated RSA key pair with CKAID 855bbff8696717c3fff8b3a52aa805f4cc2278e6 was stored in the NSS database
[Syn-3] [email protected] ~# cat /tmp/newhost 
: RSA   {
        # RSA 3488 bits   darkstar   Thu Jan 12 17:11:34 2017
        # for signatures only, UNSAFE FOR ENCRYPTION
        #ckaid=855bbff8696717c3fff8b3a52aa805f4cc2278e6
        #pubkey=0sAQGntuuo4zCnBPKrSRO1/sF7qycwG5TLT2p3MXuFztupsoD4e6C20CFXWJmQJdLOqrlIoahcrhFE1ssL3oa7N1RcUJ2nC1NFZaB8LhskIKAzK0snfz9ZmJiR74/kUNHPStqVv24X7RK+o1OhaALM1KBeDF0hCo3Q6YYwB9upHXGmO24l/rJB1o5CebX4POEv06RbJSbyrtHD0vaNRR/u0Q3f1lAiyxnivtvolxh69lur9IYNhjCbfCdzDvDA4eRI69Cny4Ux6kZwM8Dkss5Tkz3+2lWZKUXLh+qbtyicbU5p4ibYOMYy+M/2XRETaeP+2J7Z2fHvsP29objdpr7T5MCvgJQt7df8zLdBc9UPqGupoAOw4fE9viLc7e5+xGNt55rqXmTiNY2XWmxyCsIto1XEYnitCfHpvT1p+N6ZwsOXOmOWwdaeI/Y8WDKAK0UL5/FTXuHwXApOKY576w8TN2ma1dy1TO7vEXs/qQt8teF4AomJlGfGAkgpyNMlBKnd+7wgWdkXUtbax3JRCoF4BFV54EdxvkA98lafZEs7MGbKTeW2mAD2hbis7VW3ToM8BAbHG9eD
        Modulus: 0xa7b6eba8e330a704f2ab4913b5fec17bab27301b94cb4f6a77317b85cedba9b280f87ba0b6d0215758999025d2ceaab948a1a85cae1144d6cb0bde86bb37545c509da70b534565a07c2e1b2420a0332b4b277f3f59989891ef8fe450d1cf4ada95bf6e17ed12bea353a16802ccd4a05e0c5d210a8dd0e9863007dba91d71a63b6e25feb241d68e4279b5f83ce12fd3a45b2526f2aed1c3d2f68d451feed10ddfd65022cb19e2bedbe897187af65babf4860d86309b7c27730ef0c0e1e448ebd0a7cb8531ea467033c0e4b2ce53933dfeda55992945cb87ea9bb7289c6d4e69e226d838c632f8cff65d111369e3fed89ed9d9f1efb0fdbda1b8dda6bed3e4c0af80942dedd7fcccb74173d50fa86ba9a003b0e1f13dbe22dcedee7ec4636de79aea5e64e2358d975a6c720ac22da355c46278ad09f1e9bd3d69f8de99c2c3973a6396c1d69e23f63c5832802b450be7f1535ee1f05c0a4e298e7beb0f1337699ad5dcb54ceeef117b3fa90b7cb5e1780289899467c6024829c8d32504a9ddfbbc2059d91752d6dac772510a8178045579e04771be403df2569f644b3b3066ca4de5b69800f685b8aced55b74e833c0406c71bd783
        PublicExponent: 0x03
        }
# do not change the indenting of that "}"
[Syn-3] [email protected] ~# ipsec showhostkey --list
< 1> RSA keyid: AQOgZ6ux7 ckaid: 657cfd81eaa05d3e7b02026d9c7d30db2c639f0b
< 2> RSA keyid: AQOntuuo4 ckaid: 855bbff8696717c3fff8b3a52aa805f4cc2278e6
[Syn-3] [email protected] ~# ipsec showhostkey --right --ckaid 855bbff8696717c3fff8b3a52aa805f4cc2278e6
        # rsakey AQOntuuo4
        rightrsasigkey=0sAQOntuuo4zCnBPKrSRO1/sF7qycwG5TLT2p3MXuFztupsoD4e6C20CFXWJmQJdLOqrlIoahcrhFE1ssL3oa7N1RcUJ2nC1NFZaB8LhskIKAzK0snfz9ZmJiR74/kUNHPStqVv24X7RK+o1OhaALM1KBeDF0hCo3Q6YYwB9upHXGmO24l/rJB1o5CebX4POEv06RbJSbyrtHD0vaNRR/u0Q3f1lAiyxnivtvolxh69lur9IYNhjCbfCdzDvDA4eRI69Cny4Ux6kZwM8Dkss5Tkz3+2lWZKUXLh+qbtyicbU5p4ibYOMYy+M/2XRETaeP+2J7Z2fHvsP29objdpr7T5MCvgJQt7df8zLdBc9UPqGupoAOw4fE9viLc7e5+xGNt55rqXmTiNY2XWmxyCsIto1XEYnitCfHpvT1p+N6ZwsOXOmOWwdaeI/Y8WDKAK0UL5/FTXuHwXApOKY576w8TN2ma1dy1TO7vEXs/qQt8teF4AomJlGfGAkgpyNMlBKnd+7wgWdkXUtbax3JRCoF4BFV54EdxvkA98lafZEs7MGbKTeW2mAD2hbis7VW3ToM8BAbHG9eD
[Syn-3] [email protected] ~#     ipsec rsasigkey > /tmp/rsasigkey
Generated RSA key pair with CKAID 90a1e3effa21b9c25f309be8980cd6b0e2935f98 was stored in the NSS database
[Syn-3] [email protected] ~# ipsec showhostkey --list
< 1> RSA keyid: AQOgZ6ux7 ckaid: 657cfd81eaa05d3e7b02026d9c7d30db2c639f0b
< 2> RSA keyid: AQOntuuo4 ckaid: 855bbff8696717c3fff8b3a52aa805f4cc2278e6
< 3> RSA keyid: AQPRekU+k ckaid: 90a1e3effa21b9c25f309be8980cd6b0e2935f98
(failed reverse-i-search)`giht':     ipsec rsasigkey > /tmp/rsasi^Cey
[Syn-3] [email protected] ~# ipsec showhostkey --right --ckaid 90a1e3effa21b9c25f309be8980cd6b0e2935f98
        # rsakey AQPRekU+k
        rightrsasigkey=0sAQPRekU+k62ULpH9x7ibgU4ahoCYfl5ur6sb1ICIqwdixZ1e++m3py0YpaXD1JEriDtKIYs18jLyOY0Rbxaxtbbbxhu0ioDYtlFk2hyVqxSUPHsH4J8N5Ox83+kU98nZTp58SCbwErJafnbsTE2LCknMZwJsrzhZU52NXa/gS3YJnx5fXm5OiBTQjtfGJ++T2NfwrHwzyUZ14gEKooWs4mLHLB8rkBZHQ0RZzOudByctO2pKUTXHjwYezKgOqgeLYC+E0YpgXpmhEag/sSGUunKjWZWBHRT249UoHwGaSI7w2P/bcazXDUHRPWUvG9gmswCQ2+0DaZcQBHpmKaRpciQArRt6DSFMRcRHA0H3HNowBQ8//w1lfz6ZD3N0ttnhmjL+P5QeEVmUFf8rla7sn0AvoryuyRn0wmJowrojKvIrF8fDgj4wD1FK7ujk2OsyFVgi1NUAIeh/l/C8IbPxIvGGqW3jThNz6U0HcauPX9KloFjtiIa2PqayUyG/Zsj3Qd/V8KBDpFnxCDC4S6wCHXpO4jBAIDbu7/Iki4/RftMp+nJ/wIBP6vKbG5akchpPE+g/+yoMehIO0kaK23yjSZ82uzX2nQ==
[Syn-3] [email protected] ~# cat /tmp/rsasigkey 
        # RSA 3616 bits   darkstar   Thu Jan 12 17:12:34 2017
        # for signatures only, UNSAFE FOR ENCRYPTION
        #ckaid=90a1e3effa21b9c25f309be8980cd6b0e2935f98
        #pubkey=0sAQHRekU+k62ULpH9x7ibgU4ahoCYfl5ur6sb1ICIqwdixZ1e++m3py0YpaXD1JEriDtKIYs18jLyOY0Rbxaxtbbbxhu0ioDYtlFk2hyVqxSUPHsH4J8N5Ox83+kU98nZTp58SCbwErJafnbsTE2LCknMZwJsrzhZU52NXa/gS3YJnx5fXm5OiBTQjtfGJ++T2NfwrHwzyUZ14gEKooWs4mLHLB8rkBZHQ0RZzOudByctO2pKUTXHjwYezKgOqgeLYC+E0YpgXpmhEag/sSGUunKjWZWBHRT249UoHwGaSI7w2P/bcazXDUHRPWUvG9gmswCQ2+0DaZcQBHpmKaRpciQArRt6DSFMRcRHA0H3HNowBQ8//w1lfz6ZD3N0ttnhmjL+P5QeEVmUFf8rla7sn0AvoryuyRn0wmJowrojKvIrF8fDgj4wD1FK7ujk2OsyFVgi1NUAIeh/l/C8IbPxIvGGqW3jThNz6U0HcauPX9KloFjtiIa2PqayUyG/Zsj3Qd/V8KBDpFnxCDC4S6wCHXpO4jBAIDbu7/Iki4/RftMp+nJ/wIBP6vKbG5akchpPE+g/+yoMehIO0kaK23yjSZ82uzX2nQ==
        Modulus: 0xd17a453e93ad942e91fdc7b89b814e1a8680987e5e6eafab1bd48088ab0762c59d5efbe9b7a72d18a5a5c3d4912b883b4a218b35f232f2398d116f16b1b5b6dbc61bb48a80d8b65164da1c95ab14943c7b07e09f0de4ec7cdfe914f7c9d94e9e7c4826f012b25a7e76ec4c4d8b0a49cc67026caf3859539d8d5dafe04b76099f1e5f5e6e4e8814d08ed7c627ef93d8d7f0ac7c33c94675e2010aa285ace262c72c1f2b901647434459cceb9d07272d3b6a4a5135c78f061ecca80eaa078b602f84d18a605e99a111a83fb12194ba72a35995811d14f6e3d5281f019a488ef0d8ffdb71acd70d41d13d652f1bd826b30090dbed03699710047a6629a469722400ad1b7a0d214c45c4470341f71cda30050f3fff0d657f3e990f7374b6d9e19a32fe3f941e11599415ff2b95aeec9f402fa2bcaec919f4c26268c2ba232af22b17c7c3823e300f514aeee8e4d8eb32155822d4d50021e87f97f0bc21b3f122f186a96de34e1373e94d0771ab8f5fd2a5a058ed8886b63ea6b25321bf66c8f741dfd5f0a043a459f10830b84bac021d7a4ee230402036eeeff2248b8fd17ed329fa727fc0804feaf29b1b96a4721a4f13e83ffb2a0c7a120ed2468adb7ca3499f36bb35f69d
        PublicExponent: 0x03

How to import raw RSA keys for use in libreswan

Hi there

I am migrating from strongswan to libreswan. In strongswan i used to have RSA public keys from my peers and a RSA private key for myself. I fail on importing these RSA keys into the nss db or converting them into a usable libreswan configuration.

Can you please give some guidance on how to import raw RSA public/private keys?

Thanks a lot
Sascha

File-missing

in docs/ipsec.html file there is three option on top & bottom of page i.e.
contents
previous
next
which must be the link to new page but these link doesn't work they show
error 404 : page not found

IKEv2 with multiple subnets

Hello,

I have a LibreSWAN connection configuration with one left subnets and two right subnets. With IKEv1, I get what I expect: a single phase 1 (IKE) SA, and two associated phase 2 (IPsec) SAs. With IKEv2, I would similarly expect a single parent SA and two child SAs —but that’s not what I get; instead, pluto performs two complete IKE exchanges from scratch (seen in a packet capture), resulting in multiple parent SAs. The IPsec SAs are created, but confusingly the output of ipsec status only mentions PARENT SAs, even though the negotiated ESP tunnel SAs are clearly there. Can you comment on what I should expect here and why it’s behaving this way? I’m using libreswan-3.15-5.el7_1.x86_64 on RHEL7 with NETKEY.

If there’s a better place to post questions like this, please redirect me.

Thanks,

Richard

Dropping MODP1024 breaks Android/Windows clients

In Libreswan 3.19, MODP1024 was dropped from the "ike=" default list [1][2]. Assuming that the default "ike=" list is used, this change breaks compatibility with at least the following:

The IKEv2 native VPN client in Windows 7/8/10, because they require MODP1024 [3][4].
Android 5.x native VPN client [5].

The above VPN clients can no longer connect using the default "ike=" list. I suggest that you reconsider/revert this decision of dropping MODP1024 from the default cipher list. Thank you.

[1] 42a8628
[2] f870e85
[3] https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#AES-256-CBC-and-MODP2048
[4] http://rockhoppervpn.sourceforge.net/ref_tips_win7.html
[5] hwdsl2/setup-ipsec-vpn#101

plutostderror="/var/log/ipsec.log" doesn't work

I tried but plutostderror directive is not able to generate the log file I specified.
This pair of CentOS 6.3 VM were able to generate /var/log/ipsec.log when using OpenSwan package come with CentOS. Please provide pointer to trace down the issue.

Error message

[root@centos63-1 etc]# ls /var/log/ipsec.log
ls: cannot access /var/log/ipsec.log: No such file or directory
[root@centos63-1 etc]#

Here is the info.

/etc/ipsec.conf

[root@centos63-1 etc]# cat /etc/ipsec.conf
version 2.0

config setup
dumpdir=/var/run/pluto/
nat_traversal=yes
oe=off
protostack=netkey
#plutostderrlog=/dev/nulll
plutostderrlog="/var/log/ipsec.log"

conn c-c-h-h-psk # centos-centos-host-host-psk
keyingtries=3
authby=secret
left=192.168.1.212
right=192.168.1.213
auto=start

[root@centos63-1 etc]#

ipsec verify

[root@centos63-1 etc]# ipsec verify
Verifying installed system and configuration files

Version check and ipsec on-path [OK]
Libreswan 3.0 (netkey) on 2.6.32-279.22.1.el6.x86_64
Checking for IPsec support in kernel [OK]
NETKEY: Testing XFRM related proc values
ICMP default/send_redirects [NOT DISABLED]

Disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will cause act on or cause sending of bogus ICMP redirects!

     ICMP default/accept_redirects                  [NOT DISABLED]

Disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will cause act on or cause sending of bogus ICMP redirects!

     XFRM larval drop                               [OK]

Pluto ipsec.conf syntax [OK]
Hardware random device [N/A]
Two or more interfaces found, checking IP forwarding [FAILED]
Checking rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/default/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/lo/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/eth0/rp_filter [ENABLED]
/proc/sys/net/ipv4/conf/pan0/rp_filter [ENABLED]
rp_filter is not fully aware of IPsec and should be disabled
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for IKE on tcp 500 [NOT IMPLEMENTED]
Pluto listening for IKE/NAT-T on udp 4500 [OK]
Pluto listening for IKE/NAT-T on tcp 4500 [NOT IMPLEMENTED]
Pluto listening for IKE on tcp 10000 (cisco) [NOT IMPLEMENTED]
Pluto ipsec.secret syntax [OK]
Checking NAT and MASQUERADEing [TEST INCOMPLETE]
Checking 'ip' command [OK]
Checking 'iptables' command [OK]
Checking for obsolete ipsec.conf options [OK]
Opportunistic Encryption [DISABLED]

ipsec verify: encountered 13 errors - see 'man ipsec_verify' for help
[root@centos63-1 etc]#

Enabling KLIPS with SAref patch on Ubuntu 14.04

Title.
I am trying to set up a VPN server behind a NAT and have clients connect to it. Clients with public IP's can connect just fine, however, when multiple clients behind a NAT attempt to connect they are unable to. I've applied the fixes to windows and verified that this isnt a problem native to windows, though windows gives me a 789 error. I've done research on the topic concerning NAT'd clients and connection issues and the idea i got was to install libreswan and enable KLIPS with the SAref patch. I can give more details upon request such as the log files and error messages.

libreswan / libreswan Goto Github PK

libreswan's Introduction

Libreswan

License

Installing

Installing from Source

Requirements

Building for RPM based systems

Building for DEB based systems

Building from scratch into /usr/local

Starting Libreswan

Status

Configuration

NSS initialisation

Upgrading

Help

Bugs

Security Information

Development

Documentation

libreswan's People

Contributors

Stargazers

Watchers

Forkers

libreswan's Issues

for more examples, see /etc/ipsec.d/examples/

Build architecture-independent files here.

Recommend Projects

Recommend Topics

Recommend Org