Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 3088 views
  • Users 0 members are here
Options
Suggested
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

gilester
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
  • 0
    Giles, I see a several potential issues.  

    First, does your UTM have a hostname that is resolvable in public DNS to the public IP you want to use for the VPN?  If not, that can cause problems in several places.  If you have to change that, then you will need to generate new CAs and new certificates.  If you want to just put a bandaid on this, I think you can just generate a replacement for your "Local X509 Cert" using a valid FQDN for hostname and use that new cert on the 'Advanced' tab of 'IPsec'.

    At the bottom of the IPsec 'Advanced' tab is a selection allowing probing of pre-shared keys.  Without that option selected, you can have only a single PSK for respond-only gateways.  If you're using L2TP/IPsec already, then that PSK would be the only one you could use.

    Best practice is to change site-to-site PSKs monthly, or at least quarterly.  RSA-based and certificate-based tunnels are really the only approaches that should be used for a long-term connection.

    In any case, you probably don't want "Respond-only" Remote Gateways for your connections.  If the branches don't have fixed IPs, you can get a DynDNS account for a few dollars a month.

    In the example you showed, you had 10.45.0.0/24 on the UTM9, but 10.45.0.0/20 on the ASG8.

    Cheers - Bob
Reply
  • 0
    Giles, I see a several potential issues.  

    First, does your UTM have a hostname that is resolvable in public DNS to the public IP you want to use for the VPN?  If not, that can cause problems in several places.  If you have to change that, then you will need to generate new CAs and new certificates.  If you want to just put a bandaid on this, I think you can just generate a replacement for your "Local X509 Cert" using a valid FQDN for hostname and use that new cert on the 'Advanced' tab of 'IPsec'.

    At the bottom of the IPsec 'Advanced' tab is a selection allowing probing of pre-shared keys.  Without that option selected, you can have only a single PSK for respond-only gateways.  If you're using L2TP/IPsec already, then that PSK would be the only one you could use.

    Best practice is to change site-to-site PSKs monthly, or at least quarterly.  RSA-based and certificate-based tunnels are really the only approaches that should be used for a long-term connection.

    In any case, you probably don't want "Respond-only" Remote Gateways for your connections.  If the branches don't have fixed IPs, you can get a DynDNS account for a few dollars a month.

    In the example you showed, you had 10.45.0.0/24 on the UTM9, but 10.45.0.0/20 on the ASG8.

    Cheers - Bob
Children
No Data