[Swan] Problem with NAT and Dynamic IP address change
I have recently upgraded from Openswan to Libreswan (1.13) on Ubuntu
14.4 and there seems to be a problem with NAT and dynamic IP addresses
that is a regression from Openswan (Ubuntu default version).
The scenario is a simple one, with a server on a fixed IP Address and a
client system behind a NAT gateway on a dynamic IP Address.
The upgrade from Openswan went fine with the only issue being having to
convert from the old style locations of certs and keys to NSS, and all
continues to work fine until I get a dynamic IP address change, when the
SA goes out of sync, communication is lost and cannot be recovered until
I explicitly reset the connection on the non-NAT system. Automatic
recovery is completely lost.
On the non NAT system:
conn
authby=rsasig
type=tunnel
ike=3des-sha1;modp2048
phase2alg=3des-sha1;modp2048
dpddelay=30
dpdtimeout=120
dpdaction=clear
left=my ip
leftcert=alice
leftrsasigkey=%cert
leftid=%fromcert
rightca=my ca
right=%any
rightsubnet=vhost:%no,%priv
rightrsasigkey=%cert
rightid=other cert - no wild cards
auto=add
and on the NATTED system:
conn defaults
authby=rsasig
type=tunnel
ike=3des-sha1;modp2048
phase2alg=3des-sha1;modp2048
dpddelay=30
dpdtimeout=120
dpdaction=restart
left=%defaultroute
leftcert=bob
leftrsasigkey=%cert
leftid=%fromcert
rightca=my ca
right=server.domain.name
rightrsasigkey=%cert
rightid= server's cert
auto=start
This all goes fine until the NAT gateway resets (we seem to get a line
glitch about once a day at the moment) , and the dynamic IP address
changes. Instead of this being recognised and recovered from (following
RFC 3947), the non-NAT system seems to get locked into a problem state.
With Openswan this scenario worked fine and the occasional time there
was a problem it was sufficient to reset the connection from the NATTED
system.
running ipsec auto status on the non NAT system gives
...
ENT_CRYPTO_FAILED in 3s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
000 #3931: blackswan[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting
QI1); EVENT_CRYPTO_FAILED in 3s; lastdpd=-1s(seq in:0 out:0); idle;
import:not set
000 #3930: blackswan[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting
QI1); EVENT_CRYPTO_FAILED in 2s; lastdpd=-1s(seq in:0 out:0); idle;
import:not set
000 #3929: blackswan[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting
QI1); EVENT_CRYPTO_FAILED in 2s; lastdpd=-1s(seq in:0 out:0); idle;
import:not set
000 #3928: blackswan[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting
QI1); EVENT_CRYPTO_FAILED in 2s; lastdpd=-1s(seq in:0 out:0); idle;
import:not set
000 #3927: blackswan[5] 86.181.114.105:4500 STATE_QUICK_R0 (expecting
QI1); EVENT_CRYPTO_FAILED in 1s; lastdpd=-1s(seq in:0 out:0); idle;
import:not set
000 #1262: blackswan[5] 86.181.114.105:4500 STATE_MAIN_R3 (sent MR3,
ISAKMP SA established); EVENT_SA_REPLACE in 630s; newest ISAKMP;
lastdpd=2640s(seq in:22161 out:0); idle; import:not set
which seems to imply that the ISAKMP SA is up but there is a problem
with the ipsec tunnel.
If I then enter
ipsec auto --down blackswan
I see
002 blackswan #7786: deleting state (STATE_QUICK_R0)
002 blackswan #7785: deleting state (STATE_QUICK_R0)
002 blackswan #7784: deleting state (STATE_QUICK_R0)
002 blackswan #7783: deleting state (STATE_QUICK_R0)
002 blackswan #7782: deleting state (STATE_QUICK_R0)
002 blackswan #7781: deleting state (STATE_QUICK_R0)
002 blackswan #7780: deleting state (STATE_QUICK_R0)
002 blackswan #7779: deleting state (STATE_QUICK_R0)
002 blackswan #7778: deleting state (STATE_QUICK_R0)
002 blackswan #4740: deleting state (STATE_MAIN_R3)
002 blackswan[5] 86.181.114.105: deleting connection blackswan
instance with peer 86.181.114.105 {isakmp=#0/ipsec=#0}
002 blackswan[4] 86.181.114.105: terminating SAs using this connection
002 blackswan #38: deleting state (STATE_QUICK_R2)
005 blackswan #38: ESP traffic information: in=2708MB out=762KB
003 blackswan #38: ERROR: netlink response for Del SA
esp.193d61d2@86.181.114.105 included errno 3: No such process
002 blackswan[4] 86.181.114.105: deleting connection blackswan
instance with peer 86.181.114.105 {isakmp=#0/ipsec=#0}
The connection then comes back up again - as the other side is still
knocking at the door - and communication is restored.
Any ideas on what is going wrong?
Tony Whyman
MWA
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
[Swan] Getting Libswan 1.14rc3 to compile under Ubuntu precise
The following patch appears necessary to get 1.14rc3 debian packages to
compile under Ubuntu precise. This applies two changes:
1. Correct error in version no. syntax in the debian/changelog
2. Allow code to compile with libubound versions 1.4.21 i.e. when the
prototype for ub_ctx_add_ta was change - 2nd argument from char 8 to
const char *. Note: the macro UNBOUND_VERSION_MAJOR only seems to have
appeared in unbound.h from 1.4.21 onwards.
Tony Whyman
MWA
diff -rupN libreswan-3.14rc3.orig/debian/changelog
libreswan-3.14rc3/debian/changelog
--- libreswan-3.14rc3.orig/debian/changelog2015-06-30
01:48:45.0 +0100
+++ libreswan-3.14rc3/debian/changelog2015-07-04 23:38:12.671042000
+0100
@@ -1,4 +1,4 @@
-libreswan (1:v3.14~rc3-1) precise; urgency=low
+libreswan (1:3.14~rc3-1) precise; urgency=low
* Update to v3.14rc3-1
diff -rupN libreswan-3.14rc3.orig/lib/libswan/unbound.c
libreswan-3.14rc3/lib/libswan/unbound.c
--- libreswan-3.14rc3.orig/lib/libswan/unbound.c2015-06-29
17:23:47.0 +0100
+++ libreswan-3.14rc3/lib/libswan/unbound.c2015-07-04
23:38:03.943056000 +0100
@@ -87,7 +87,11 @@ bool unbound_init(struct ub_ctx *dnsctx)
DBG(DBG_DNS,
DBG_log(Loading root key:%s, rootanchor);
);
+#ifdef UNBOUND_VERSION_MAJOR
ugh = ub_ctx_add_ta(dnsctx, rootanchor);
+#else
+ugh = ub_ctx_add_ta(dnsctx, (char*) rootanchor);
+#endif
if (ugh != 0) {
libreswan_log(error adding the DNSSEC root key: %s: %s,
ub_strerror(ugh), strerror(errno));
@@ -98,7 +102,11 @@ bool unbound_init(struct ub_ctx *dnsctx)
DBG(DBG_DNS,
DBG_log(Loading dlv key:%s, dlvanchor);
);
+#ifdef UNBOUND_VERSION_MAJOR
ugh = ub_ctx_set_option(dnsctx, dlv-anchor:, dlvanchor);
+#else
+ugh = ub_ctx_set_option(dnsctx, dlv-anchor:,(char *) dlvanchor);
+#endif
if (ugh != 0) {
libreswan_log(error adding the DLV key: %s: %s,
ub_strerror(ugh), strerror(errno));
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] 3.14rc2 and 3.14rc3 do not compile under Ubuntu Precise
Investigating further, it looks like the prototype for ub_ctx_add_ta has changed from int ub_ctx_add_ta(struct ub_ctx* ctx, char* ta); in unbound 1.4.16, to int ub_ctx_add_ta(struct ub_ctx* ctx, const char* ta); in ubound 1.4.22 (or earlier) The definition of rootanchor, now static const char rootanchor[] /*line 35 of lib/libswan/unbound.c */ probably needs to be conditional on the version number of unbound.h Tony Whyman MWA On 04/07/15 13:43, Tony Whyman wrote: I have tried the new 3.14rc3 and 3.14rc2, trying to build each under Ubuntu Precise (12.04 LTS) and Trusty (14.04 LTS). Both compile under 14.04 but fail to compile under 12.04 with the following error messages: In function 'unbound_init': snip/unbound.c:90:2: error: passing argument 2 of 'ub_ctx_add_ta' discards 'const' qualifier from pointer target type [-Werror] /usr/include/unbound.h:331:5: note: expected 'char *' but argument is of type 'const char *' snip/lib/libswan/unbound.c:101:2: error: passing argument 3 of 'ub_ctx_set_option' discards 'const' qualifier from pointer target type [-Werror] /usr/include/unbound.h:242:5: note: expected 'char *' but argument is of type 'const char *' rc3.14rc3 also fails to build the debian packages due to a corrupt version string in debian/changelog. It will compile when changed to libreswan (1:3.14~rc3-1) precise; urgency=low Note: rather odd that the changelog specifies precise when it can't compile under precise Tony Whyman MWA ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Does libreswan 1.15 have a problem with spaces in CA common names/nicknames
Ubuntu 14.04 uses 3.19.2. On 08/09/15 20:44, Paul Wouters wrote: Our tests used nss-3.18.0-1.fc21. ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Does libreswan 1.15 have a problem with spaces in CA common names/nicknames
Paul, Thanks for getting back. If you look down my original EMail, I have already tried: certutil -V -d sql:/etc/ipsec.d -n "MWA Root CA" -u C certutil: certificate is invalid: Peer's certificate issuer has been marked as not trusted by the user. rebecca ~ # certutil -M -d sql:/etc/ipsec.d -n "MWA Root CA" -t "CT," rebecca ~ # certutil -V -d sql:/etc/ipsec.d -n "MWA Root CA" -u C certutil: certificate is valid but with no luck. I noted that your suggestion had two "," in it, so tried that as well, just in case, but still the same result. There are probably two problems here. The first is with the import script. I had a good look at the updated script, hence the above. It looks like it is not parsing the cert nickname correctly when there is a space in it - hence the error message - but this is recoverable by explicit use of certutil. The bigger problem is why does the authentication still fail. This worked before with 1.13 and works with Openswan using the same certificates. I have also purged all old copies of libreswan and openswan from the test system to try and get it to a well known state, in case that was the problem. I am thus guessing that because of the parse problem in the import script, no one has actually tested 1.15 with a CA having spaces in its nickname - hence this is why I think that this is where the problem lies. Tony Whyman MWA On 08/09/15 13:33, Paul Wouters wrote: On Tue, 8 Sep 2015, Tony Whyman wrote: Subject: [Swan] Does libreswan 1.15 have a problem with spaces in CA common names/nicknames certutil -L -d sql:/etc/ipsec.d Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI rebecca.mwassocs.co.uk u,u,u MWA Root CA ,, You are missing the trust bits on your CA certificate. Upgrading should have caused you to run ipsec --checknss which should have added the trust bits for you. I wonder what that did not happen. try: certutil -M -d sql:/etc/ipsec.d -n "MWA Root CA" -t 'CT,,' Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Does libreswan 1.15 have a problem with spaces in CA common names/nicknames
Paul,
That set me on the right track. I was using a simple test CA certificate
which has been around for a long time with a 1024 bit signing key.
Replacing this with a new test CA with a 4096 bit key solved the
authentication problem. Is withdrawal of support for 1024 bit keys
declared anywhere?
There is definitely a bug in the ipsec (import) script when the CA name
has spaces. I have crudely fixed it by amending line 80 to
certutil -L -d "${IPSEC_NSSDIR_SQL}" | egrep -v 'Certificate|MIME' | awk
'{$NF=""; print $0}' | awk '{gsub(/^ +| +$/,"")}'| grep -v "^$" | while
read -r cert; do
There may be a better way but this seems to remove the trailing white
space that was causing the problem for me.
Tony Whyman
MWA
On 08/09/15 16:06, Paul Wouters wrote:
Ok, then your issue has not been the update of the nss database. Your
problem then lies in the fact that we now use NSS for the certificate
validation instead of the very old freeswan based x509*.c code.
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Does libreswan 1.15 have a problem with spaces in CA common names/nicknames
Paul,
One more point, I modified /usr/sbin/ipsec: set_db_trust to see what was
happening i.e.
set_db_trusts() {
# has to handle a NSS nick with spaces
certutil -L -d "${IPSEC_NSSDIR_SQL}" | egrep -v 'Certificate|MIME'
| awk '{$NF=""; print $0}' | grep -v "^$" | while read -r cert; do
echo "Trying '$cert'"
if certutil -L -d ${IPSEC_NSSDIR_SQL} -n "${cert}" | grep -q
'Is a CA' &&
[ $(certutil -L -d ${IPSEC_NSSDIR_SQL} -n "${cert}" | grep -i
-A3 'ssl flags' | grep -i 'trusted' | wc -l) -ne 2 ]; then
echo "correcting trust bits for ${cert}"
certutil -M -d "${IPSEC_NSSDIR_SQL}" -n "${cert}" -t 'CT,,'
fi
done
}
note the echo statement.
The result of running the script is now:
pk12util: PKCS12 IMPORT SUCCESSFUL
Trying 'rebecca.mwassocs.co.uk'
Trying 'MWA Root CA '
certutil: Could not find cert: MWA Root CA
: PR_FILE_NOT_FOUND_ERROR: File not found
Note the space at the end of the "cert" variable. This is why the script
fails.
Tony Whyman
MWA
On 08/09/15 15:21, Tony Whyman wrote:
Paul,
Thanks for getting back. If you look down my original EMail, I have
already tried:
certutil -V -d sql:/etc/ipsec.d -n "MWA Root CA" -u C
certutil: certificate is invalid: Peer's certificate issuer has been
marked as not trusted by the user.
rebecca ~ # certutil -M -d sql:/etc/ipsec.d -n "MWA Root CA" -t "CT,"
rebecca ~ # certutil -V -d sql:/etc/ipsec.d -n "MWA Root CA" -u C
certutil: certificate is valid
but with no luck. I noted that your suggestion had two "," in it, so
tried that as well, just in case, but still the same result.
There are probably two problems here. The first is with the import
script. I had a good look at the updated script, hence the above. It
looks like it is not parsing the cert nickname correctly when there is
a space in it - hence the error message - but this is recoverable by
explicit use of certutil. The bigger problem is why does the
authentication still fail. This worked before with 1.13 and works with
Openswan using the same certificates.
I have also purged all old copies of libreswan and openswan from the
test system to try and get it to a well known state, in case that was
the problem.
I am thus guessing that because of the parse problem in the import
script, no one has actually tested 1.15 with a CA having spaces in its
nickname - hence this is why I think that this is where the problem lies.
Tony Whyman
MWA
On 08/09/15 13:33, Paul Wouters wrote:
On Tue, 8 Sep 2015, Tony Whyman wrote:
Subject: [Swan] Does libreswan 1.15 have a problem with spaces in CA
common
names/nicknames
certutil -L -d sql:/etc/ipsec.d
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
rebecca.mwassocs.co.uk u,u,u
MWA Root CA ,,
You are missing the trust bits on your CA certificate. Upgrading should
have caused you to run ipsec --checknss which should have added the
trust bits for you. I wonder what that did not happen.
try:
certutil -M -d sql:/etc/ipsec.d -n "MWA Root CA" -t 'CT,,'
Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Please review: docuemntation of openswan to libreswan migration
Some very quick feedback. I migrated our systems earlier this year from Openswan on Ubuntu to Libreswan. Coming from this background the big issue was NSS. All the Ubuntu systems were set up with X.509 certificates and private keys in separate files and suddenly there was a need for know about this weird thing called NSS and, before that, why doesn't Libreswan recognise my existing certificates etc. Hence, the first thing I looked for on the HowTo was a big upfront warning about the change to NSS. There is some text on this later on, but it is easy to miss the significance of this and, where are the links to the wiki page on NSS - which would be so useful for someone coming from this background. Thus my feedback is that the removal of the X.509 file support and the need to understand how to use NSS should be right up front together with the link to the NSS page. Regards Tony Whyman MWA On 09/12/15 14:45, Paul Wouters wrote: Hi, I've expanded the openswan migration document to contain a lot more information about possible changed behaviour and manual changes needed for a smooth migration from openswan to libreswan. If you have done this migration, it would be great if you could have a look at the document and tell me if you ran into anything that isn't mentioned on this page: https://libreswan.org/wiki/HOWTO:_openswan_to_libreswan_migration Note that this mostly talks about openswan -> libreswan-3.15+ Some people have found issues in migrating with earlier libreswan versions, which we have addressed since then. The reason I did the write up is to better support those running RHEL6 that are going to migrate from openswan to libreswan voluntarily in RHEL-6.7 (using the Extras channel), or when forced to migrate in RHEL-6.8. Thanks! Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Please review: docuemntation of openswan to libreswan migration
Supplementing my original point - I've gone through the notes I made when converting from Ubuntu/Openswan to Libreswan and, apart from the NSS issue, it was generally very straightforward, especially for a "standard" VPN type configuration. The only other issue of note comes from building Libreswan as deb packages and installing from .deb files. In this case, Libreswan was installed (under Ubuntu) as an upstart job while Openswan had been a System V Init script install. This caused some initial confusion as /etc/init.d/ipsec had for some reason not been removed when the Libreswan package was installed (I used my own repository and apt-get). I was also used to controlling pluto by using commands such as "/etc/init.d/ipsec restart" when the VPN needed to be kicked back into life. With Libreswan, I need to use "ipsec restart" instead. It's these small differences that, in practice, affect the user much more than the build time parameter changes. Tony On 09/12/15 23:07, Tom Robinson wrote: On 10/12/15 02:03, Tony Whyman wrote: Thus my feedback is that the removal of the X.509 file support and the need to understand how to use NSS should be right up front together with the link to the NSS page. I also found this to be the most challenging thing when migrating in the last few months. ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Problem with subnet-to-subnet setup behind NAT'ed networks
Jacob,
I have a similar and working setup using Libreswan/Ubuntu. The main
difference is that I have the tunnels working peer-to-peer rather than
subnet-to-subnet and it may be worth your while testing and proving the
peer to peer case before moving to the subnet-to-subnet case.
Otherwise, I can only see two differences in the configuration:
1. You have used left/rightsourceip while I have not (probably not
significant).
2.In my case I have an asymmetric tunnel establishment i.e. one side
is "auto=add". This may be significant when it comes to the NAT
gateways. The passive side also has a dpdaction of clear.
The NAT gateways are also set up to forward all incoming port 500/4500
UDP to the secure gateways.
Good luck
Tony Whyman
On 11/02/16 12:59, Jacob Vind wrote:
Hi,
I really hope we can get some help, we are trying to set up a
subnet-to-subnet Libreswan based IPSEC connection between two sites of
ours. But we are having problems with it, we can get it to startup and
working for a while (time varies from few minutes to hours). I hope
someone will help review the config and log and come with suggestions.
First a simple network diagram of the setup can be seen here:
https://www.evernote.com/l/AR8bgtmQgg5B0oT3ZWWdgQ2DL5_I-I7HqKA
I figure that might make it easier to understand the setup. As you can
see we operate with two private subnets on each side. Below are
librewan config from left and right side (just edited so the public IP
is not visible and not the entire key):
LEFT:
--- BEGIN ---
conn adsubnets
also=sj-dtu-tunnel
leftsubnet=172.16.1.0/24
leftsourceip=172.16.1.253
rightsubnet=172.16.0.0/24
rightsourceip=172.16.0.253
forceencaps=yes
nat-keepalive=yes
conn sj-dtu-tunnel
leftid=@SJ
left=192.168.3.212
leftrsasigkey=0sAQOkPvSdH [...] NzpthMaVxQ==
rightid=@DTU
right=77.X.X.X
rightrsasigkey=0sAQOx3MfD [...] oJGYM1tc5cJB
authby=rsasig
# load and initiate automatically
auto=start
--- END ---
The default gw of this machine is 192.168.3.254
RIGHT:
--- BEGIN ---
conn adsubnets
also=sj-dtu-tunnel
leftsubnet=172.16.1.0/24
leftsourceip=172.16.1.253
rightsubnet=172.16.0.0/24
rightsourceip=172.16.0.253
forceencaps=yes
nat-keepalive=yes
conn sj-dtu-tunnel
leftid=@SJ
left=70.X.X.X
leftrsasigkey=0sAQOkPvSdH [...] NzpthMaVxQ==
rightid=@DTU
right=192.168.13.238
rightrsasigkey=0sAQOx3MfD [...] oJGYM1tc5cJB
authby=rsasig
# load and initiate automatically
auto=start
--- END ---
The default gw of this machine is 192.168.13.254
rightsourceip
We have made iptables rules so UDP ports 4500 and 500 can pass all the
way, of course both ways. Both ipsec routers are running Centos7, and
we have installed your latest version 3.16-1 (we first tried with 3.15
which ships with CentOS, had same failure with that.
Below is some log from the left side machine, where I have included
lines from around where it stops working and starts working again. We
monitor with ping when it stops working, and it is not because the
internet connection between the two sides are unavailable.
Anything we are missing? Any input will be highly appreciated.
Also please let me know if you need more information from me.
Thanks.
Best Regards
Jacob Vind.
Feb 9 13:29:38 adrouter01-sj pluto[3245]: "mysubnet" #15: initiating
Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
to replace #4 {using isakmp#14 msgid:ae9942a9 proposal=defaults
pfsgroup=OAKLEY_GROUP_MODP2048}
Feb 9 13:29:38 adrouter01-sj pluto[3245]: "mysubnet" #15: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2
Feb 9 13:29:38 adrouter01-sj pluto[3245]: "mysubnet" #15:
STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
{ESP/NAT=>0xf21e014b <0x9a31be7b xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD= 77.X.X.X:4500 DPD=passive}
Feb 9 13:32 PING TO OTHER SIDE STOPS RESPONDING
Feb 9 13:33:15 adrouter01-sj pluto[3245]: "sj-dtu-tunnel" #16:
initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
to replace #2 {using isakmp#14 msgid:ae8e6273 proposal=defaults
pfsgroup=OAKLEY_GROUP_MODP2048}
Feb 9 13:33:16 adrouter01-sj pluto[3245]: "sj-dtu-tunnel" #16:
transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Feb 9 13:33:16 adrouter01-sj pluto[3245]: "sj-dtu-tunnel" #16:
STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
{ESP/NAT=>0x0aeaae7f <0x277fbba9 xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD= 77.X.X.X:4500 DPD=passive}
Feb 9 21:12:04 adrouter01-sj pluto[3245]: "mysubnet" #26: initiating
Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
to replace #15 {using isakmp#25 msgid:f0fa5ae3 proposal=defaults
pfsgroup=OAKLEY_GROUP_MODP2048}
Feb
[Swan] IPsec Multicast
Are there any plans to implement RFC 5374 in libreswan? Tony Whyman MWA ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] IPsec Multicast
Paul, I think you have answered the question. I was really just trying to get a feel for what state IPsec multicast may be in. I am working the requirements for a group of applications that are naturally multicast and also have a strong requirement for data origin authentication. So naturally, I am looking to see what may be out there at present. Regards Tony Whyman MWA On 19/05/16 16:33, Paul Wouters wrote: If you look at https://tools.ietf.org/html/rfc6071#section-6 There isn't really a method that I know to add this to IKEv2 ? So I am not sure what he exact feature is that you are asking for. It is unlikely we would add it to ikev1 unless someone else writes the code. Paul Sent from my iPhone On May 19, 2016, at 09:10, Tony Whyman <tony.why...@mccallumwhyman.com> wrote: Are there any plans to implement RFC 5374 in libreswan? Tony Whyman MWA ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan] Tunnel up/down events
Is there any way to reacting to an ipsec tunnel up/down event in (e.g.) /etc/network/if-up.d or through udev? Regards Tony Whyman MWA ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan] Has this bug been reported yet?
Just installed a new server with ubuntu 16.04 on board and a fresh
installation of libreswan 3.19 compiled as a deb package. Tried to
initialise the nss database with
ipsec initnss
and got the error:
/usr/sbin/ipsec: 319: /usr/sbin/ipsec: =0: not found
/usr/sbin/ipsec: 320: [: -ne: unexpected operator
Looks like a simple script error. Line 319 is
${rc}=$?
and changing it to
let ${rc}=$?
seems to fix the problem.
Regards
Tony Whyman
MWA
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] [Swan-announce] Libreswan 3.21 released
There seems to be a compatibility problem when compiling under Ubuntu 14.04 (trusty). I can compile this release under Ubuntu 16.04 (xenial), abeit only after adding new dependencies: libsystemd-dev and libldns-dev (could be useful to add checks for these dependencies to the configure script). However, when compiling in a 14.04 environment, I get the error message: libreswan-3.21/programs/pluto/pluto_sd.c:29:2: error: implicit declaration of function 'sd_watchdog_enabled' [-Werror=implicit-function-declaration] int ret = sd_watchdog_enabled(0, _usecs); Digging deeper, "sd_watchdog_enabled" is not part of systemd/sd-daemon.h in the 14.04 distribution, but is present in the 16.04 distribution. It looks like the new version of libreswan will only compile with a recent version of the systemd libraries. Is this intentional and has support for older distributions been dropped? Note: Ubuntu 14.04/Mint 17 is an LTS release and is still in wide use. Tony Whyman On 10/08/17 02:34, The Libreswan Project wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The Libreswan Project has released libreswan-3.21 This is a bugfix and feature release. New Features: This release features Opportunistic IPsec using DNSSEC lookups of IPSECKEY records. It also adds support for the DNSSEC root key rollover that is currently happening with support for loading new DNSSEC trust anchors from disk. If using DNSSECi with libreswan, please upgrade to this version before October 10, 2017. Support for hardware offloading for certain NIC cards (such as Mellanox) was added. PFS support was added to the CREATE_CHILD_SA Exchange. Important bugfixes: The ID handling code is now more strict when using certificates. Any ID configured via leftid= or rightid= MUST either be the certificate DN or be a SubjectAltName (SAN) on the certificate. A race condition in the threading code was fixed that could cause pluto to crash on loaded systems that use IKEv1 XAUTH or IKEv2 PAM authentication. A crasher in FIPS mode when input to hashing algorithms was too weak was fixed. Compatiblity changes: The above mentioned stricter ID handling can cause existing connections to fail if a SubjectAltName is missing from a certificate whose ID is specified specified in the connection. You can download libreswan via https at: https: //download.libreswan.org/libreswan-3.21.tar.gz https: //download.libreswan.org/libreswan-3.21.tar.gz.asc The full changelog is available at: https: //download.libreswan.org/CHANGES Please report bugs either via one of the mailinglists or at our bug tracker: https: //lists.libreswan.org/ https: //bugs.libreswan.org/ Binary packages for RHEL/EPEL and Debian/Ubuntu can be found at https: //download.libreswan.org/binaries/ Binary packages for Fedora and Debian should be available in their respective repositories a few days after this release. See also https://libreswan.org/ v3.21 (August 9, 2017) * FIPS: Don't crash on too weak PSK's in FIPS mode, warn for non-FIPS [Andrew] * FIPS: rsasigkey: Use modulus F4, not 3 (FIPS 186-4, section B.3.1) [Paul] * pluto: Support for "idXXX" esp/ike transform IDs removed [Andrew,Paul] * pluto: Do not return whack error when termining an alias connection [Paul] * pluto: Remove IKE policy bits on passthrough conns [Paul] * pluto: Minor memory leak fixes [Paul] * pluto: Fix memory leak due to addresspool reference count error [Antony] * pluto: Re-add support for ipsec whack --listevents [Antony] * pluto: Cleanup listed events on shutdown to please leak-detective [Antony] * pluto: Perform stricter SubjectAltName checks on configured ID's [Paul] * pluto: Handle *subnets in --route and --unroute via whack [Mika/Tuomo] * pluto: Unify IKEv1 XAUTH and IKEv2 PAM threading code [Andrew] * pluto: Use pthread_cancel() (not SIGINT, conflicts with debuggers) [Andrew] * pluto: Fix memory corruption with XAUTH/PAM threads [Andrew/Hugh] * pluto: Fix resource leak processing XAUTH password authentication [Andrew] * pluto: Fix warnings generated by gcc 7.1 [Lubomir Rintel] * pluto: NIC offload support nic-offload=auto|yes|no (eg mellanox) [Ilan Tayari] * pluto: Use common function in ikev1 / ikev2 for dpd/liveness actions [Antony] * NSS: Try harder finding private keys that reside on hardware tokens [Andrew] * IKEv2: Opportunistic IPsec support for IPSECKEY records [Antony] * IKEv2: New dnssec-enable=yes|no, dnssec-rootkey-file=, dnssec-anchors= [Paul] * IKEv2: If CREATE_CHILD_SA superseded retransmit, drop it [Antony] * IKEv2: Add PFS support for CREATE_CHILD_SA (RFC7296 1.3.1) [Antony] * IKEv2: Add PFS support for CREATE_CHILD_SA (RFC7296 1.3.2 responder) [Antony] * IKEv2: Add PFS support for CREATE_CHILD_SA (RFC7296 1.3.3 responder) [Antony] * IKEv2: Flush ESP/AH proposals on the initiator. It could be stale [Antony] * IKEv2: State Machine (svm) updates to simplify CREATE_CHILD_SA [Antony] * IKEv2: DH role is based on messa
[Swan] LIbreswan 3.25 and dual stack ipv4 and ipv6
I've been experimenting with Libreswan 3.25 and setting up tunnels between two dual stack (ipv4 and ipv6) systems. The objective is to migrate to ipv6 for all IPsec tunnels. It seems that both IPv4 and IPv6 tunnels can be established - but with issues and some awkward configuration entries. The implementation looks buggy. The scenario is: Both Client and Server are ubuntu 16.04 with up-to-date kernels. Server is configured with both A and records in the DNS for the same domain name. The former gives its IPv4 address and the second its IPv6 address. This setup works fine for Apache, Sendmail, etc. "netstat -tl" implies that Pluto is listening on all interfaces (ipv4 and ipv6) Initial Server Side configuration is conn defaults authby=rsasig type=tunnel dpddelay=30 dpdtimeout=120 left=%defaultroute leftcert="" leftrsasigkey=%cert leftid=%fromcert mtu=1420 conn client right=%any rightsubnet=vhost:%no,%priv rightrsasigkey=%cert rightid="" also=defaults auto=add Client Side Configuration is: conn defaults authby=rsasig type=tunnel dpddelay=30 dpdtimeout=120 dpdaction=restart left=%defaultroute leftcert="" leftrsasigkey=%cert leftid=%fromcert mtu=1420 conn server right= rightrsasigkey=%cert rightid="" also=defaults auto=add While the above worked fine with the original IPv4 only stack, with dual stack it fails with 022 "server": We cannot identify ourselves with either end of this connection. or 0.0.0.0 are not usable However, changing the Client config slightly so that right= it works! Pluto seems to have got confused when both A and records exist for the same domain name. Oddly, if I now try a slightly different combination: left= I get a different error: 003 ERROR: "server" #3: sendto on enp2s0 to :500 failed in EVENT_v1_RETRANSMIT. Errno 101: Network is unreachable Why it now wants to use to server's ipv4 address in this test is a mystery given the above. Now making a further change to the Client config right= appears to get to a state where the client is initiating main mode but then retransmitting without a response. The Pluto log on the server side records: packet from :500: initial Main Mode message received on authorized with policy RSASIG+IKEV1_ALLOW However, changing the server side to left= right= and it works! An ipv6 in ipv6 tunnel is established. Conclusion There seem to be two problem areas: 1. The interpretation of "%defaultroute". On a dual stack system this always seems to be the IPv4 interface. This applies to both outgoing connections and when matching an incoming connection to a configuration. I have tried using ::0 as a "default" for IPv6, but to no avail. It looks like it has to be an explicit IPv6 address to work. 2. The interpretation of DNS results when both A and records exists for the same DNS Name. I would have expected that the record would always be the default choice and that the source interface (%defaultroute) would follow the address family. But that does not appear to be the case. There also appears to be no mechanism to force IPv4 or IPv6 no that "connaddrfamily" has been obsoleted. The result of all this is that it appears that with dual stack systems, explicit IP addresses have to be used if you are to have any chance at all of establishing IPsec tunnels, and the only time when "left=%defaultroute" is workable is when "right=". Regards Tony Whyman MWA ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
