LANCOM 9100 VPN: Vodafone CDA / APN einrichten

Glenn · Beitrag von **Glenn** » 19 Apr 2012, 10:23

Hallo Forum ...

Da LANCOM auf meine Support-Anfrage nicht antwortet, versuche ich nun mal hier mein Glück.

Wir haben hier einen LANCOM 9100 VPN und versuchen gerade einen IPSec-Tunnel zu unserem Handy-Provider Vodafone aufzubauen. Das Ganze läuft unter dem Thema "CDA" bzw. "APN".

Grundsätzlich funktioniert das Gleiche schon mit der Telekom. Auch dort haben wir einen APN angemietet und die entsprechend eingebuchten Handys sind nun dirtekt mit unserem Firmen-Netzwerk verbunden.

Leider klappt die Einrichtung bei Vodafone nicht ... und wir wissen im Moment leider nicht mehr weiter.

Vielleicht hat ja hier schon jemand einen Vodafone-APN eingerichtet ...

Unser Problem:

Die Phase 1 wird noch korrekt aufgebaut - bei der Phase 2 meldet sich dann der Vodafone-Radius und greift auf unsere externe (öffentliche) IP zu ... und findet kein passendes Proposal.

Im Trace sieht das so aus:

Code: Alles auswählen

[VPN-Status] 2012/04/17 11:07:49,904  Devicetime: 2012/04/17 11:07:48,220
IKE info: Phase-1 [responder] got INITIAL-CONTACT from peer CDA (139.7.127.250)

[VPN-Status] 2012/04/17 11:07:49,904  Devicetime: 2012/04/17 11:07:48,220
IKE info: Phase-1 [responder] for peer CDA between initiator id  139.7.127.250, responder id  xxx.xxx.xxx.xxx done
IKE info: SA ISAKMP for peer CDA encryption aes-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)

[VPN-Status] 2012/04/17 11:07:50,420  Devicetime: 2012/04/17 11:07:48,790
IKE info: Phase-2 failed for peer CDA: no rule matches the phase-2 ids  139.7.146.26 <->  xxx.xxx.xxx.xxx
IKE log: 110748.000000 Default message_negotiate_sa: no compatible proposal found
IKE log: 110748.000000 Default dropped message from 139.7.127.250 port 500 due to notification type NO_PROPOSAL_CHOSEN
IKE info: dropped message from peer CDA 139.7.127.250 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2012/04/17 11:07:50,720  Devicetime: 2012/04/17 11:07:48,890
policy manager error indication: CDA (139.7.127.250), cause: 12801

[VPN-Status] 2012/04/17 11:07:50,720  Devicetime: 2012/04/17 11:07:48,890
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for CDA (139.7.127.250)

"xxx.xxx.xxx.xxx" ist dabei unsere öffentliche IP.

Die Vodafone-IP 139.7.127.250 ist wohl der Vodafone-GGSN, die IP 139.7.146.26 ist der Vodafone-RADIUS, der mit unserem eigenen RADIUS "reden" möchte.
Unser RADIUS lauscht aber nur im LAN auf der 172.16.24.2 ... und ist auf der externen IP gar nicht erreichbar.

Vodafone möchte von unserer internen Netz-Struktur aber gar nicht wissen und demzufolge auch keine Pakete durch den VPN-Tunnel ins "interne" Netz schicken. Man möchte dort eine öffentliche IP von uns haben ...

Auf meiner Suche nach einer Lösung stoße ich immer wieder auf "Netzbeziehungen" und "NAT". Unter "Netzbeziehungen" sind wohl die Zugriffsrechte der Firewall gemeint, welche gesetzt sind.
"NAT"-en möchte ich unsere einzige öffentliche IP nicht auf den internen Radius.

Wie gesagt, bei der Telekom funktioniert's problemlos.

Hier mal ein Trace der Telekom-Aufbaus ... sieht etwas anders aus:

Code: Alles auswählen

[VPN-Status] 2012/04/19 10:15:52,515  Devicetime: 2012/04/19 10:15:48,440
IKE info: Phase-1 [responder] for peer GGSN between initiator id  80.187.254.92, responder id  xxx.xxx.xxx.xxx done
IKE info: SA ISAKMP for peer GGSN encryption 3des-cbc authentication sha1
IKE info: life time ( 86400 sec/ 0 kb)

[VPN-Status] 2012/04/19 10:15:53,340  Devicetime: 2012/04/19 10:15:49,430
IKE info: Phase-2 [responder] done with 2 SAS for peer GGSN rule ipsec-14-GGSN-pr0-l0-r0
IKE info: rule:' ipsec 0.0.0.0/0.0.0.0 <-> 172.16.0.0/255.255.248.0 '
IKE info: SA ESP [0x931b8605]  alg 3DES keylength 192 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0x7c7acd4b]  alg 3DES keylength 192 +hmac HMAC_SHA incoming
IKE info: life soft( 3240 sec/1658880 kb) hard (3600 sec/1843200 kb)
IKE info: tunnel between src: xxx.xxx.xxx.xxx dst: 80.187.254.92

Jemand 'ne Idee?

Glenn · Beitrag von **Glenn** » 19 Apr 2012, 11:01

Nachtrag:

Die Phase-II-Rules sind grundsätzlich in Ordnung.

Wir haben Folgendes getestet:
Phase-I wurde zuerst von Vodafone aufgebaut -> der Vodafone-RADIUS hat dann mal nicht gesendet -> Die Phase-II wurde von mir durch einen Ping ins VPN-Netz initiiert

Hier der Trace:

Code: Alles auswählen

[VPN-Status] 2012/04/17 15:12:48,570  Devicetime: 2012/04/17 15:12:46,870
IKE info: Phase-1 [responder] got INITIAL-CONTACT from peer CDA (139.7.127.250)

[VPN-Status] 2012/04/17 15:12:48,570  Devicetime: 2012/04/17 15:12:46,880
IKE info: Phase-1 [responder] for peer CDA between initiator id  139.7.127.250, responder id  xxx.xxx.xxx.xxx done
IKE info: SA ISAKMP for peer CDA encryption aes-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)

[VPN-Status] 2012/04/17 15:13:42,920  Devicetime: 2012/04/17 15:13:40,950
VPN: WAN state changed to WanCall for CDA (139.7.127.250), called by: 006ba29c

[VPN-Status] 2012/04/17 15:13:42,920  Devicetime: 2012/04/17 15:13:40,950
VPN: connecting to CDA (139.7.127.250)

[VPN-Status] 2012/04/17 15:13:42,920  Devicetime: 2012/04/17 15:13:40,970
VPN: start IKE negotiation for CDA (139.7.127.250)

[VPN-Status] 2012/04/17 15:13:43,576  Devicetime: 2012/04/17 15:13:40,970
VPN: WAN state changed to WanProtocol for CDA (139.7.127.250), called by: 006ba29c

[VPN-Status] 2012/04/17 15:13:57,662  Devicetime: 2012/04/17 15:13:54,320
IKE info: Phase-2 [inititiator] done with 2 SAS for peer CDA rule ipsec-37-CDA-pr0-l0-r0
IKE info: rule:' ipsec 172.16.24.0/255.255.255.0 <-> 172.16.8.0/255.255.248.0 '
IKE info: SA ESP [0xa2e65a8a]  alg AES keylength 256 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0x79508c40]  alg AES keylength 256 +hmac HMAC_SHA incoming
IKE info: life soft( 2880 sec/0 kb) hard (3600 sec/0 kb)
IKE info: tunnel between src: xxx.xxx.xxx.xxx dst: 139.7.127.250

Wie man sieht, wird die Phase-II dann zum Vodafone-GGSN (139.7.127.250) aufgebaut und dann klappt's.
Offensichtlich gibt's ein Problem, wenn der Vodafone-RADIUS mit seiner IP dazwischen funkt und die Phase-II aufbauen will.

Nach Aussage der Vodafone-Mitarbeiter ist dies aber die Konfiguration, die sie bei ??-zig anderen Kunden erfolgreich einsetzen. Gibt ja wohl noch mehr Leute, die einen eigenen APN betreiben ...

backslash · Beitrag von **backslash** » 19 Apr 2012, 12:04

Hi Glenn

es gibt schon einen deutlichen Uterschied zwischen deinen Vodafone- und Telekom-Traces, nämlich diesen:

Vodafone:

IKE info: rule:' ipsec 172.16.24.0/255.255.255.0 <-> 172.16.8.0/255.255.248.0 '

Telekom

IKE info: rule:' ipsec 0.0.0.0/0.0.0.0 <-> 172.16.0.0/255.255.248.0 '

da liegen schon ganz andere Regeln zugrunde - so wurde im Telekom-Trace eine SA für Defaultroute ausgehandelt während es bei Vodafone nur eine für dein lokales Netz ist (172.16.24.0/255.255.255.0)

Und im nicht-funktionierenden Fall will Vodafone sogar eine Phase-2 für öffentliche IPs aushandeln (139.7.146.26 <-> xxx.xxx.xxx.xxx ). Das ist in jedem Fall eine Konfiguration mit nicht übereinstimmenden Phase-II-Regeln. Und zwar dürften die auf der Vodaphone-Seite falsch sein, denn schließlich sollen die Handies ihre Daten durch einen Tunnel übertragen, weshalb eine SA mit öffentlichen IPs völlig überflüssig ist.

Nach Aussage der Vodafone-Mitarbeiter ist dies aber die Konfiguration, die sie bei ??-zig anderen Kunden erfolgreich einsetzen.

dann soll er dir aber auch exakt sagen, welche Phase-II-Regeln du brauchst - das was du jedenfalls konfiguriert hast, kann nicht mit dem übereinstimmen, was du konfigurieren mußt - oder Vodafone hat richtig M... gebaut...

Gruß
Backlsash