3

I have created two virtualbox ubuntu clones for the purpose of setting up a test strongswan ipsec network; I'm trying to follow this guide. The virtualbox machines are on a bridged adapter and i verify that they can connect by pinging to the ip of each other, which suceeds

Basically i've created a net-net configuration as described in the documentation, On left machine, i replace right in ipsec.conf with the ip shown when running ifconfig on right machine and viceversa on right.

(As a brief side-comment, i want to use a private secret shared by safe channels, i presume that this implies a symmetric key encryption scheme, since anything regarding a public key would be somewhat less secure, and to be clear enough, this is an issue for countries where governments will tap all your connections, so MITM is a real problem. So if my understanding is wrong, please feel free to clarify)

back to the technical problem, in moon, i created a /etc/ipsec.d/moonKey.pem file that contains a secret string and then in /etc/ipsec.secrets:

: RSA moonKey.pem

with no passphrase, since the string in moonKey.pem is in cleartext

Similarly, in sun i've created a /etc/ipsec.d/sunKey.pem file that contains the same secret string as in moon. *I am assuming that these will be the PSK

I then run sudo ipsec restart and i don't get errors, but pinging the whole 10.2.0.0 subnet from moon i don't get any response, and similarly from sun, so it seems the setup didn't suceed

any ideas what i might be doing wrong? or how to debug this issue?

btw, i wanted to create these tags but i don't have enough rep yet:

strongswan private-shared-key ubuntu-10.10

5
  • This sounds like it's a better candidate for serverfault (even though it involves setting up IPsec)...
    – AviD
    Apr 13, 2011 at 7:04
  • @AviD - I agree, shall we see if any answers today and then migrate over?
    – Rory Alsop
    Apr 13, 2011 at 9:01
  • even if the question is mostly about setup, also there is some clarification requested about my assumptions about shared secret encryption that might not be answered properly elsewhere
    – lurscher
    Apr 13, 2011 at 15:23
  • btw, what exactly do you mean "private shared secret"? If it's private - its not shared, and if you share it, its no longer private... I think youre conflating two terms: "private key" and "shared secret" or "secret key". Can you clarify?
    – AviD
    Apr 13, 2011 at 18:28
  • yes, i meant a key that is shared among the trusted nodes either to encrypt the communication, or to encrypt a longer key used for extended communication. Its private in the sense that i don't make it public (only to my trusted nodes, and only by other secure channels)
    – lurscher
    Apr 13, 2011 at 18:35

1 Answer 1

3

The setup described in the document you cite is suitable for certificate-based authentication. The RSA tag in ipsec.secrets means exactly that the file moonKey.pem contains the RSA private key.

What you need to do to use Pre-Shared Keys (PSK):

  • in your ipsec.secrets you need a line with the PSK tag followed by the secret itself among quotes. Like this: 192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"
  • since you are not using certificates you need to drop the leftcert and rightid lines from ipsec.conf.
  • in ipsec.conf add the line authby=secret just below the conn statement to specify the PSK authentication mechanism.
  • you do not need any .pem files.

I cannot test these modifications right now, so perhaps I miss something.

As a side note, public-key cryptography is not inferior to symmetric key cryptography. If used correctly, they are both secure.

2
  • "As a side note, public-key cryptography is not inferior to symmetric key cryptography. If used correctly, they are both secure." - you still need to exchange the certificates over a pre-shared secure channel to avoid MITM right? so how is it different from the approach i want to take? sorry if my question seems ignorant, i'm just learning about this stuff
    – lurscher
    Apr 13, 2011 at 17:34
  • Machine certificates can be distributed over an insecure channel. What it is necessary to distribute via a secure channel is the Certification Authority's certificate. In your case, with only two machines, the advantage of public-key crypto is really very minor. With more machines, using public-key crypto reduces the amount of keys that you have to distribute. Apr 14, 2011 at 17:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .