Issue 245 from www.openswan.org
Created by: Paul Wouters
On Sat Mar 12 18:16:47 2005

Priority: High
Status: Assigned

Add support for RFC4025

IPSECKEY DNS record

Issue 1024 from www.openswan.org
Created by: Julien Plissonneau Duquène
On Mon Mar 30 13:58:46 2009

Priority: High
Status: New

On a setup with a root FS on NFS over IPSec, it is not possible to restart pluto (initially started in initramfs) using the scripts. When trying that, the NFS server becomes unreachable after associations are removed, and the restart script hangs there (and the whole system too).

Issue 1175 from www.openswan.org
Created by: Paul Wouters
On Thu Nov 25 10:56:14 2010

Priority: Normal
Status: New

add new whack command to dynamically change plutodebug level - like ipsec klipsdebug

Issue 417 from www.openswan.org
Created by: Paul Wouters
On Sat Aug 27 22:24:56 2005

Priority: High
Status: Assigned

add ipsec verify option to look at global pmtu setting for 2.6.12/13+ kernels

Issue 1171 from www.openswan.org
Created by: Paul Wouters
On Mon Nov 22 14:27:35 2010

Priority: Normal
Status: New

There should be a netlink delete notify message, which pluto can then take action on (hold, trap, init, etc)

Issue 1378 from www.openswan.org
Created by: Tom Rigole
On Thu Jun 27 10:23:40 2013

Priority: Normal
Status: Feedback

We have a setup with a central OpenSwan VPN server (105.19.132.220) and multiple distributed devices setting up site-to-site VPN's to this central server. I've attached a limited extract of the ipsec.conf of the central server (only two sites are included and real public IP have been replaced with random ones in a consistent way).

These remote sites do source-NAT'ing and each site uses a small dedicated subnet (examples here are: 10.112.0.64/29 and 10.112.0.80/29). The other way around the server is exposed under a VIP 192.168.21.21 wich is mapped on the server loopback interface.

Now this setup works fine. The remote sites connect and traffic is routed both ways as expected. Pinging the remote sites 10.112.0.65 or 10.112.0.81 from the central server (105.19.132.220) works fine. The other way around from both sites we can ping the central server VIP 192.168.21.21 perfectly. We are also constantly using these VPN's to support protocols setting up tcp connections from the server towards the remote sites. Whenever communciation interruptions occur, the VPN restore themselves just fine.

As a final remark, these remote sites also connection to another central VPN server, which is no openswan but a hardware firewall. This works also as expected.

Now the issue:

Sometimes, after weeks of operation, the central openswan server fails to find the route for one of the remote vpn's (e.g. ping'ing 10.112.0.65 from the central server fails). Looking at the tunnel statuses (see attachements) the tunnel seems to be open however. In the other direction, from the site (10.112.0.65) to the central server the ping'ing does still work however (so we can ping 192.168.21.21 from 10.112.0.65)! There were no server reboots or ipsec restarts in the mean time, so it is not obvious what triggers the error. I can't seem to find any way to fix the issue, except by simply restarting the ipsec service on the central server. After the restart, all is working fine again (but the error will most likely occur again in a couple of weeks).

Also, while this error condition holds on this central openswan server, the ipsec tunnel to the other concentrator on the hardware firewall is still up and running fine.

I've attached the ipsec.conf extract and the output from 'ip xfrm state' output and 'route -n' during the 'normal' operation and during the 'error' condition. I've remarked that during the error condition, some bogus tunnel is visible in the 'ip xfrm state'.

The OpenSwan version is:

• Linux Openswan U2.6.32/K2.6.32-358.el6.x86_64 (netkey)

The system on which this runs is:

• CentOS release 6.4 (Final)
• kernel release: 2.6.32-358.el6.x86_64

Any hints on how to fix this are welcome!

Attachments: https://gist.github.com/xelerance/7881320

Issue 125 from www.openswan.org
Created by: Paul Wouters
On Mon Feb 9 19:52:35 2004

Priority: Normal
Status: New

compress=no just means we don't advertise it. If the remote asks compression, we still do it. There seems to be some interop problems with IPCOMP and 2.6 (2.6 people doing it wrong) and therefor some (why not all??) connections with 2.4 KLIPS to 2.6 native fail.

The only current fix is a recompile with CONFIG_IPSEC_IPCOMP disabled.

mcr: paul, re: compress=never, DHR wanted to make it four stated along time ago, for exactly this reason. Henry didn't agree. It stayed that way.
Yes, we should make it four stated, but there is only one flag in pluto, so it takes some work. Let's do it after starter.

Issue 1211 from www.openswan.org
Created by: Paul Wouters
On Sun Feb 13 20:50:14 2011

Priority: Normal
Status: Assigned

This results in seeing:

sending 592 bytes for EVENT_RETRANSMIT through eth0:4600 to 167.16.139.24:500 (using #1)

Because really, what is needed is: ipsec whack --ikeport xxxx [stuff] --to --ikeport xxxx [stuff]

What we really want is to have ietf_constants.h:#define IKE_UDP_PORT 500 as a customizable option

Issue 189 from www.openswan.org
Created by: Paul Wouters
On Tue Oct 19 21:12:00 2004

Priority: Normal
Status: Assigned

Add check to ipsec verify for overlapping virtual_private and subnet=

Issue 1387 from www.openswan.org
Created by: Mark Swank
On Mon Oct 21 20:33:06 2013

Priority: High
Status: New

While restarting or reloading openswan I want to block all incoming and outgoing traffic.

Not saying this is the best solution for what I am trying to do but will show the bug clearly.
You will need 2 nodes with 1 connection to each other in /etc/ipsec.conf

1. from node1 start ping flood to node2
2. tcpdump traffic
4. notice packets in clear upon restart of openswan.

My possible solution: which does not work due to blank spd.

1. ifconfig eth0 down
2. service ipsec restart
3. ifconfig eth0 up
4. Lets look at what is in ip xfrm.

Notice that there is no policy for the connection.

5. Now restart IPsec again and you will see the policy for the connection. <service ipsec restart && ip xfrm policy show>

This should be high priority bug and or feature in openswan imo.
Allow openswan to restart and not send packets in clear while openswans restarts and pants are down.
side note: after step 4) I also had to do a to restore my ssh connection as it did not like the down/up.
Regardless if feature or not openswan should handle this if interface is down.

This also implies that if the port is shut off at the switch openswan on boot or ipsec restart/reload will end up with a blank spd but have not tested this.

os=rhel6.4
openswan=2.6.32

Attachment: https://gist.github.com/xelerance/7881461

Issue 1184 from www.openswan.org
Created by: Paul Wouters
On Mon Dec 20 17:10:32 2010

Priority: Low
Status: New

http://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-00

Issue 1379 from www.openswan.org
Created by: shreeduth awasthi
On Wed Jul 17 19:24:54 2013

Priority: High
Status: Feedback

we have compiled Openswan under Linux 4.3 kernel successfully.

We've then tried to establish IPSec connections between the Openswan (Linux 4.3) and Our board (racoon). We could successfully establish a tunnel and we have configured few IPSec rules on to it. The functionality is working fine with packets being encrypted and decrypted properly.

The only problem which we are facing now is the flooding of error messages at both ends. ( Our board and linux machine )

Pls. help us get over this problem. ( Hopefully configuration issue )

Linux side:

we are using openswan (working and non-working ipsec.conf attached )

Open Swan Version on Linux Side :

Linux Openswan U2.6.21/K2.6.18-164.el5PAE

Our Board side ( racoon )

ipsec-tools-0.8.0-1_WR4.3.x86_64

Additional information:

Here is important bits from my ipsec.conf file

Non Woking IPsec Conf

conn lab-ipsec1
authby=rsasig
left=10.1.21.2
leftsubnets={ 10.1.13.0/24 10.1.31.0/24 10.1.33.0/24 }
right=10.1.21.1
rightsubnets={ 10.1.12.0/24 10.1.36.0/24 10.1.21.0/24 }

Working IPSec Conf

conn lab-ipsec1
authby=rsasig
left=10.1.21.2
leftsubnets=10.1.13.0/24
right=10.1.21.1
rightsubnets=10.1.12.0/24
.......

conn lab-ipsec2
authby=rsasig
left=10.1.21.2
leftsubnets=10.1.31.0/24
right=10.1.21.1
rightsubnets=10.1.36.0/24
........

conn lab-ipsec3
authby=rsasig
left=10.1.21.2
leftsubnets=10.1.33.0/24
right=10.1.21.1
rightsubnets=10.1.21.0/24
.......

The above IPsec conf is for Linux box side. Please find the complete details in the attachment

Note: Using (,) in between the subnets is also not working !

Issue 1343 from www.openswan.org
Created by: Steve Lanser
On Thu Mar 8 17:15:31 2012

Priority: High
Status: New

The official documentation does not state any support for the following modp groups:

group 15:     modp3072-bit
group 16:     modp4096-bit
group 17:     modp6144-bit
group 18:     modp8192-bit

It does support this one from RFC 3526:
group 14: modp2048-bit

The parser does not complain if you attempt to use these groups in configuration, but pluto crashes during negotiation.

For example, if you set modp3072 in your phase2alg statement, pluto aborts like this:

Mar 8 13:53:26 tb11 pluto[11290]: "10.2.0.31-to-10.2.0.27" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
Mar 8 13:53:26 tb11 pluto[11290]: "10.2.0.31-to-10.2.0.27" #1: Dead Peer Detection (RFC 3706): enabled
Mar 8 13:53:26 tb11 pluto[11290]: "10.2.0.31-to-10.2.0.27" #2: initiating Quick Mode PSK+ENCRYPT+PFS+UP+SAREFTRACK {using isakmp#1 msgid:750ddde8 proposal=3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP3072}
Mar 8 13:53:26 tb11 pluto[11290]: NSS: DH private key creation failed (err -8190)
Mar 8 13:53:26 tb11 ipsec__plutorun: /usr/libexec/ipsec/_plutorun: line 250: 11290 Aborted (core dumped) /usr/libexec/ipsec/pluto --nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d --debug-all --debug-raw --debug-crypt --debug-parsing --debug-emitting --debug-control --debug-lifecycle --debug-klips --debug-dns --debug-oppo --debug-oppoinfo --debug-controlmore --debug-x509 --debug-dpd --debug-pfkey --debug-natt --debug-nattraversal --use-netkey --uniqueids --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,%v6:fd00::/8,%v6:fe80::/10
Mar 8 13:53:26 tb11 ipsec__plutorun: 104 "10.2.0.31-to-10.2.0.27" #1: STATE_MAIN_I1: initiate
Mar 8 13:53:26 tb11 ipsec__plutorun: 003 "10.2.0.31-to-10.2.0.27" #1: received Vendor ID payload [Openswan (this version) 2.6.38dr2 ]
Mar 8 13:53:26 tb11 ipsec__plutorun: 003 "10.2.0.31-to-10.2.0.27" #1: received Vendor ID payload [Dead Peer Detection]
Mar 8 13:53:26 tb11 ipsec__plutorun: 106 "10.2.0.31-to-10.2.0.27" #1: STATE_MAIN_I2: sent MI2, expecting MR2
Mar 8 13:53:26 tb11 ipsec__plutorun: 108 "10.2.0.31-to-10.2.0.27" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Mar 8 13:53:26 tb11 ipsec__plutorun: 004 "10.2.0.31-to-10.2.0.27" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
Mar 8 13:53:28 tb11 pm[2294]: [243608.109978] [pm.NOTICE]: Output from ipsec (IPSec Daemon [pluto]) (pid 11046): ====== Crypto IPsec stopped ipsec at 20120308-135328 with status 0: ====== Crypto IPsec (pluto) died unexpectedly

This happens under the default compilation with NSS (I don't know if it happens without NSS), however we require NSS.

Here are the configurations used in this particular test:

(on tb11 the host that crashed)
conn 10.2.0.31-to-10.2.0.27
#########################
# Peering ID 1
#########################
# Phase 1 ISAKMP settings
auto = start
connaddrfamily = ipv4
left = 10.2.0.31
right = 10.2.0.27
type = transport
aggrmode = no
dpddelay = 5
dpdtimeout = 5
authby = secret
ikelifetime = 28800s
ike = 3des-sha1;modp1024
ikev2 = never
#########################
# Phase 2 IPsec SA settings
salifetime = 3600s
phase2 = esp
#phase2alg = 3des-sha1;modp1024
phase2alg = 3des-sha1;modp3072
pfs = yes
compress = no

And on tb7, where it didn't crash, but merely detected a dead peer state:

conn 10.2.0.27-to-10.2.0.31
#########################
# Peering ID 1
#########################
# Phase 1 ISAKMP settings
auto = start
connaddrfamily = ipv4
left = 10.2.0.27
right = 10.2.0.31
type = transport
aggrmode = no
dpddelay = 5
dpdtimeout = 5
authby = secret
ikelifetime = 28800s
ike = 3des-sha1;modp2048
ikev2 = never
#########################
# Phase 2 IPsec SA settings
salifetime = 3600s
phase2 = esp
#phase2alg = 3des-sha1;modp1024
phase2alg = 3des-sha1;modp3072
pfs = yes
compress = no

Mar 8 13:53:12 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: Main mode peer ID is ID_IPV4_ADDR: '10.2.0.31'
Mar 8 13:53:12 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Mar 8 13:53:12 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
Mar 8 13:53:12 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: Dead Peer Detection (RFC 3706): enabled
Mar 8 13:53:22 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: DPD: No response from peer - declaring peer dead
Mar 8 13:53:22 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: DPD: Putting connection into %trap
Mar 8 13:53:22 tb7 pluto[12767]: "10.2.0.27-to-10.2.0.31" #3: deleting state (STATE_MAIN_R3)

[email protected]

Issue 437 from www.openswan.org
Created by: Paul Wouters
On Mon Sep 19 05:02:07 2005

Priority: High
Status: New

allow pluto to --down and --delete a connection even if it (no longer) appears in ipsec.conf.

Issue 1310 from www.openswan.org
Created by: Paul Wouters
On Thu Feb 9 11:55:27 2012

Priority: Normal
Status: New

DEBUG: add an impair-retransmit option that supresses all retransmits

This aids in debugging

Issue 667 from www.openswan.org
Created by: H Peter Anvin
On Mon Sep 11 19:46:32 2006

Priority: High
Status: Feedback

The 2.6 Linux kernel has a substantial weakness in that it doesn't create endpoint interfaces for IPsec tunnels. This causes problems with routing, proxyarp and iptables. It has been proposed on the netdev mailing list that a suitable way around this is to use the ipip tunnel module and set up the kernel to do ipsec in transport mode. This mode is described in RFC 3884 (IIPtran) section 3.1 as being over-the-wire idential with tunnel-mode IPsec, and so it should be possible for pluto to establish this kind of link instead of the more typical variant.

It would be nice to have, at least as an option.

Hi,

I am using Cetos 6.4. When I run command "ipsec verify" it fails with error "IP XFRM BROKEN".

It seems that issue is in file "openswan-2.6.39/programs/verify/verify.in". In this we are checking for text "XFRM-OBJECT". But on my system error message returned by command "ip xfrm" does not contain text "XFRM-OBJECT", it contains "XFRM_OBJECT" instead.

Please let me know if you need any further information from me on this.

Thanks & Regards,
Atul Atri.

Issue 1040 from www.openswan.org
Created by: Paul Wouters
On Sat Jun 20 11:48:51 2009

Priority: Low
Status: Assigned

Instead of a hardcoded ./include/ietf_constants.h:#define IKE_UDP_PORT 500, also allow it to run on another port via an option.
currently, you can already listen on another port using plutoopts="--ikeport 5000"

either change the option to use the --ikeport for both listen and send, or split the option in two seperate options

though thinking about rekeying, it might make sense to only support matching in/out ports, which is also the easier fix.

Issue 157 from www.openswan.org
Created by: Andreas Steinmetz
On Sun Aug 22 23:14:24 2004

Priority: High
Status: Assigned

The attached patch allows silent operation of pluto,
i.e. neither logging to syslog not stderr. Useful
for appliances.

Pathc: https://gist.github.com/xelerance/7881015

Issue 579 from www.openswan.org
Created by: Paul Wouters
On Wed Feb 15 06:38:49 2006

Priority: High
Status: New

Date: Wed, 15 Feb 2006 10:20:54 +1100
From: Herbert Xu [email protected]
Cc: Paul Wouters [email protected], Beschorner Daniel [email protected],
"'[email protected]'" [email protected]
To: Andy [email protected]
Subject: Re: XFRM_STATE_NOPMTUDISC, was : MTU/DF problem with 2.6

On Tue, Feb 14, 2006 at 04:33:54PM -0500, Andy wrote:

It's controlled by /proc/sys/net/ipv4/ip_no_pmtu_disc.

But wouldn't that would turn off pmtu for ALL traffic? We're looking for
a way to selectively disable it for ipsec (esp actually).

It's available in the kernel as a per-state flag so someone can
write up a patch for Openswan and make it a per-connection (or global)
flag.

Issue 125 from www.openswan.org
Created by: Paul Wouters
On Mon Feb 9 19:52:35 2004

Priority: Normal
Status: New

compress=no just means we don't advertise it. If the remote asks compression, we still do it. There seems to be some interop problems with IPCOMP and 2.6 (2.6 people doing it wrong) and therefor some (why not all??) connections with 2.4 KLIPS to 2.6 native fail.

The only current fix is a recompile with CONFIG_IPSEC_IPCOMP disabled.

mcr: paul, re: compress=never, DHR wanted to make it four stated along time ago, for exactly this reason. Henry didn't agree. It stayed that way.
Yes, we should make it four stated, but there is only one flag in pluto, so it takes some work. Let's do it after starter.

Issue 1358 from www.openswan.org
Created by: Panagiotis Tamtamis
On Mon May 14 11:08:13 2012

Priority: Normal
Status: New

Until now rekey of a connection based on traffic volume could not be initiated.

With proposed patch anyone can set the value "salifetraffic" (name is possible to change at final patch) in ipsec.conf to set the amount bytes anyone wants in order the connection establish a new IPSEC_SA

eg salifetraffic=56533

below an initial patch can be found for anyone who wants to use that feature.

NOTE: This patch also contains changes for the Feature #1347
https://www.openswan.org/issues/1347#change-2682

This is an initial version!

How the patch works:
When someone uses the keyword salifetraffic then the bytes count is configured to the NETKEY stack at the kernel. (If the value is not used the default applies which is INF)
When the counter expires a MSG from the kernel arrives to openswan.

Openswan handles this MSG. First finds for which connection this msg arrived.
Then finds the best state that this connection is.

And if all are ok an SA_REPLACE event is added to the event handler.

Issue 130 from www.openswan.org
Created by: Michael Richardson
On Wed May 26 18:14:24 2004

Priority: High
Status: Assigned

2.6 provides for a setsockopt() to control setting of DF/PMTU.
In general, we want IKE packets fragmented, since IKE has no PMTU facility.

Make this call on 2.6, and silently ignore failure on 2.4.

Issue 127 from www.openswan.org
Created by: Paul Wouters
On Mon Feb 16 20:54:24 2004

Priority: High
Status: Feedback

15:29 @volvic bleve: openswan works fine with /32
netmask
15:29 < bleve> volvic: exellent!
15:29 < bleve> volvic: then we can really fix one big
problem with dynamic routing.
15:30 @volvic bleve: that's good. Kernel does not
insert route, if /32 netmask is selected

Issue 1282 from www.openswan.org
Created by: Sergey Shamanov
On Thu Sep 8 07:17:05 2011

Priority: Normal
Status: New

I tring yo connect openswan with Cisco ASA5540. In MODE-CFG I recieved "peer udp encapsulation port: 10000" (in vpnc debug log).
Can I setup this connection?

Issue 1389 from www.openswan.org
Created by: John Lundgren
On Thu Nov 7 06:13:40 2013

Priority: Normal
Status: New

I am trying to implement IPSec on a network with hosts running CentOS6.4. Multicast is used on the network, and I am trying to find a solution to secure that multicast traffic using IPSec. As far as I can tell, OpenSwan does not support multicast comms. The only solution I have found is to use GRE tunnels for the multicast traffic, but I am trying to keep all traffic strictly multicast. Anyone have any ideas?

Issue 602 from www.openswan.org
Created by: Linus van Geuns
On Fri Apr 7 15:45:51 2006

Priority: High
Status: New

The idea is to reload the connection database or the whole configuration without disconnecting active connections.

The easiest way would be to reload the connection database and touch existing connections only if they have been modified or deleted.

Issue 1390 from www.openswan.org
Created by: Mark Swank
On Thu Nov 7 19:53:26 2013

Priority: High
Status: New

Linux NODE2 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
I am using certificates in this example but also happens if using psk.

ikev2 and gcm are independent bugs. Even when I use IKEv1 only gcm will never work.
note: IKEv2 was working using openswan 2.6.32 and broke when I installed .39 from source. I have never seen GCM working in any version of openswan.

I could swich to using libreswan but will loose the FIPS validation if I do so REALLY REALLY need this fixed :)

config setup
interfaces=%none
plutoopts="--interface=eth0 --perpeerlog"
protostack=netkey
nat_traversal=yes
force_keepalive=yes
keep_alive=300
oe=off
nhelpers=1
plutostderrlog=/var/log/pluto.log
plutorestartoncrash=true
dumpdir=/tmp
plutowait=yes
plutodebug="all"
listen=10.154.25.150

conn tunnel_10.154.25.149

left=10.154.25.150
leftsubnet=10.154.25.150/32
leftsourceip=10.154.25.150
leftid="CN=NODE2.acme.com"
leftcert=node2
leftrsasigkey=%cert

right=10.154.25.149
rightsubnet=10.154.25.149/32
rightsourceip=10.154.25.149
rightid="CN=NODE1.cisco.com"
rightrsasigkey=%cert
auto=start
type=transport
authby=rsasig 
ikev2=insist                        #COMMENT ME OUT AND IKEv1 WILL WORK . need to remove GCM below and switch to phase2alg=aes256-sha2_256;modp2048  
ike=aes256-sha2_256-modp2048
#phase2alg=aes256-sha2_256;modp2048 # THIS WORKS
phase2alg=aes_gcm_c-256-null        # THIS DOES NOT WORK
pfs=yes
phase2=esp
rekey=yes
ikelifetime=24h
salifetime=28800s 
keyingtries=3 
compress=yes
forceencaps=no 
dpddelay=5
dpdtimeout=5
dpdaction=restart
failureshunt=reject
rekeyfuzz=100% 
rekeymargin=14400s 
mtu=1492 

000 using kernel interface: netkey
000 interface eth0/eth0 10.154.25.150
000 interface eth0/eth0 10.154.25.150
000 %myid = (none)
000 debug raw+crypt+parsing+emitting+control+lifecycle+klips+dns+oppo+controlmore+pfkey+nattraversal+x509+dpd+oppoinfo
000
000 virtual_private (%priv):
000 - allowed 0 subnets:
000 - disallowed 0 subnets:
000 WARNING: Either virtual_private= is not specified, or there is a syntax
000 error in that line. 'left/rightsubnet=vhost:%priv' will not work!
000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
000 private address space in internal use, it should be excluded!
000
000 algorithm ESP encrypt: id=2, name=ESP_DES, ivlen=8, keysizemin=64, keysizemax=64
000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=40, keysizemax=128
000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=160, keysizemax=288
000 algorithm ESP encrypt: id=22, name=ESP_CAMELLIA, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
000 algorithm ESP auth attr: id=8, name=AUTH_ALGORITHM_HMAC_RIPEMD, keysizemin=160, keysizemax=160
000 algorithm ESP auth attr: id=9, name=AUTH_ALGORITHM_AES_CBC, keysizemin=128, keysizemax=128
000 algorithm ESP auth attr: id=251, name=AUTH_ALGORITHM_NULL_KAME, keysizemin=0, keysizemax=0
000
000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=131
000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
000
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,8,64} trans={0,8,3072} attrs={0,8,2048}
000
000 "tunnel_10.154.25.149": 10.154.25.150/32===10.154.25.150<10.154.25.150>[CN=NODE2.cisco.com]...10.154.25.149<10.154.25.149>[CN=NODE1.cisco.com]===10.154.25.149/32; erouted HOLD; eroute owner: #0
000 "tunnel_10.154.25.149": myip=10.154.25.150; hisip=10.154.25.149; mycert=tomcat;
000 "tunnel_10.154.25.149": CAs: 'DC=corp, DC=Krooz, CN=Krooz-KROOZSRV1DC08-CA'...'%any'
000 "tunnel_10.154.25.149": ike_life: 86400s; ipsec_life: 28800s; rekey_margin: 14400s; rekey_fuzz: 100%; keyingtries: 3
000 "tunnel_10.154.25.149": policy: RSASIG+ENCRYPT+COMPRESS+PFS+UP+!IKEv1+IKEv2ALLOW+IKEv2Init+SAREFTRACK; prio: 32,32; interface: eth0;
000 "tunnel_10.154.25.149": network params: metric:0; mtu:1492;
000 "tunnel_10.154.25.149": dpd: action:restart; delay:5; timeout:5;
000 "tunnel_10.154.25.149": newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "tunnel_10.154.25.149": IKE algorithms wanted: AES_CBC(7)_256-SHA2_256(4)_000-MODP2048(14); flags=-strict
000 "tunnel_10.154.25.149": IKE algorithms found: AES_CBC(7)_256-SHA2_256(4)_256-MODP2048(14)
000 "tunnel_10.154.25.149": ESP algorithms wanted: AES_GCM_C(20)_288-NONE(0)_000; flags=-strict
000 "tunnel_10.154.25.149": ESP algorithms loaded: none
000
000 #17: "tunnel_10.154.25.149":500 STATE_PARENT_I1 (sent v2I1, expected v2R1); EVENT_v2_RETRANSMIT in 30s; nodpd; idle; import:local rekey
000

Issue 1275 from www.openswan.org
Created by: Paul Wouters
On Tue Aug 9 12:41:33 2011

Priority: Normal
Status: New

PLUTO_SENDS_VENDORID should reallye be a config setup option and not a compile time option

Issue 1189 from www.openswan.org
Created by: Paul Wouters
On Thu Jan 6 22:14:01 2011

Priority: Normal
Status: Assigned

Add testcase for XAUTH + DPD

This has been reported as not working

Date: Wed, 5 Jan 2011 13:46:05 -0800
From: Murat Sezgin [email protected]
Cc: [email protected]
To: Paul Wouters [email protected]
Subject: Re: [Openswan Users] DPD and XAUTH problem
Parts/Attachments:
1 OK 121 lines Text (charset: ISO-8859-1)

2 Shown ~119 lines Text (charset: ISO-8859-1)

Hi Paul,

I upgraded them (both server and client side) to 2.6.32 but the problem is still here. It works fine if I don't use XAUTH. If I enabled XAUTH the issue happens. The below is the client's log messages which may be critical for DPD. I say "may be", because I am not very familiar with the code.

Have you ever tested openswan's DPD feature with XAUTH enabled? I read from the ipsec.conf man page that the xauth connections cannot to rekey, so I also disabled the rekey on the both sides, but it also did not help. Why I did this? Because on the client side side I see ""xauthclient" #2: DPD: could not find newest phase 1 state",

Issue 169 from www.openswan.org
Created by: Paul Wouters
On Tue Sep 14 13:59:06 2004

Priority: Normal
Status: Assigned

Check for OE records in the reverse and missing OE conns.
This should become part of 'ipsec verify', and possibly 'ipsec livetest'.
This should remind people to not 'just' disable OE when they still have OE records in the reverse.

I've read that LXC containers are supposed to have the capability to support IPSec since kernel 2.6.32, but I have not been able to actually get it setup. I have tried the published packages, installing debian packages from your download site, and compiling from source. All to no avail.

Since you guys are the clear experts in the area, I was hoping some information could be provided on what it would take to build an LXC container (with Docker http://www.docker.io would be awesome, but even w/o would be workable) that can run a L2TP / IPSec VPN server.

Any info would really be appreciated. Thanks so much.

Issue 1034 from www.openswan.org
Created by: Paul Wouters
On Thu Jun 4 15:48:17 2009

Priority: Low
Status: New

eg allow this:
src 172.17.0.0/24 dst 172.19.0.0/24
dir out priority 2344
tmpl src CENTRALIPADDR dst PEERDSL1
proto esp reqid 16397 mode tunnel
src 172.16.0.0/24 dst 172.19.0.0/24
dir out priority 2344
tmpl src CENTRALIPADDR dst PEERDSL2
proto esp reqid 16401 mode tunnel
src 10.0.0.0/8 dst 172.19.0.0/24
dir out priority 2856
tmpl src CENTRALIPADDR dst PEERDSL2
proto esp reqid 16405 mode tunnel

this used to be not possible due to routing limitations, but at least with NETKEY should work.
With KLIPS it might be able to work too but would be harder.

Issue 1347 from www.openswan.org
Created by: Panagiotis Tamtamis
On Thu Mar 22 06:43:13 2012

Priority: Low
Status: New

If a user wants to manipulate this value should have the ability to select whatever value he/she wants.
Right now this option is not available.

Issue 1351 from www.openswan.org
Created by: Steve Lanser
On Tue Mar 27 17:50:33 2012

Priority: High
Status: New

This bug tracks the broader problem around issue #1335 and issue #1350, which is that pluto fails to deal with interface and IP addressing changes dynamically.

Pluto should be responsible for its own dynamic updates when interface IP state or addresses change, and it should deal gracefully with any affected connections. As it is, pluto neither updates its interface bindings automatically, nor does it always deal gracefully with such changes.

As a workaround on our system, we issue an automatic whack --status request when needed to prompt pluto to update its bindings.

In the case of issue #1350, when an interface is turned down, the whack --listen request, after removing deleted IP address bindings, returns errors about failed connection state handling. It should not be attempting to communicate with an unreachable peer, or at least should squelch communication failures in this context, and of course pluto itself should never core dump (which it does some time later).

Restarting pluto is not a great workaround as it is disruptive to ongoing connections, including connections over unaffected interfaces.

Ideally, I think, pluto would perform an internal "auto --down" on connections that become unroutable, resulting in the added-only state it does on startup under the same conditions, e.g. when you see a message like this:

pluto[26733]: "10.8.8.8-to-10.9.9.9": We cannot identify ourselves with either end of this connection.
...
ipsec auto -status
...
000 "10.8.8.8-to-10.9.9.9": 10.8.8.8<10.8.8.8>...10.9.9.9<10.9.9.9>; unrouted; eroute owner: #0
000 "10.8.8.8-to-10.9.9.9":     myip=unset; hisip=unset;

When an IP address makes a connection viable on an interface, it would at that time route the connection and maybe also initiate it (as in "auto --up") depending on the "auto =" setting in the ipsec.conf file.

Another subtlety mentioned in bug #1335 and related to IPv6 is that attempting to bind to an IPv6 address that is not in a usable state (i.e. "preferred" state) will result in a bind error like the following:

Mar 27 13:33:08 tb7 pluto[26733]: ERROR: bind() for ether2/ether2 8675:309::214:22ff:feb1:167a:500 in process_raw_ifaces(). Errno 99: Cannot assign requested address

so the --listen feature needs to be IPv6 address state aware (See RFC 4293).

Issue 478 from www.openswan.org
Created by: Paul Wouters
On Fri Oct 28 08:39:51 2005

Priority: Normal
Status: Assigned

Code we can use from the RFC editor is available at:

http://www.zork.org/gcm/

openswan-2.6.39 + SAref

if I do: service ipsec restart

I get an error:
kernel: [414936.572073] unregister_netdevice: waiting for mast0 to become free. Usage count = 1

Issue 1256 from www.openswan.org
Created by: Paul Wouters
On Thu May 5 16:05:34 2011

Priority: Normal
Status: New

upon down'ing the SA, store the packet/byte counters before the info is lost
openswan-statsd could pass it along with the down message.

Issue 315 from www.openswan.org
Created by: Paul Wouters
On Wed May 18 23:24:10 2005

Priority: Normal
Status: Assigned

request: dpdscript=

script to execute when DPD kills a conn.

Issue 183 from www.openswan.org
Created by: Paul Wouters
On Sun Oct 3 22:04:38 2004

Priority: High
Status: Assigned

ipsec verify --quiet option so people can add it to the subsystem startup.
so major failures show up to people

Issue 171 from www.openswan.org
Created by: Paul Wouters
On Tue Sep 14 14:05:02 2004

Priority: Normal
Status: Assigned

This is twofold:

• When initiating OE and receiving a confirmation about NAT-T, drop the attempt (and possibly follow the policy groups further to see if we are allowed to connect in the clear)
• When responding to OE and receiving a confirmation about NAT-T, refuse all proposals until initiator goes away. Also clear any possible %trap to allow initiator to connect in the clear.

Issue 139 from www.openswan.org
Created by: Paul Wouters
On Wed Jul 7 19:01:15 2004

Priority: High
Status: Assigned

these are known dyndnses

www.dyndns.org
www.no-ip.com
www.dtdns.com
www.changeip.com
www.dynamic-nameserver.com

Issue 321 from www.openswan.org
Created by: Paul Wouters
On Tue May 24 11:06:34 2005

Priority: Normal
Status: Assigned

Implement xauth method that uses MD5/CHAP. Estimate 3-5 days of work.

Issue 125 from www.openswan.org
Created by: Paul Wouters
On Mon Feb 9 19:52:35 2004

Priority: Normal
Status: New

compress=no just means we don't advertise it. If the remote asks compression, we still do it. There seems to be some interop problems with IPCOMP and 2.6 (2.6 people doing it wrong) and therefor some (why not all??) connections with 2.4 KLIPS to 2.6 native fail.

The only current fix is a recompile with CONFIG_IPSEC_IPCOMP disabled.

mcr: paul, re: compress=never, DHR wanted to make it four stated along time ago, for exactly this reason. Henry didn't agree. It stayed that way.
Yes, we should make it four stated, but there is only one flag in pluto, so it takes some work. Let's do it after starter.

Issue 1382 from www.openswan.org
Created by: BOBY ZHB
On Thu Aug 8 11:33:45 2013

Priority: Normal
Status: New

ipsec version

Linux Openswan U2.6.32/K2.6.32-358.el6.x86_64 (netkey)

192.168.22.0/24===1.1.1.2<1.1.1.2>[@hsw.com,+S=C]---1.1.1.1...1.1.1.22<1.1.1.22>[+S=C]===192.168.16.0/20;
Left subnet：192.168.22.0/24
Right subnet：192.168.16.0/20

PC(192.168.22.14) ssh connection 192.168.22.1 failed.

ip xfrm state

src 192.168.22.1 dst 192.168.22.14
proto esp spi 0x00000000 reqid 0 mode transport
replay-window 0
sel src 192.168.22.1/32 dst 192.168.22.14/32 proto tcp sport 22 dport 55757

ip addr list

2: eth0: inet 1.1.1.2/24 brd 1.1.1.255 scope global eth0
3: eth1: inet 192.168.22.1/24 brd 192.168.22.255 scope global eth1

Issue 1304 from www.openswan.org
Created by: Germano Michel
On Mon Feb 6 15:17:09 2012

Priority: Normal
Status: New

Version 2.6.37 of KLIPS has no netns support. If one starts ipsec on a namespace the init script complains about not having KLIPS on the kernel since it can't find /proc/net/ipsec/...
Is there any work in progress regarding this? I'm quite sure there is none.

This feature is very important (at least to me) and I'm interested in implementing it.
I would like opinions on what should be modified in order to support NETNS. I have already studied it a bit and found that the /proc filesystem needs to be netns aware. But I'm not sure what to do with the ixs_cache_allocator and some other stuff, so comments are very welcome.

Just joined the project.

Thanks,
Germano

Issue 911 from www.openswan.org
Created by: Marco Berizzi
On Mon Mar 3 12:11:20 2008

Priority: High
Status: New

righsubnetwithin parameters on 2.5.17 is unsupported.
Now all private subnet must be defined on virtual_private. Unfortunately a restart is required to update virtual_private.
I would like to do an ipsec auto --replace connection_name and the virtual_private is refreshed.

Issue 1208 from www.openswan.org
Created by: Ruben Laban
On Fri Feb 11 14:34:29 2011

Priority: Normal
Status: New

Scenario:
left has a full BGP table without a default route.
right has a subnet that's not within an BGP advertised network.

Problem:
After bringing up a tunnel between left(subnet) and right(subnet), one can't ping from left to rightsubnet, because of "no route to host".

Possible solution:
Add an "addroute=yes/no" option to ipsec.conf which would add a route to rightsubnet pointing to the uplink interface (any other interface doesn't work) upon tunnel establishment.

Remark:
I haven't tested this with IPv4, yet. The problem does exist at least with IPv6.

Issue 92 from www.openswan.org
Created by: Paul Wouters
On Wed Nov 5 14:31:43 2003

Priority: High
Status: Assigned

The private key for a roadwarrior connection using
raw RSA keys must always be the first one in
ipsec.secrets and only a single anonymous key is
allowed. private keys which match a certificate
follow after that entry and there can be an unlimited
number of such private keys.

Issue 1368 from www.openswan.org
Created by: ali lia
On Tue Oct 9 07:02:39 2012

Priority: High
Status: New

please, tell me how can i cross compiling openswan to powerpc processor?