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

iPhone - Cisco VPN - Kommunikation mit VPN Server fehlgeschlagen

Hallo zusammen

Ich komme einem Problem nicht so richtig auf die Spur, vielleicht kann mir jemand helfen.

Wir haben hier eine ASG 320 mit der Fw 8.301
Hier sollen nun einige iPhone 4s per VPN drauf zugreifen.

Ich habe mir die etwas älter Anleitung von Astaro durchgelesen und den Punkt - Cisco VPN Client wie folgt konfiguriert:

Schnittstelle = externes LAN interface mit der statischen IP der Firewall
Serverzertifikat = hier habe ich ein eigenes Zertifikat (4096 Bit) mit dem FQDN der Firewall erstellt. 
Pool - Netzwerk = ist wie voreingestellt.

Lokale Netzwerke = Netzwerkworauf zugegriffen werden soll.
Benutzer und Gruppen = IPhone Gruppe

Unter der Registerkarte "iOS-Geräte" habe ich noch den FQDN der Firewall mitgegeben.

Mein iPhone hat sich die Konfig vom Benutzerportal heruntergeladen und installiert.

Sobald ich die VPN aktivieren will bekomme ich entweder den Fehler:

"Ein unerwarteter Fehler ist aufgetreten"  oder
"Kommunikation mit VPN Server fehlgeschlagen"

Im Log finde ich folgende Zeilen die ich nicht so richtig zuordnen kann:

2012:03:08-16:51:09 fw pluto[29624]: | authkey: 13:e7:9e:0f:42:01:2f:59:9b:6b:ef:56:59:0c:9b:5b:bc:7b:e4:1f

 
2012:03:08-16:51:09 fw pluto[29624]: | certificate is valid 

2012:03:08-16:51:09 fw pluto[29624]: | issuer cacert found 

2012:03:08-16:51:09 fw pluto[29624]: | certificate signature is valid 

2012:03:08-16:51:09 fw pluto[29624]: "D_for FirmenName to VLAN_38 (Network)"[16] 109.84.0.105:41994 #31: crl not found
 
2012:03:08-16:51:09 fw pluto[29624]: "D_for FirmenName to VLAN_38 (Network)"[16] 109.84.0.105:41994 #31: certificate status unknown 



Wenn jemand eine Idee hat - her damit.

Viele Grüße
greenhornXXL


This thread was automatically locked due to age.
Parents
  • It could be several problems; the log is too long for me to look closely because I don't know IPsec and Cisco well enough to know what's normal.

    It says that the certificate was verified, so it seems that you already have changed your certificates from MD5 to SHA to account for Apple's change in iOS5.

    The Hostname should be an FQDN that is resolvable in public DNS.  The 'Server certificate' must have VPN ID with the same FQDN; if the FQDN in the certificate is different, the one in the certificate must be used in 'Override hostname'.

    You might try deleting the profile in the iPhone and reloading it via the User Portal.

    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
  • Hallo zusammen

    @ rprengel
    Die Astaro ist direkt per Standltg. ans Internet angebunden.
    Hostname der Astaro ist FQDN und kann von überall angepingt werden.
    SSL-VPN fkt. z.B. tadellos.

    @ Forscher
    Dies kann ich gerne mal probieren ... allerdings finde ich die Cisco Lsg. eleganter so dass die User per Webportal sich einfach ein Packet ziehen können und es auf ihren iPhone selbst installieren.

    @ BAlfson
    Der Hostname ist FQDN.
    Zusätzlich habe ich den Eintrag in "Hostname übergeben" gesetzt.
    Der Ping auf den Name löst auch die richtige IP auf. Das Zertifikat habe ich für die iPhone neu erstellt und als VPN ID [FQDN - Hostname] eingetragen.
    Profile auf den iPhones habe ich gelöscht und neu gemacht - bisher ohne Erfolg.

    Die Iphone finden auch die Astaro den das Log erkennt das sich ein iPhone anmelden möchte - aber die Kommunikation bricht dann aus irgenwelchen gründen zusammen.


    Besten Dank für die Infos
    ich bleibe dran ...
  • @ Forscher

    Ich hab nun das L2TP über IPsec ausprobiert und dies funktioniert auf anhieb mit der Auth.-Methode: Verteilter Schlüssel.

    Wenn ich die X509 Methode austesten will finde ich im iPhone nicht die Einstellung umd die VPN Verbindung mit dem Zertifikat zu verheiraten.
    Das Zertifikat habe ich aus dem Benutzerportal auf das iPhone heruntergeladen und installiert, aber wie füge ich das der L2TP VPN Verbindung hinzu?!

    Kannst du mir hier noch einen Tipp geben ?!
    Vielleicht bin ich auch blind ;-)

    Viele Grüße
    greenhornXXL
Reply
  • @ Forscher

    Ich hab nun das L2TP über IPsec ausprobiert und dies funktioniert auf anhieb mit der Auth.-Methode: Verteilter Schlüssel.

    Wenn ich die X509 Methode austesten will finde ich im iPhone nicht die Einstellung umd die VPN Verbindung mit dem Zertifikat zu verheiraten.
    Das Zertifikat habe ich aus dem Benutzerportal auf das iPhone heruntergeladen und installiert, aber wie füge ich das der L2TP VPN Verbindung hinzu?!

    Kannst du mir hier noch einen Tipp geben ?!
    Vielleicht bin ich auch blind ;-)

    Viele Grüße
    greenhornXXL
Children
  • Hallo zusammen, 

    kann mir jemand mal weiterhelfen mit der Konfiguration, ich weiß nicht was ich verkehrt mache.

    Unsere ASG hängt direkt am Internet via Company Connect. Der Hostname ist ein FQDN und per Name oder IP von außen direkt erreichbar.

    Eingerichtet habe ich Fernzugriff --> Cisco VPN  mittels dieser nicht mehr ganz aktuellen Anleitung.

    Auf dem iPhone ist iOS 5.1 installiert. Ich habe das Zertifikat heruntergeladen und dann in die Verbindungseinstellungen eigebunden. 

    Es erfolgt ein Connect, dies sieht man im Live Log, allerdings wird dann die Verbindung abgewiesen. Das iPhone meldet Serverzertifikat konnte nicht überprüft werden.

    Gewählt ist das local x509 der ASG (2048bit).

    Im Log steht immer folgendes:



    packet from received Vendor ID payload [RFC 3947]
    packet from ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
    packet from ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
    packet from ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
    packet from ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
    packet from ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
    packet from ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
    packet from ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    packet from ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    packet from ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    packet from received Vendor ID payload [XAUTH]
    packet from ignoring Vendor ID payload [Cisco-Unity]
    packet from received Vendor ID payload [Dead Peer Detection]
    D_REF_IpsRoaFor***xToLan01_1[1] :4500 #6227: responding to Main Mode from unknown peer :4500
    | NAT-T: new mapping :4500/500)
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: NAT-Traversal: Result using RFC 3947:00:00 peer is NATed
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: ignoring informational payload, type IPSEC_INITIAL_CONTACT
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: Peer ID is ID_DER_ASN1_DN: 'C=de, L=ORT, O=ORG CN=***x, E=***@xx.xx'
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: crl not found
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: certificate status unknown
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: we have a cert and are sending it
    D_REF_IpsRoaFor***xToLan01_1[1] #6227: Dead Peer Detection (RFC 3706) enabled
    | NAT-T: new mapping :500/4500)
    D_REF_IpsRoaFor***xToLan01_1[1] :4500 #6227: sent MR3, ISAKMP SA established
    D_REF_IpsRoaFor***xToLan01_1[1] :4500 #6227: sending XAUTH request
    packet from Informational Exchange is for an unknown (expired?) SA
    ERROR: asynchronous network error report on eth1 for message to port 4500 complainant Connection refused [errno 111 origin ICMP type 3 code 3 (not authenticated)


    Hat jemand eine Idee??
  • Hallo zusammen,

    habe exact das selbe problem wie tetris:
    certificate status unknown

    jemand eine Lösung gefunden?
  • Hier nochmal meine genau meldung:

    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: received Vendor ID payload [RFC 3947]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: received Vendor ID payload [XAUTH]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [Cisco-Unity]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: ignoring Vendor ID payload [FRAGMENTATION 80000000]
     
    2013:01:08-17:12:05 mail pluto[12373]: packet from 109.84.0.114:54785: received Vendor ID payload [Dead Peer Detection]
     
    2013:01:08-17:12:05 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: responding to Main Mode from unknown peer 109.84.0.114:54785
     
    2013:01:08-17:12:05 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: NAT-Traversal: Result using RFC 3947: peer is NATed
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: ignoring informational payload, type IPSEC_INITIAL_CONTACT
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: Peer ID is ID_DER_ASN1_DN: 'C=de, L=Schmitten, O=Indusa GmbH, CN=Holger Ernst, E=info@indusa.de'
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: crl not found
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: certificate status unknown
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54785 #7: we have a cert and are sending it
     
    2013:01:08-17:12:06 mail pluto[12373]: | NAT-T: new mapping 109.84.0.114:54785/54966)
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: sent MR3, ISAKMP SA established
     
    2013:01:08-17:12:06 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: sending XAUTH request
     
    2013:01:08-17:12:09 mail pluto[12373]: packet from 109.84.0.114:54966: Main Mode message is part of an unknown exchange
     
    2013:01:08-17:12:09 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: parsing XAUTH reply
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: extended authentication was successful
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: sending XAUTH status
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: parsing XAUTH ack
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: received XAUTH ack, established
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: parsing ModeCfg request
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: unknown attribute type (28683)
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: peer requested virtual IP %any
     
    2013:01:08-17:12:10 mail pluto[12373]: acquired existing lease for address 10.242.5.2 in pool 'VPN Pool (Cisco)'
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: assigning virtual IP 10.242.5.2 to peer
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: sending ModeCfg reply
     
    2013:01:08-17:12:10 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: sent ModeCfg reply, established
     
    2013:01:08-17:12:27 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966 #7: received Delete SA payload: deleting ISAKMP State #7
     
    2013:01:08-17:12:27 mail pluto[12373]: "D_REF_gepyLUsgUq"[7] 109.84.0.114:54966: deleting connection "D_REF_gepyLUsgUq" instance with peer 109.84.0.114 {isakmp=#0/ipsec=#0}