Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec Site-to-Site problem with X.509 Certs

Hello

On my test bench I am trying to configure a hub/spoke sort of arrangement with a UTM9 (9.002) at the centre. This needs to support L2TP/IPSec and SSL connections from road warriors, and pure IPSec tunnels between some branch offices (1 using an ASG v8 and the rest using Draytek Vigor 2830s).

I have successfully got a road-warrior Remote Access L2TP/IPSec configuration working using PSKs for authentication. When I try creating a Site-to-Site IPSec gateway I cannot select PSK again; is it the case that only one of RA/S2S can use PSK? Is that a StrongSwan limitation?

I figure, no worries, I could easily use X.509 certs for the branch office connections. I'm starting with the ASG v8 branch office. I followed the instructions in this PDF (http://sophserv.sophos.com/repo_kb/115139/file/Site-to-site-vpn_x509_en.pdf) and created a certificate for my branch office on the UTM9 that I imported into the ASG8.

The connection will not authenticate, however.

My settings are:

Central office UTM9, hostname "utmTest"
IPSec/Advanced/Local cert: "Local X509 cert" (the auto-generated one)
Remote Gateway: Respond only, Auth type: local X509 cert, with the cert I created for the branch office selected. This cert is ID'd by e-mail, "myUser@myDomain.net".
IPSec connection created against this gateway.

Branch office ASG8, hostname "naira"
IPSec/Advanced/Local cert: "Branch office certificate" (same cert that I configured for the "Remote Gateway" on the UTM9 - imported to the ASG8)
Remote gateway: Initiate only, Auth type: Remote X509 cert, ID type e-mail address, with the address entered: "myUser@myDomain.net".
IPSec connection created against this gateway.

If I click on the "Site-to-Site" menu heading, the connection summary reports:

On the UTM9:
SA:  10.45.0.0/24=81.x.x.154 -> 178.x.x.65=172.16.0.0/21
VPN ID: utmTest
Error: No connection

On the ASG8:
SA:  172.16.0.0/21=178.x.x.65 -> 81.x.x.154=10.45.0.0/20
VPN ID: myUser@myDomain.net
Error: No connection


This connection does not work. The logfile on the ASG8 reports: "we require peer to have ID 'myUser@myDomain.net', but peer declares 'utmTest'". 'utmTest' is the hostname of my UTM9 machine.

UTM9 log:
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: responding to Main Mode from unknown peer 178.x.x.65
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: NAT-Traversal: Result using RFC 3947: no NAT detected
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: Peer ID is ID_USER_FQDN: 'myUser@myDomain.net'
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: crl not found
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: certificate status unknown
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: we have a cert and are sending it
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: Dead Peer Detection (RFC 3706) enabled
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: sent MR3, ISAKMP SA established
2012:09:27-12:02:08 utmTest pluto[21264]: "S_TestBranchOffice"[7] 178.x.x.65 #98: ignoring informational payload, type INVALID_ID_INFORMATION 


ASG8 log:
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: initiating Main Mode to replace #52
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: received Vendor ID payload [strongSwan]
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: ignoring Vendor ID payload [Cisco-Unity]
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: received Vendor ID payload [XAUTH]
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: received Vendor ID payload [Dead Peer Detection]
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: received Vendor ID payload [RFC 3947]
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: enabling possible NAT-traversal with method 3
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: NAT-Traversal: Result using RFC 3947: no NAT detected
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: we have a cert and are sending it
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: Peer ID is ID_FQDN: 'utmTest'
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: crl not found
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: certificate status unknown
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: we require peer to have ID 'myUser@myDomain.net', but peer declares 'utmTest'
2012:09:27-12:02:08 naira pluto[11139]: "S_BranchOffice TEST" #54: sending encrypted notification INVALID_ID_INFORMATION to 81.x.x.154:500
2012:09:27-12:02:09 naira pluto[11139]: packet from 81.x.x.154:500: Informational Exchange is for an unknown (expired?) SA
2012:09:27-12:02:18 naira pluto[11139]: "S_BranchOffice TEST" #54: Peer ID is ID_FQDN: 'utmTest'
2012:09:27-12:02:18 naira pluto[11139]: "S_BranchOffice TEST" #54: crl not found
2012:09:27-12:02:18 naira pluto[11139]: "S_BranchOffice TEST" #54: certificate status unknown
2012:09:27-12:02:18 naira pluto[11139]: "S_BranchOffice TEST" #54: we require peer to have ID 'myUser@myDomain.net', but peer declares 'utmTest'
2012:09:27-12:02:18 naira pluto[11139]: "S_BranchOffice TEST" #54: sending encrypted notification INVALID_ID_INFORMATION to 81.x.x.154:500
2012:09:27-12:02:22 naira pluto[11139]: packet from 81.x.x.154:500: Informational Exchange is for an unknown (expired?) SA 


It looks like I've got the certificates wrong but I can't work it out. Help?

Thanks,
Giles.


This thread was automatically locked due to age.
Parents
  • Thanks for the reply, Bob.

    I'm getting somewhere, albeit using PSKs for the moment. My branches do have static IPs so I can set their tunnels to 'initiate' instead of 'respond only'. Also, good spot on my subnet mismatch, that stopped the PSK from working until I'd corrected it.

    Your pointer to the "probing" option was very useful in case I need to have other respond-only connections.

    I have also configured the UTM with a publicly resolvable FQDN and re-generated the certificates that seemed to need it. If I get everything working with the PSKs I may try the certs again as a 'best practice' solution.

    Thanks again,
    Giles.
Reply
  • Thanks for the reply, Bob.

    I'm getting somewhere, albeit using PSKs for the moment. My branches do have static IPs so I can set their tunnels to 'initiate' instead of 'respond only'. Also, good spot on my subnet mismatch, that stopped the PSK from working until I'd corrected it.

    Your pointer to the "probing" option was very useful in case I need to have other respond-only connections.

    I have also configured the UTM with a publicly resolvable FQDN and re-generated the certificates that seemed to need it. If I get everything working with the PSKs I may try the certs again as a 'best practice' solution.

    Thanks again,
    Giles.
Children
No Data