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 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

  • This sounds like it's a better candidate for serverfault (even though it involves setting up IPsec)... – AviD Apr 13 '11 at 7:04
  • @AviD - I agree, shall we see if any answers today and then migrate over? – Rory Alsop Apr 13 '11 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 '11 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 '11 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 '11 at 18:35

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: %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.

| improve this answer | |
  • "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 '11 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. – Giacomo Verticale Apr 14 '11 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.