iPad VPN LC1611

NickD · Beitrag von **NickD** » 23 Sep 2010, 11:01

Guten Tag,

ich versuche ein iPad (onboard Cisco-Client) über VPN mit einem Lancom 1611 DSL/I (FW 7.80, letzte verfügbare Version für diesen Router) zu verbinden. Den VPN-Zugang auf der Router-Seite habe ich genau nach der Anleitung von Louis durchgeführt, Anleitung die hier im Forum und auch auf der Lancom-Seite zu finden ist (allerdings für den iPhone).
Ich bekomme eine stabile VPN-Verbindung zum VPN-Router. Sie wird als solche korrekt in den LanMonitor auch angezeigt. Leider werden keine (oder fast keine) Daten über den Tunnel übertragen.
Auf dem Zielserver hinter dem LANCOM-Router (SBS, der DNS, Exchange, und WEB-Server in einem ist), habe ich mit dem Netzwerkmonitor festgestellt, dass nur die DNS-Abfragen vom iPad zum DNS-Server ankommen. Leider sind die Standardmöglichkeiten einer Netzwerkanalyse von der iPad-Seite aus so gut wie nicht vorhanden, also kann ich nicht einmal einen PING vom iPad absetzen. Versuche den SBS WEB-Server vom iPad (mit Safari) zu erreichen laufen nicht, obwohl hier die entsprechenden DNS-Abfragen schon ankommen, und auch geantwortet werden (das zeigt mir der Netzwerkmonitor auf dem SBS). Ob der iPad diese Antworten auch bekommt, dass kann ich nicht sagen.
Da der iPad VPN-Client eine feste IP-Adresse vom Router bekommt, habe ich versucht diese vom SBS aus anzupingen, (solange der Tunnel steht, versteht sich), aber es kommen auch hiervon keine Antworten.
Andere (Windows) Clients, die den VPN-Tunnel mit dem Shrew-Client realisieren, lassen sich bei Verbindung aus dem internen Netzwerk anpingen.
Die Firewall Regel, die automatisch vom Setup-Assistent für diese VPN-Verbindung, habe ich überprüft, und sie scheint in Ordnung zu sein (WIZ_VPN-Client_VPN-IPAD, übertragen, von Allen Stationen zu VPN-IPAD, alle Protokolle).
Ich habe auch probiert eine weitere Firewall-Regel einzubauen, die den umgekehrten Weg beschreibt, also VPN-IPAD zu allen Stationen, aber auch diese bringt keine Verbesserung.
Hat jemand eine Idee, wie ich den Fehler beheben kann?

Danke und Gruß,

NickD

backslash · Beitrag von **backslash** » 23 Sep 2010, 12:22

Hi NickD,

Da der iPad VPN-Client eine feste IP-Adresse vom Router bekommt, h

Ist das eine Adresse aus dem Adreßkreis deines LAN oder eines anderen Netzes?

Wenn das iPad eine Adresse aus deinem LAN zugewiesen bekommt: Hast du im LANCOM Proxy-ARP eingeschaltet (IP-Router -> Allgemein -> entfernte Stationen über Proxy-ARP einbinden)?

Wenn das iPad eine Adresse aus einem anderen Netz zugewiesen bekommt: Ist das LANCOM das Default-Gateway in deinem Netz oder ist zumindest dem Defaultgateway bekannt, daß das iPad über das LANCOM erreichbar ist?

Gruß
Backslash

NickD · Beitrag von **NickD** » 23 Sep 2010, 12:50

Hi Backslash,

danke für Deine Antwort! Die IP-Adresse, die dem iPad zugewiesen wird, ist aus dem selben Netzwerk wie die interne LAN-Schnittstelle des Lancom-Routers. Im selben Netzwerk befindet sich auch der SBS-Server, den ich per VPN erreichen möchte. Da der LANCOM-Router gleichzeitig auch Internet-Router ist, haben alle Stationen in diesem Netzwerk als Standard-Gateway die IP-Adresse der LAN-Schnittstelle des LANCOM-Routers.
Ich hatte auch den Vorschlag probiert, in der Routing Tabelle des LANCOM-Routers, bei dem Eintrag mit der IP-Adresse des iPads, statt VPN-IPAD die Adresse 0.0.0.0 einzutragen. Mit dieser Einstellung bekomme ich keine VPN-Verbindung mehr zustande.
Die Option "Stationen über Proxy-ARP einbinden" ist eingeschaltet (andere VPN-Verbindungen mit Win-Stationen und Shrew-Client laufen problemlos).

Bravestarr · Beitrag von **Bravestarr** » 23 Sep 2010, 14:39

Die Gegenstelle muss in der Routingtabelle eingetragen sein. Ansonsten klappt es nicht.

Das beschriebene Verhalten kenne ich eigentlich nur, wenn es auf dem LANCOM mehr als eine SA für den Tunnel gibt. Apple-Produkte kommen damit nicht klar. Kontrolliere die SAs bitte mal über ein show vpn.

Ein IP-Router-Trace wäre hilfreich. Leider habe ich kein iPad zum Testen, aber für die kleineren Brüder gibt es im Appstore SSH-Tools, mit denen man auch mal einen Ping absetzen kann. Such einfach mal...

Gruß

NickD · Beitrag von **NickD** » 23 Sep 2010, 15:29

Hi Bravestarr,

danke für die Antwort. Mit "show vpn" habe ich tatsächlich 16 Einträge (Connections) gefunden, die mein VPN-XXX betreffen. Praktisch jede andere definierte VPN-Verbindung auf dem Lancom zeigt hier 16 Connections an. Verstehe ich hier richtig, jede Connection ist eine mögliche SA (security association). Was kann man in diesem Fall machen?

NickD · Beitrag von **NickD** » 26 Sep 2010, 16:35

Hi,

jetz habe ich die APPS aus dem Store gezogen, und kann so pings vom iPad absetzen. Mit dem Netzwerkmonitor auf dem SBS-Server kann ich sehen wie die ICMP-Pakete vom iPad den SBS-Server über den VPN-Tunnel erreichen, und wie diese ECHO Requests auch vom SBS-Server geantwortet werden. Sie werden korrekt an die VPN-IP-Adresse des iPads zurückgegendet, aber zum iPad kommen sie nicht an. Pings vom iPad zum internen LAN-Adapter des LANCOM-Routers werden auch nicht beantwortet. Ich habe sogar die FW-Regel Deny_All desaktiviert, und so kann ich die Externe IP-Adresse des Routers anpingen (sie wird im LAN-Monitor von LANCOM angezeigt, und sie antwortet). Wie kann ich sehen (auf dem LANCOM-Router) was mit den Retour-Paketen passiert?

Gruß,

NickD · Beitrag von **NickD** » 26 Sep 2010, 17:41

Hi noch mal,

mit "trace + ip-router" (am LC-Router) kann ich sehen, wir die Echo Requests des iPads den SBS-Server zugesendet werden, und wie diese auch beantwortet werden. Der Router schient sie zur richtigen Empfänger zu senden:

[IP-Router] 2010/09/26 17:24:44,150
IP-Router Rx (VPN-TBOTH, RtgTag: 0):
DstIP: 193.2.8.88, SrcIP: 193.2.8.63, Len: 92, DSCP/TOS: 0x00
Prot.: ICMP (1), echo request, id: 0xaa69, seq: 0x006e
Route: LAN-1 Tx (INTRANET):

[IP-Router] 2010/09/26 17:24:44,150
IP-Router Rx (LAN-1, INTRANET, RtgTag: 0):
DstIP: 193.2.8.63, SrcIP: 193.2.8.88, Len: 92, DSCP/TOS: 0x00
Prot.: ICMP (1), echo reply, id: 0xaa69, seq: 0x006e
Route: WAN Tx (VPN-TBOTH)

----
IP-SBS: 193.2.8.88
IP-VPN-Verbindung (VPN-TBOTH): 193.2.8.63

Gleichzeitig habe ich trace + firewall aktiviert. Es wird aber keinerlei Aktivität der Firewall angezeigt.

Mir ist es natürlich bekannt, dass diese IP-Adressen keine Privaten sind, aber das lässt sich jetzt leider nicht ändern (schwere Erbschaft). Andere VPN-Verbindungen, aber eben nicht mit einem iPad, laufen problemlos.

Ich bin ... sprachlos (deswegen schreibe ich

).

Gruß,

NickD · Beitrag von **NickD** » 26 Sep 2010, 18:18

Jetzt bin ich noch einen Schritt weiter: ich habe endlich eine Fehlermeldung!

"no sa available: give up, should be retransmitted"

Mit "trace + VPN-Packet" habe ich einen Echo Request und Reply aufgenommen. Das Antwort-Paket kommt vom SBS-Server zurück zum Router, aber dieser kann anscheinend das Paket nicht weiterleiten, wegen fehlenden verfügbaren SA (siehe unten). Die Firewall Regel "WIZ_VPN-CLIENT_VPN-TBOTH" existiert und ist für die Erzeugung von VPN-Regeln aktiviert.

Was kann ich jetzt noch konfigurieren?

######################################################
[VPN-Packet] 2010/09/26 17:59:41,710
decap: 193.2.8.63->193.2.8.88 92 ICMP ECHOREQUEST
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 92
ID : 27951
Fragment : Offset 0
TTL : 64
Protocol : ICMP
Checksum : 31446 (OK)
Src Address : 193.2.8.63
Dest Address : 193.2.8.88
-->ICMP Header
Msg : echo request
Checksum : 4314 (OK)
Body : 00 00 00 00 00 00 00 00 ........
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 39 38 20 62 6f 74 98 bot
74 6c 65 73 20 6f 66 20 tles of
62 65 65 72 20 6f 6e 20 beer on
74 68 65 20 77 61 6c 6c the wall

[VPN-Packet] 2010/09/26 17:59:41,750
for send: 193.2.8.88->193.2.8.63 92 ICMP ECHOREPLY
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 92
ID : 1704
Fragment : Offset 0
TTL : 127
Protocol : ICMP
Checksum : 41565 (OK)
Src Address : 193.2.8.88
Dest Address : 193.2.8.63
-->ICMP Header
Msg : echo reply
Checksum : 6362 (OK)
Body : 00 00 00 00 00 00 00 00 ........
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 39 39 20 62 6f 74 99 bot
74 6c 65 73 20 6f 66 20 tles of
62 65 65 72 20 6f 6e 20 beer on
74 68 65 20 77 61 6c 6c the wall

[VPN-Packet] 2010/09/26 17:59:41,750
no sa available: give up, should be retransmitted: 193.2.8.88->193.2.8.63 92 ICMP ECHOREPLY
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 92
ID : 1704
Fragment : Offset 0
TTL : 127
Protocol : ICMP
Checksum : 41565 (OK)
Src Address : 193.2.8.88
Dest Address : 193.2.8.63
-->ICMP Header
Msg : echo reply
Checksum : 6362 (OK)
Body : 00 00 00 00 00 00 00 00 ........
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 39 39 20 62 6f 74 99 bot
74 6c 65 73 20 6f 66 20 tles of
62 65 65 72 20 6f 6e 20 beer on
74 68 65 20 77 61 6c 6c the wall

[VPN-Packet] 2010/09/26 17:59:41,750
for send: 193.2.8.88->193.2.8.63 92 ICMP ECHOREPLY
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 92
ID : 1705
Fragment : Offset 0
TTL : 127
Protocol : ICMP
Checksum : 41564 (OK)
Src Address : 193.2.8.88
Dest Address : 193.2.8.63
-->ICMP Header
Msg : echo reply
Checksum : 6362 (OK)
Body : 00 00 00 00 00 00 00 00 ........
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 39 38 20 62 6f 74 98 bot
74 6c 65 73 20 6f 66 20 tles of
62 65 65 72 20 6f 6e 20 beer on
74 68 65 20 77 61 6c 6c the wall

[VPN-Packet] 2010/09/26 17:59:41,750
no sa available: give up, should be retransmitted: 193.2.8.88->193.2.8.63 92 ICMP ECHOREPLY
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : (0x00) Precedence 0
Total length : 92
ID : 1705
Fragment : Offset 0
TTL : 127
Protocol : ICMP
Checksum : 41564 (OK)
Src Address : 193.2.8.88
Dest Address : 193.2.8.63
-->ICMP Header
Msg : echo reply
Checksum : 6362 (OK)
Body : 00 00 00 00 00 00 00 00 ........
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20
20 20 39 38 20 62 6f 74 98 bot
74 6c 65 73 20 6f 66 20 tles of
62 65 65 72 20 6f 6e 20 beer on
74 68 65 20 77 61 6c 6c the wall

#######################################################

Bravestarr · Beitrag von **Bravestarr** » 27 Sep 2010, 10:16

Wieviele SAs gibt es denn für die iPad-Verbindung? Wird NAT-T genutzt?

NickD · Beitrag von **NickD** » 27 Sep 2010, 10:23

Hi

Mit "show vpn" habe ich tatsächlich 16 Einträge (Connections) gefunden, die mein VPN-XXX betreffen. Praktisch jede andere definierte VPN-Verbindung auf dem Lancom zeigt hier 16 Connections an

Mit Trace + vpn-status bekomme ich folgende Infos beim Aufbaus des VPN-Tunnels:

[VPN-Status] 2010/09/26 18:23:46,290
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports draft-ietf-ipsec-isakmp-xauth
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 46.115.235.39:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2010/09/26 18:23:46,290
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2

[VPN-Status] 2010/09/26 18:23:47,210
IKE info: Phase-1 [responder] for peer VPN-TBOTH between initiator id vpn-gname-tboth, responder id vpn-gname-tboth don
IKE info: NAT-T enabled in mode rfc, we are not behind a nat, the remote side is behind a nat
IKE info: SA ISAKMP for peer VPN-TBOTH encryption aes-cbc authentication sha1
IKE info: life time ( 3600 sec/ 0 kb)

[VPN-Status] 2010/09/26 18:23:47,210
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer VPN-TBOTH set to 3240 seconds (Responder)

[VPN-Status] 2010/09/26 18:23:47,210
IKE info: Phase-1 SA Timeout (Hard-Event) for peer VPN-TBOTH set to 3600 seconds (Responder)

[VPN-Status] 2010/09/26 18:23:47,230
IKE info: NOTIFY received of type INITIAL_CONTACT for peer VPN-TBOTH

[VPN-Status] 2010/09/26 18:23:47,230
IKE info: Phase-1 [responder] got INITIAL-CONTACT from peer VPN-TBOTH (46.115.235.39)

[VPN-Status] 2010/09/26 18:23:47,230
IKE info: Phase-1 SA removed: peer VPN-TBOTH rule VPN-TBOTH removed

[VPN-Status] 2010/09/26 18:23:47,380
IKE log: 182347.000000 Default xauth_initiator_recv_ATTR: cfg packet ID did not match!

[VPN-Status] 2010/09/26 18:23:47,390
IKE info: IKE-CFG: Attribute XAUTH_USER_NAME len 9 value VPN-TBOTH received

[VPN-Status] 2010/09/26 18:23:47,390
IKE info: IKE-CFG: Attribute XAUTH_PASSWORD len 13 value * received

[VPN-Status] 2010/09/26 18:23:47,510
IKE info: IKE-CFG: Attribute XAUTH_STATUS len 2 value FAIL received

[VPN-Status] 2010/09/26 18:23:47,540
IKE info: IKE-CFG: Received REQUEST message with id 13284 from peer VPN-TBOTH
IKE info: IKE-CFG: Attribute INTERNAL_IP4_ADDRESS len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NETMASK len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_DNS len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NBNS len 0 value (none) received
IKE info: IKE-CFG: Attribute INTERNAL_ADDRESS_EXPIRY len 0 value (none) received
IKE info: IKE-CFG: Attribute APPLICATION_VERSION len 40 value Cisco Systems VPN Client 3.2.2:iPhone OS received
IKE info: IKE-CFG: Attribute <Unknown 28672> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28674> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28675> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28676> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28678> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28679> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28673> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28680> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28681> len 0 is private -> ignore
IKE info: IKE-CFG: Attribute <Unknown 28683> len 0 is private -> ignore

[VPN-Status] 2010/09/26 18:23:47,550
IKE info: IKE-CFG: Creating REPLY message with id 13284 for peer VPN-TBOTH
IKE info: IKE-CFG: Attribute APPLICATION_VERSION len 0 skipped
IKE info: IKE-CFG: Attribute INTERNAL_ADDRESS_EXPIRY len 4 value 1200 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NBNS len 0 skipped
IKE info: IKE-CFG: Attribute INTERNAL_IP4_DNS len 4 value 193.2.8.88 added
IKE info: IKE-CFG: Attribute INTERNAL_IP4_NETMASK len 0 skipped
IKE info: IKE-CFG: Attribute INTERNAL_IP4_ADDRESS len 4 value 193.2.8.63 added
IKE info: IKE-CFG: Sending message

[VPN-Status] 2010/09/26 18:23:47,890
IKE info: Phase-2 proposal failed: remote No 1, esp hmac HMAC_SHA <-> local No 1, esp hmac HMAC_MD5
IKE info: Phase-2 proposal failed: remote No 1, esp algorithm AES <-> local No 2, esp algorithm BLOWFISH
IKE info: Phase-2 proposal failed: remote No 1, esp hmac HMAC_SHA <-> local No 2, esp hmac HMAC_MD5
IKE info: Phase-2 proposal failed: remote No 1, esp algorithm AES <-> local No 3, esp algorithm 3DES
IKE info: Phase-2 proposal failed: remote No 1, esp hmac HMAC_SHA <-> local No 3, esp hmac HMAC_MD5
IKE info: Phase-2 remote proposal 1 failed for peer VPN-TBOTH
IKE info: Phase-2 remote proposal 2 for peer VPN-TBOTH matched with local proposal 1

[VPN-Status] 2010/09/26 18:23:48,030
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer VPN-TBOTH set to 3240 seconds (Responder)

[VPN-Status] 2010/09/26 18:23:48,030
IKE info: Phase-2 SA Timeout (Hard-Event) for peer VPN-TBOTH set to 3600 seconds (Responder)

[VPN-Status] 2010/09/26 18:23:48,030
IKE info: Phase-2 [responder] done with 2 SAS for peer VPN-TBOTH rule ipsec-13-VPN-TBOTH-pr0-l0-r0
IKE info: rule:' ipsec 0.0.0.0/0.0.0.0 <-> 193.2.8.63/255.255.255.255 '
IKE info: SA ESP [0x06b7b426] alg AES keylength 256 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x0f376c7a] alg AES keylength 256 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/0 kb) hard (3600 sec/0 kb)
IKE info: tunnel between src: 87.184.20.215 dst: 46.115.235.39

[VPN-Status] 2010/09/26 18:23:48,040
VPN: wait for IKE negotiation from VPN-TBOTH (46.115.235.39)

[VPN-Status] 2010/09/26 18:23:49,120
VPN: VPN-TBOTH (46.115.235.39) connected

root@DSL-BN:/
>
[VPN-Status] 2010/09/26 18:24:07,880
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer VPN-TBOTH Seq-Nr 0x272, expected 0x272

[VPN-Status] 2010/09/26 18:24:07,880
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer VPN-TBOTH, sequence nr 0x272

[VPN-Status] 2010/09/26 18:24:28,060
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer VPN-TBOTH Seq-Nr 0x273, expected 0x273

[VPN-Status] 2010/09/26 18:24:28,060
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer VPN-TBOTH, sequence nr 0x273

[VPN-Status] 2010/09/26 18:24:48,740
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer VPN-TBOTH Seq-Nr 0x274, expected 0x274

[VPN-Status] 2010/09/26 18:24:48,740
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer VPN-TBOTH, sequence nr 0x274

[VPN-Status] 2010/09/26 18:25:09,670
IKE info: NOTIFY received of type ISAKMP_NOTIFY_DPD_R_U_THERE for peer VPN-TBOTH Seq-Nr 0x275, expected 0x275

[VPN-Status] 2010/09/26 18:25:09,670
IKE info: ISAKMP_NOTIFY_DPD_R_U_THERE_ACK sent for Phase-1 SA to peer VPN-TBOTH, sequence nr 0x275

trace - VPN-Status
VPN-Status OFF

Bravestarr · Beitrag von **Bravestarr** » 27 Sep 2010, 10:26

Dann ist da schon das Problem. Mehr als eine SA für die Verbindung kann das iPad nicht verwalten. Dann zeigt sich genau dein Fehlerbild. Es ist also ein Konfigproblem.

NickD · Beitrag von **NickD** » 27 Sep 2010, 10:30

Hi,

ja, das habe ich auch vermutet

. Nur wo genau, das ist die Frage. Was könnte ich noch machen?

Gruß,

Bravestarr · Beitrag von **Bravestarr** » 27 Sep 2010, 10:35

Das werden sicherlich die definierten VPN-Regeln in der Firewall sein. Vielleicht existiert eine Networks-Networks-Regel... Die muss raus, denn es darf nur genau eine SA für das iPad geben.

NickD · Beitrag von **NickD** » 27 Sep 2010, 10:44

Wie kann ich tracen welche SAs (in diesen Fall VPN-Firewall-Regel) beim Aufbau des Tunnels erstellt werden. Mit "show VPN" sehe ich nur die Möglichkeiten (sie werden angezeigt, auch wenn die VPN-Verbindung nicht aufgebaut wurde).

Gruß,

Bravestarr · Beitrag von **Bravestarr** » 27 Sep 2010, 10:47

show vpn zeigt ja genau die SAs für die Tunnel... Das sind keine Möglichkeiten, sondern die aktuell gültigen.

In der Firewall würde ich als erstes nachsehen. Alternativ machst du einen Supportfall bei LANCOM direkt auf und verlinkst auf diesen Eintrag im Forum. Das Problem sollte in ein paar Minuten gefunden sein, wenn die Konfiguration vorliegt.