[Swan] NSS transition questions

Philippe Vouters philippe.vouters at laposte.net
Thu May 23 13:07:57 EEST 2013


Dear Greg,

I reply to you according to what I understand from both your point of 
view and my experience with Libreswan/Openswan. While starting to use 
Libreswan/Openswan, I first used the PSK secrets notion which I found 
simple enough to start with. For this I used and still use the 
/etc/ipsec.d/ipsec.secrets.

While making things a little more complex, I used OpenSSL certificates. 
In my first attempts, I found it simple enough to store the certificates 
into /etc/ipsec.d/cacerts. Although I did not checked lately, my belief 
is that this directory for this purpose should still be also valid.

However and as of today, I use the NSS facility for storing the OpenSSL 
certificates I generated. I did not find NSS that much complex to use 
and NSS seems to be a good follow-up to the /etc/ipsec.d/cacerts 
facility. Although it has been discussed, CRLs, if you use them, ought 
to still have to be stored into /etc/ipsec.d/clrs. Unless otherwise 
stated by someone else, CRLs fetching have not been yet worked upon so 
that you can currently store them into a NSS database.

Except the actual value of the PSK key, you can see how I am today 
organized regarding Libreswan/Openswan by reading the following Web 
documents on my Web site in this order. They denotes my progression 
toward emulating an enterprise class VPN such as I knew and benefited 
from while working at HP:
http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven.html
http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven-Part_2.html
http://vouters.dyndns.org/tima/Linux-Shrew-VPN-Client-Setting_an_Intranet_VPN_with_Windows_Seven-Part_3.html
http://vouters.dyndns.org/tima/Linux-Libreswan-Shrew-VPN-Testing_PAM_XAUTH_DHCP_with_Shrew.html

In the hope this mail will address parts or all of your concerns.

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

On 05/23/2013 11:06 AM, Greg Scott wrote:
> Looking forward to a long run with Libreswan - great to find you again!   I noticed a thread saying Libreswan now only uses NSS.  Is the old way with the key stored directly in ipsec.secrets and hostkey.secrets now gone forever?
>
> If now forced to use NSS, is there a way to import old pre shared keys into an NSS database?  Here is the use case.  I have a central site with several branch sites, all running  various versions of Openswan.  Historically, when the time came to update any of these sites with new hardware, I could just copy the ipsec.secrets and hostkey.secrets file from the old to the new and everyone was happy.
>
> But with NSS, I have to generate new keys and modify CONN definitions all over the place because there was no way to import the older hostkey.secrets keys into a new NSS database.   So any time any site changed to/from NSS, I had to modify CONN definitions at the central site, which could potentially affect all sites if I wasn't careful.
>
> That was my major beef against NSS when Openswan first started using it.  Also, installing directly from the  .tar.gz sources had no provision to include NSS as I recall.  RPM builds included NSS, but source builds from .tar.gz files did not, and since new RPMs for any given Fedora release stop coming after a year or so, I went to .tar.gz packages.  For a while, some sites used NSS and others did not and this was a royal pain to go back and forth until I gradually updated everyone.
>
> Since we apparently have to use NSS now, is there anything in place to ease the transition from the old way to the new NSS way?  Or can I continue installing Libreswan from .tar.gz files without NSS?
>
> Thanks
>
> - Greg Scott
>
>
> Greg Scott
> Infrasupport Corporation
> GregScott at Infrasupport.com
>
> Direct 1-651-260-1051
>
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>



More information about the Swan mailing list