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.
Parents
  • 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 ?
Reply
  • 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 ?
Children
No Data