Site-to-Site with strongSwan x.509 cert issue

The private key file that you defined in /etc/ipsec.secrets and which is stored in /etc/ipsec.d/private/ does not contain a private key in PKCS#1 format. The private key file content should be of the form

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAr64uEJrApxtDe28anlGU0IXJmf4sjeEbJh8BbIjnNOsaZ2ex
...
-----END RSA PRIVATE KEY-----

without passphrase protection or

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,1E1991A43D0778B7

MAsd1YBlHz54KjvBvhpwDBewinBkxBo/NmdsMetLIcV8Ag87YcKtTXYju+fbW21y
...
-----END RSA PRIVATE KEY-----

with passphrase protection.

Kind regards

Andreas

Thank you for your input, my next question is this, how do I convert the exported pem file from the astaro interface to the proper format, my only options are pkcs12 or pem.

As a recap let me reiterate what I have on my remote strongswan box.

 /etc/ipsec.d/cacerts/myAstaroCA      

/etc/ipsec.d/certs/selfSignedCertFromAstaroCA.pem

Here are the contents of ipsec.secrets

# RCSID $Id: ipsec.secrets.proto,v 1.3.6.1 2005/09/28 13:59:14 paul Exp $
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".
#: RSA /etc/ipsec.d/private/bellRd-gatewayKey.pem
: RSA /etc/ipsec.d/certs/test.pem  This file is from astaroCA











Here are the contents of the pem file

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            9a:c5:e1:89:03:33:0e:18
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=us, L=Phoenix, O=Medical Services Inc., CN=Medical Services Inc. VPN CA/emailAddress=dmarkwith@Mysite.com
        Validity
            Not Before: Mar  9 23:06:22 2009 GMT
            Not After : Mar 28 21:44:28 2035
        Subject: C=us, ST=Az, L=Phoenix, O=Medical Services Inc., OU=IT, CN=bellRd-gateway.Mysite.com/emailAddress=skeys@MySite.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:a8:97:67:e9:18:21:e5:52:07:c1:53[[[:D]]]4:1a:07:
                    12:79:2e:80[[[:D]]]0:1d:47:6d:e9:c0:42:68:a9:54:69:
                    ec:10:9d:97:3a:c4[[[:D]]]e[[[:D]]]b:f2:0b:09:ae:b3:62:e1:
                    00:13:bf:94:07[[[:D]]]3:2b:cd:b3[[[:D]]]3:65:16:89:89:e1:
                    48:57:16:a5:02:7a:f9:6f:ba:bc:1b:b0:06:30:23:
                    10:62:4d:94:fe:4b:b6:f1:88:81:cd:0e:47:33:6f:
                    87:02:e9:3e:12:5e:fc:39:25:4e:6d:e5:7b:e3:7e:
                    12[[[:D]]]d:65:98:67:7d:3d:88:8a:fb:7f:57:37:01:9a:
                    22:c9:9c[[[:D]]]d:50:93:c8:46:5b[[[:D]]]8[[[:D]]]1[[[:D]]]f:8f:4e:a2:
                    ce:21:bf:05:36:7c:6f:0d:26:e1:09:bc:a0:11:92:
                    94:2c:2a:98:f6:7f:45:af:46:7f:88:e9:a1:aa:6a:
                    c2:1f:f9:3e:cd:10:4d:2f:6a:f2:5a:f6:74:8f:c6:
                    23:61:e1:cc:aa:e7:ac:99:9b:75:91:88:39:3c:34:
                    1f:27:69:f6:6b:c7:7a:fe:a6:9a:ae:b6:cf:9c:51:
                    dc:b0:1f:7f:13:4e:a4:96:7f:72:89:7b:91:90:17:
                    98:c6:5e:26:69:bb:03:06:e9:a8:39:2b:02:ae:01:
                    3c:7e:ab:25:0b:0a:73:78:fd:c1:72:29:b9:47:27:
                    4d:69
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                84:07:A7:95:5C:04:F5:AA[[:D]]9:F4:34:CA:ED:2F:45:41:51:4A:48:3F
            X509v3 Authority Key Identifier: 
                keyid:EE[[:D]]E:8E:EB:93:25:30:E7:CC:C6:18:3B:C6:EF:EE:08:90:A5:27:67
                DirName:/C=us/L=Phoenix/O=Medical Services Inc./CN=Medical Services Inc. VPN CA/emailAddress=dmarkwith@Mysite.com
                serial:9A:C5:E1:89:03:33:0E:0E

            X509v3 Subject Alternative Name: 
                IP Address:77.77.165.73
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: md5WithRSAEncryption
        15:f6[[[:D]]]2:eb:39:83:a1:7a:6c:43:4e:45:b7:8d:26:48:06:6e:
        da:1d:a0:f4:47:43:ab[[[:D]]]8:5e:0c:24:81:8f:48:49:62:18:2e:
        be:09:a5:25:e3[[[:D]]]b:e2:e8:37[[[:D]]]1:90:4b:03:a5[[[:D]]]d:56:fc:b1:
        ad:74:ad:9d:52:09:bb:70:1f:5c:c4:c6:4f:1e[[[:D]]]4[[[:D]]]b:f9:ec:
        21:40:50:c0:63:0e:62:04:ee:0e:b5:f0:8f:91:07:5b:c8:5a:
        c0:10:8e:4f:cb:71:f0:32[[[:D]]]6:73:fb:a5:c4:cf:ae:5e:cf:bf:
        33:53:e7:c4:3f:14:ea:a2:16:5e:c3:ce:88[[[:D]]]e:a6:ab:c3:10:
        9d:23
-----BEGIN CERTIFICATE-----
MIIEUDCCA7mgAwIBAgIJAJrF4YkDMw4YMA0GCSqGSIb3DQEBBAUAMIGQMQswCQYD
VQQGEwJ1czEQMA4GA1UEBxMHUGhvZW5peDEgMB4GA1UEChMXUGh5c2ljaWFuIFNl
cnZpY2VzIEluYy4xJzAlBgNVBAMTHlBoeXNpY2lhbiBTZXJ2aWNlcyBJbmMuIFZQ
TiBDQTEkMCIGCSqGSIb3DQEJARYVZG1hcmt3aXRoQHBzaXNpdGUuY29tMCIXDTA5
MDMwOTIzMDYyMloXETM1MDMyODIxNDQyOCswMDAwMIGiMQswCQYDVQQGEwJ1czEL
MAkGA1UECBMCQXoxEDAOBgNVBAcTB1Bob2VuaXgxIDAeBgNVBAoTF1BoeXNpY2lh
biBTZXJ2aWNlcyBJbmMuMQswCQYDVQQLEwJJVDEjMCEGA1UEAxMaYmVsbFJkLWdh
dGV3YXkucHNpc2l0ZS5jb20xIDAeBgkqhkiG9w0BCQEWEXNrZXlzQHBzaXNpdGUu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqJdn6Rgh5VIHwVPU
GgcSeS6A0B1HbenAQmipVGnsEJ2XOsTe2/ILCa6zYuEAE7+UB9MrzbPTZRaJieFI
VxalAnr5b7q8G7AGMCMQYk2U/ku28YiBzQ5HM2+HAuk+El78OSVObeV7434S3WWY
Z309iIr7f1c3AZoiyZzdUJPIRlvY0d+PTqLOIb8FNnxvDSbhCbygEZKULCqY9n9F
r0Z/iOmhqmrCH/k+zRBNL2ryWvZ0j8YjYeHMquesmZt1kYg5PDQfJ2n2a8d6/qaa
rrbPnFHcsB9/E06kln9yiXuRkBeYxl4mabsDBumoOSsCrgE8fqslCwpzeP3Bcim5
RydNaQIDAQABo4IBFDCCARAwHQYDVR0OBBYEFIQHp5VcBPWq2fQ0yu0vRUFRSkg/
MIHFBgNVHSMEgb0wgbqAFO7ejuuTJTDnzMYYO8bv7giQpSdnoYGWpIGTMIGQMQsw
CQYDVQQGEwJ1czEQMA4GA1UEBxMHUGhvZW5peDEgMB4GA1UEChMXUGh5c2ljaWFu
IFNlcnZpY2VzIEluYy4xJzAlBgNVBAMTHlBoeXNpY2lhbiBTZXJ2aWNlcyBJbmMu
IFZQTiBDQTEkMCIGCSqGSIb3DQEJARYVZG1hcmt3aXRoQHBzaXNpdGUuY29tggkA
msXhiQMzDg4wDwYDVR0RBAgwBocEP/2lSTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF
4DANBgkqhkiG9w0BAQQFAAOBgQAV9tLrOYOhemxDTkW3jSZIBm7aHaD0R0Or2F4M
JIGPSEliGC6+CaUl49vi6DfRkEsDpd1W/LGtdK2dUgm7cB9cxMZPHtTb+ewhQFDA
Yw5iBO4OtfCPkQdbyFrAEI5Py3HwMtZz+6XEz65ez78zU+fEPxTqohZew86I3qar
wxCdIw==
-----END CERTIFICATE-----

I'm willing to paypal someone $50usd(i know it isnt much) who can help me get this working.

It looks to me like you asked about certs and Andreas wrote about your "private key file."  Since he's the creator of StrongSWAN, I suspect his approach works.  If StrongSWAN can handle certs, then you apparently need to change its configuration.

Cheers - Bob

> ipsec rereadall
002 forgetting secrets
002 loading secrets from "/etc/ipsec.secrets"
002   loaded private key file '/etc/ipsec.d/private/bellRd-gatewayKey.pem' (1675 bytes)  
002 Changing to directory '/etc/ipsec.d/cacerts'
002   loaded CA cert file 'astaroCA.pem' (3156 bytes)
002 Changing to directory '/etc/ipsec.d/aacerts'
002 Changing to directory '/etc/ipsec.d/ocspcerts'
002 Changing to directory '/etc/ipsec.d/acerts'
002 Changing to directory '/etc/ipsec.d/crls'

I changed ipsec.secrets so that it was to read the self-generated pem file, not the key generated by the astaroCA and I dont get any errors.  

> ipsec auto --add main
> ipsec auto --up main
104 "main" #1: STATE_MAIN_I1: initiate
003 "main" #1: ignoring Vendor ID payload [2d1f406118fbd5d28474791ffa00488a]
003 "main" #1: ignoring Vendor ID payload [Cisco-Unity]
003 "main" #1: ignoring Vendor ID payload [XAUTH]
003 "main" #1: received Vendor ID payload [Dead Peer Detection]
106 "main" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "main" #1: unable to locate my private key for RSA Signature
224 "main" #1: STATE_MAIN_I2: AUTHENTICATION_FAILED
010 "main" #1: STATE_MAIN_I2: retransmission; will wait 20s for response
003 "main" #1: unable to locate my private key for RSA Signature
224 "main" #1: STATE_MAIN_I2: AUTHENTICATION_FAILED
003 "main" #1: unable to locate my private key for RSA Signature
224 "main" #1: STATE_MAIN_I2: AUTHENTICATION_FAILED
010 "main" #1: STATE_MAIN_I2: retransmission; will wait 40s for response
031 "main" #1: max number of retransmissions (2) reached STATE_MAIN_I2
000 "main" #1: starting keying attempt 2 of an unlimited number, but releasing whack

I did something wrong or missed a step and it has to do with certs.

Recap  this is what I did on ASG320.

1. Created a cert for my remote gateway
2. Setup a gateway/vpn connection using that cert 

Recap of what I did on my debian box running strongSWAN

1. Imported the ASG320 CA to /etc/ipsec.d/cacerts/ASG320.pem
2. Imported the cert generated from ASG320 to /etc/ipsec.d/certs/remoteGateway.pem
3. Created a vpn connection using remoteGateway.pem for the leftcert

Is that correct or did I miss something?

Recap  this is what I did on ASG320.

1. Created a cert for my remote gateway
2. Setup a gateway/vpn connection using that cert 

Recap of what I did on my debian box running strongSWAN

1. Imported the ASG320 CA to /etc/ipsec.d/cacerts/ASG320.pem
2. Imported the cert generated from ASG320 to /etc/ipsec.d/certs/remoteGateway.pem
3. Created a vpn connection using remoteGateway.pem for the leftcert

Is that correct or did I miss something?

#2 on my debain box I imported the cert but not the key file 

openssl pkcs12 *clcerts  *nodes *nokeys *in /certs/client.p12 *out client.pem
openssl pkcs12  *nodes *nocerts *in /certs/client.p12 *out client.key

and added the appropriate entry in ipsec.secrets

Now I'm getting this error 
ignoring informational payload, type INVALID_ID_INFORMATION 

but I think this error has to do with the VPN ID in the cert.

A simple Simon mistake as I suspected [:)]

Yes,  the ID that you define on the debian box with leftid= must match the peer identity that you define on the ASG320. If leftid= is missing then the subject distinguished name extracted from the certificate loaded via leftcert= is used.

Regards

Andreas

Thanks again, I must be getting close but I still get INVALID_ID_INFORMAION with this config 

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
left=my strongSwan public IP
leftcert=bell.pem
leftid=@my strongSwan public IP
# leftfirewall=yes

conn net-net
leftsubnet=10.1.0.0/16
right=my astaro public IP
rightsubnet=10.2.0.0/16
rightid=@my astaro public IP

both my CN and VPNID are set to their respected public IP addresses.  If I drop the @ before my ip identifiers I get "no valid key known for "my astaro public IP" on the linux box.  Do I need to do something with the key astaro is using?  I thought all I needed to do was add the astaroCA to my strongSwan remote box.

Thanks in advance.

Thanks again, I must be getting close but I still get INVALID_ID_INFORMAION with this config 

conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
left=my strongSwan public IP
leftcert=bell.pem
leftid=@my strongSwan public IP
# leftfirewall=yes

conn net-net
leftsubnet=10.1.0.0/16
right=my astaro public IP
rightsubnet=10.2.0.0/16
rightid=@my astaro public IP

both my CN and VPNID are set to their respected public IP addresses.  If I drop the @ before my ip identifiers I get "no valid key known for "my astaro public IP" on the linux box.  Do I need to do something with the key astaro is using?  I thought all I needed to do was add the astaroCA to my strongSwan remote box.

Thanks in advance.

If you are using an ID_IPV4_ADDR as an identity then you *must not* prepend a @ character since this notation is used for Fully-Qualified Domain Names! The IP address must be included as a SubjectAltName in the X.509 certificate which was the case at least for the cert you posted earlier:

X509v3 Subject Alternative Name:
IP Address:77.77.165.73

The error "no valid key known for "my astaro public IP" is a strong  indication that a matching SubjectAltName is missing in the cert sent by the Astaro box.

Andreas

Andreas thanks a bunch, VPN established. One more question from my network behind the astaro I'm able to reach any machine that is behind the debian/strongSwan box, but NOT able to go from machines on my network behind debian/strongSwan to machines behind the astaro.  I did some searching and played around with nexthop, but no luck, ip_forward is enabled.  I didn't see any type of ipsec interface on my debian/strongSwan side.  I have also tried leftfirewall=yes .

Route table dump from astaro 

172.16.1.0      *               255.255.255.0   U     0      0        0 eth2
172.17.0.0      *               255.255.255.0   U     0      0        0 eth6
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.5.0     *               255.255.255.0   U     0      0        0 ipsec0

Route table dump from debian/strongSwan

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.5.0     *                   255.255.255.0   U      0      0        0 eth2
192.168.0.0     AstaroPubIP 255.255.255.0   UG    0      0        0 eth1
PubNetworkAddr    *                  255.255.255.0   U      0      0        0 eth1
default            ISPPubIP       0.0.0.0             UG    0      0        0 eth1

Config file from debian/strongSwan


conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
left=pubIP
leftcert=bell.pem
leftid=pubIP
leftfirewall=no
leftsubnet=192.168.5.0/24

conn net-net
auth=esp
esp=aes-128-md5
right=pubIP
rightsubnet=192.168.0.0/24
rightid=pubIP
rightcert=AstaroHost.pem
auto=start


Again thanks, you have gone above and beyond.  Also please PM me your paypal address so I can send your $.

Thanks,
Sean

If MASQUERADING is activated on your debian box then you must exempt traffic to be tunnelled from NAT by inserting the following iptables rule in the POSTROUTING chain:

iptables -t nat -I POSTROUTING 1 -s 192.168.5.0/24 -o eth1 -m policy --dir out --pol ipsec --proto esp -j ACCEPT

Andreas

I don't have MASQ enabled(yet), but thanks for the tip as I'm sure it will come in handy soon.  Maybe I'm missing kernel mods as I'm running 2.6.18 ?  I'll search around more and see what comes up.
#####################################################
bellRd-gateway:~# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     0    --  192.168.0.0/24       192.168.5.0/24      policy match dir in pol ipsec reqid 16385 proto esp
ACCEPT     0    --  192.168.5.0/24       192.168.0.0/24      policy match dir out pol ipsec reqid 16385 proto esp

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
#####################################################
So on my debian box I shouldn't necessarily have an "ipsec" interface, just on the astaro?

Thanks again,
Sean

Updated to 2.6.24 now running "strongSwan version U2.8.0/K2.6.24-etchnhalf.1-686".

No changes.....

I did some reading and ipsec devices are no more in > 2.6.16, or so that's what I gathered.  Bringing up the packet filter on the astaro shows that they are coming in but over the regular interface, not the ipsec channel, again or so I think.

A ping from behind my debian gateway yeilds this on the astaro packet filter log
Default DROP  ICMP 
63.253.165.73      
→ 
192.168.0.200      

len=84  ttl=63  tos=0x00  srcmac=00:02:a5:f0:23:0a  dstmac=00:1a:8c:17:22:49

Trying to ssh to a machine behind my astaroFW from a computer behind my debian gateway yeilds this in the astaro packet filter log

Default DROP  TCP 
63.253.165.73  :  32931
→ 
192.168.0.122  :  22

[SYN]  len=60  ttl=63  tos=0x00  srcmac=00:02:a5:f0:23:0a  dstmac=00:1a:8c:17:22:49

This leads me to believe I am missing a ipsec.conf directive that modifies IPtables automatically?

"With pluto reaching the rightsubnet via the tunnel from the gateway
itself is not possible because the IPsec policy is for leftsubnet
but the source address will be left. Thus ESP encapsulation will be
done and since there is not route to rightsubnet, the icmp request
will not leave the gateway.
"

Solved!  I will post a link to a writeup in the near future.  Thanks again!

Since you were talking about leftid, how does one set that for the Astaro? The web GUI does not seem to allow it.