Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

ip-sec Problem CA DN u. Xauth

Hallo zusammen,

ich spiele mich gerade etwas in einer Teststellung mit den einzelnen remote vpn moeglichkeiten.

Mommentan haenge ich an der Variante IP-SEC mit CA DN u. Xauth.
Der normale CA-DN Verbindungsaufbau inkl. Xauth fuer einen an der Astaro lokal vorhanden (ueber Backend AD angelegten) User funktioniert auch problemlos.

Nehme ich aber im Xauth anstatt eines lokal vorhandenen Users eine AD Gruppe, so schlägt der Verbindungsaufbau fehl.
Anscheinend kann mein Client keine IP-Adresse aus dem DHCP IP-SEC Pool beziehen.

Ich habe hier mal den Mitschnitt des Verbindungsaufbaus rauskopiert.

2012:09:24-14:37:07 gwseoul pluto[14118]: listening for IKE messages

2012:09:24-14:37:07 gwseoul pluto[14118]: forgetting secrets
2012:09:24-14:37:07 gwseoul pluto[14118]: loading secrets from "/etc/ipsec.secrets"
2012:09:24-14:37:07 gwseoul pluto[14118]: loaded private key from 'Local X509 Cert.pem'
2012:09:24-14:37:07 gwseoul pluto[14118]: "D_test ipsec": deleting connection
2012:09:24-14:37:07 gwseoul pluto[14118]: loaded host certificate from '/etc/ipsec.d/certs/Local X509 Cert.pem'
2012:09:24-14:37:07 gwseoul pluto[14118]: added connection description "D_test ipsec"
2012:09:24-14:37:07 gwseoul pluto[14118]: forgetting secrets
2012:09:24-14:37:07 gwseoul pluto[14118]: loading secrets from "/etc/ipsec.secrets"
2012:09:24-14:37:07 gwseoul pluto[14118]: loaded private key from 'Local X509 Cert.pem'
2012:09:24-14:37:07 gwseoul pluto[14118]: loading ca certificates from '/etc/ipsec.d/cacerts'
2012:09:24-14:37:07 gwseoul pluto[14118]: loaded ca certificate from '/etc/ipsec.d/cacerts/Server2008R2 Root Cert.pem'
2012:09:24-14:37:07 gwseoul pluto[14118]: loaded ca certificate from '/etc/ipsec.d/cacerts/VPN Signing CA.pem'
2012:09:24-14:37:07 gwseoul pluto[14118]: loading aa certificates from '/etc/ipsec.d/aacerts'
2012:09:24-14:37:07 gwseoul pluto[14118]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2012:09:24-14:37:07 gwseoul pluto[14118]: loading attribute certificates from '/etc/ipsec.d/acerts'
2012:09:24-14:37:07 gwseoul pluto[14118]: Changing to directory '/etc/ipsec.d/crls'
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [da8e937880010000]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: received Vendor ID payload [XAUTH]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: received Vendor ID payload [RFC 3947]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: received Vendor ID payload [Dead Peer Detection]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [NCP Client]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [c61baca1f1a60cc10800000000000000]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [cbe79444a0870de4224a2c151fbfe099]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [FRAGMENTATION c0000000]
2012:09:24-14:37:28 gwseoul pluto[14118]: packet from 192.168.0.1:10952: ignoring Vendor ID payload [Cisco-Unity]
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: responding to Main Mode from unknown peer 192.168.0.1:10952
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: NAT-Traversal: Result using RFC 3947: no NAT detected
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: Peer ID is ID_DER_ASN1_DN: 'C=de, L=Seoul, O=Umbrella Corporation, CN=Administrator, E=Administrator@mail.local'
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: crl not found
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: certificate status unknown
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: we have a cert and are sending it
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: Dead Peer Detection (RFC 3706) enabled
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sent MR3, ISAKMP SA established
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending XAUTH request
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: parsing XAUTH reply
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: extended authentication was successful
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending XAUTH status
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: parsing XAUTH ack
2012:09:24-14:37:28 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: received XAUTH ack, established
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: parsing ModeCfg request
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: unknown attribute type (20002)
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: unknown attribute type (20003)
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: unknown attribute type (20004)
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: unknown attribute type (20005)
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: peer requested virtual IP %any
2012:09:24-14:37:30 gwseoul pluto[14118]: acquiring address from pool 'test ipsec' failed
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending ModeCfg reply
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sent ModeCfg reply, established
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: peer client ID payload ID_IPV4_ADDR is invalid (0.0.0.0) in Quick I1
2012:09:24-14:37:30 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending encrypted notification INVALID_ID_INFORMATION to 192.168.0.1:10952
2012:09:24-14:37:36 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xb0ae188e (perhaps this is a duplicated packet)
2012:09:24-14:37:36 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending encrypted notification INVALID_MESSAGE_ID to 192.168.0.1:10952
2012:09:24-14:37:42 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xb0ae188e (perhaps this is a duplicated packet)
2012:09:24-14:37:42 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending encrypted notification INVALID_MESSAGE_ID to 192.168.0.1:10952
2012:09:24-14:37:48 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xb0ae188e (perhaps this is a duplicated packet)
2012:09:24-14:37:48 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: sending encrypted notification INVALID_MESSAGE_ID to 192.168.0.1:10952
2012:09:24-14:37:50 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952 #7: received Delete SA payload: deleting ISAKMP State #7
2012:09:24-14:37:50 gwseoul pluto[14118]: "D_test ipsec"[1] 192.168.0.1:10952: deleting connection "D_test ipsec"[1] instance with peer 192.168.0.1 {isakmp=#0/ipsec=#0} 


Evt. hat ja jemand nen Tip fuer mich.


This thread was automatically locked due to age.
  • Hallo Ptrick,

    acquiring address from pool 'test ipsec' failed

    Man sollte (fast) immer "VPN Pool (IPsec)" (10.242.4.0/24) benutzen.

    MfG - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hallo BAlfson,

    du hattest recht, es wird ein falscher ip-pool angegeben.
    Das problem ist nur der angezeigte Pool existiert nicht.

    Ich nutze den VPN Pool (IPsec)" (10.242.4.0/24)

    Wenn ich den IP-SEC Zugang per Xauth auf einen ueber das ad angelegten, aber in der utm9 lokal vorhandenen User einstelle stimmt der angegeben Pool.

    siehe
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: Peer ID is ID_DER_ASN1_DN: 'C=de, L=Seoul, O=Umbrella Corporation, CN=Administrator, E=Administrator@mail.local'
    
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: crl not found
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: certificate status unknown
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: we have a cert and are sending it
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: Dead Peer Detection (RFC 3706) enabled
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: sent MR3, ISAKMP SA established
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: sending XAUTH request
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: parsing XAUTH reply
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: extended authentication was successful
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: sending XAUTH status
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: parsing XAUTH ack
    2012:09:24-18:52:01 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: received XAUTH ack, established
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: parsing ModeCfg request
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: unknown attribute type (20002)
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: unknown attribute type (20003)
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: unknown attribute type (20004)
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: unknown attribute type (20005)
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: peer requested virtual IP %any
    2012:09:24-18:52:02 gwseoul pluto[23449]: acquired new lease for address 10.242.4.1 in pool 'VPN Pool (IPsec)'
    2012:09:24-18:52:02 gwseoul pluto[23449]: "D_test ipsec"[1] 192.168.0.1:10952 #3: assigning virtual IP 10.242.4.1 to peer 


    Stelle ich imgleich Profil auf eine AD Gruppe um aendert sich der Pool auf den namen der VPN Verbindung.

    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: Peer ID is ID_DER_ASN1_DN: 'C=de, L=Seoul, O=Umbrella Corporation, CN=Administrator, E=Administrator@mail.local'
    
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: crl not found
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: certificate status unknown
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: we have a cert and are sending it
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: Dead Peer Detection (RFC 3706) enabled
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: sent MR3, ISAKMP SA established
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: sending XAUTH request
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: parsing XAUTH reply
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: extended authentication was successful
    2012:09:24-18:55:36 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: sending XAUTH status
    2012:09:24-18:55:37 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: parsing XAUTH ack
    2012:09:24-18:55:37 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: received XAUTH ack, established
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: parsing ModeCfg request
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: unknown attribute type (20002)
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: unknown attribute type (20003)
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: unknown attribute type (20004)
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: unknown attribute type (20005)
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: peer requested virtual IP %any
    2012:09:24-18:55:38 gwseoul pluto[23449]: acquiring address from pool 'test ipsec' failed
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: sending ModeCfg reply
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: sent ModeCfg reply, established
    2012:09:24-18:55:38 gwseoul pluto[23449]: "D_test ipsec"[2] 192.168.0.1:10952 #6: peer client ID payload ID_IPV4_ADDR is invalid (0.0.0.0) in Quick I1 


    Hat diese Konstellation jemand von euch erfolgreich am laufen ?
  • scheint kein utm9 problem zu sein.
    mit v8 funktioniert der tunnel auch nicht.

    evt. ist an meinem aufbau etwas falsch.

    mein aufbau ist folgender.

    meine ankommende DN MASK String sieht folgendermahsen aus:
    'C=de, L=Seoul, O=Umbrella Corporation, CN=Administrator, E=Administrator@mail.local'


    mein im vpn profil eingetragener DN MASK Strin sieht so aus:
    C=de, L=Seoul, O=Umbrella Corporation, CN=*, E=*


    Die zertifikate sind in der Astaro ueber das AD angelegt worden.
    Die Astaro ist sowohl ueber Ldap als auch ueber SSO angebunden.

    Im NCP Client habe ich das zertifikat eingebunden und meinem NCP-Client Profil zugeordnet.

    Bei identität habe ich ASN1 gewaehlt.

    Xauth scheint laut protokoll durch den aua ja zu funktionieren, daher schliesse ich einen Fehler zwecks ad auth aus.

    Ist das ein Bug im Openswan Modul in der Astaro oder liegt es an meinem setup ?
  • meine ankommende DN MASK String sieht folgendermahsen aus:

    'C=de, L=Seoul, O=Umbrella Corporation, CN=Administrator, E=Administrator@mail.local'



    mein im vpn profil eingetragener DN MASK Strin sieht so aus:

    C=de, L=Seoul, O=Umbrella Corporation, CN=*, E=*


    Ist das ein Bug im Openswan Modul in der Astaro oder liegt es an meinem setup ?

    Die zertifikate sind in der Astaro ueber das AD angelegt worden.
    Die Astaro ist sowohl ueber Ldap als auch ueber SSO angebunden.

    In Astaro/Sophos ist es StrongSWAN, nicht OpenSWAN, aber es muss am Setup liegen.

    Zeige bitte ein Bild der IPsec-Fernzugriffsregel.

    Was ist der Hostname des systems?  Wie sieht das "Local X509 Cert" Zertificat aus?

    MfG - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hallo BALfson,

    danke erstmal fuer deine Hilfe.

    Der Name meiner UTM9 ist gwseoul

    hier die anderen Daten die du haben wolltest.

      

    User Cert: http://sa-clan.de/ipsec/Administrator%20%28X509%20User%20Cert%29.pem

    Certificate Authority: http://sa-clan.de/ipsec/VPN%20Signing%20CA.pem
  • (Sorry, my German-speaking brain isn't composing thoughts at the moment. [:(])

    You can have difficulties with several things, including VPNs, if the hostname is only "gwseoul" instead of an FQDN that resolves in public DNS to the public IP on theExternal interface.  I don't think that's the problem here.

    In the Cert and in the VPN Signing CA, I see emailAddress=test@umrella.local.  I don't think the typo is causing this problem - and I guess you replaced the real name with this for posting.

    The only guess I can make is that the local user was created manually instead of being synced from the Active Directory.  Try this with a user that you are certain was synced or auto-created.  Download the Certificate from the User Portal and install that on the client.

    Any luck?

    MfG - Bob (Bitte auf Deutsch weiterhin)
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA