[gelöst] Redundante VPN-Verbindungen

[svensen]

(Namen und IP-Adressen geändert)

Hallo,

ich habe einen 1722 an ADSL und Kabel Deutschland mit Load balancer laufen. Der Kabel-Anschluss ist erst neu dazugekommen. Sinn der Sache ist, dass meine Leitungen nich sonderlich stabil sind, und wenn eine ausfällt, soll's auf der anderen wietergehen. Wenn beide laufen, sollen sich die VPN-Tunnel halt eine Leitung aussuchen.

Beide WAN-Verbindungen haben DynDNS, exemplarisch:
ASDL - hq.dyndns.org - IP 1.2.3.4
KABEL - hq-2.dyndns.org - IP 5.6.7.8

Bei den VPN-Gegenstellen (hier ein 1821+) hatte ich als Gateway immer "hq.dyndns.org" eingetragen, was problemlos funktioniert.
Nun aber habe ich bei den Gegenstellen zusätzlich unter "Weitere entfernte Gateways" noch den hq-2.dyndns.org eingetragen, und hier hakt's:

Wenn die VPN-Verbindung vom lokalen Gateway über ADSL initiiert wird, ist alles OK, über KABEL aber passiert bei der Gegenstelle folgendes:

Code: Alles auswählen

[VPN-Status] 2009/08/07 15:09:53,220
IKE info: The remote server 5.6.7.8:500 peer def-main-peer id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 5.6.7.8:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 5.6.7.8:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server 5.6.7.8:500 peer def-main-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 5.6.7.8:500 peer def-main-peer id <no_id> negotiated rfc-3706-dead-peer-detection


[VPN-Status] 2009/08/07 15:09:53,220
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1

[VPN-Status] 2009/08/07 15:09:53,490
IKE info: set id for sending to device cert id O=Firma,C=DE,CN=GEGENSTELLE

[VPN-Status] 2009/08/07 15:09:53,950
IKE info: Phase-1 [responder] for peer def-main-peer between initiator id O=Firma,C=DE,CN=HQ, responder id O=Firma,C=DE,CN=GEGENSTELLE done
IKE info: SA ISAKMP for peer def-main-peer encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2009/08/07 15:09:53,950
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer def-main-peer set to 97200 seconds (Responder)

[VPN-Status] 2009/08/07 15:09:53,950
IKE info: Phase-1 SA Timeout (Hard-Event) for peer def-main-peer set to 108000 seconds (Responder)

[VPN-Status] 2009/08/07 15:09:54,020
IKE info: Phase-2 failed for peer def-main-peer: no rule matches the phase-2 ids  192.168.3.0/255.255.255.0 <->  192.168.129.0/255.255.255.0
IKE log: 150954.000000 Default message_negotiate_sa: no compatible proposal found
IKE log: 150954.000000 Default dropped message from 5.6.7.8 port 500 due to notification type NO_PROPOSAL_CHOSEN
IKE info: dropped message from peer def-main-peer 5.6.7.8 port 500 due to notification type NO_PROPOSAL_CHOSEN

Was irgendwie schon merkwürdig ist, da das Teil schon regelmäßig die DNS-Abfragen korrekt durchführt, und zwar für beide Einträge. Auch ein Einsetzten der IP-Adresse inter "Weitere entfernte Gateways" führt nicht zum Erfolg.

Bei einer ADSL-initiierten Verbindung sieht's so aus:

Code: Alles auswählen

[VPN-Status] 2009/08/07 16:03:27,180
IKE info: The remote server 1.2.3.4:500 peer HQ id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 1.2.3.4:500 peer HQ id <no_id> supports NAT-T in mode draft
IKE info: The remote server 1.2.3.4:500 peer HQ id <no_id> supports NAT-T in mode draft
IKE info: The remote server 1.2.3.4:500 peer HQ id <no_id> supports NAT-T in mode rfc
IKE info: The remote server 1.2.3.4:500 peer HQ id <no_id> negotiated rfc-3706-dead-peer-detection

[VPN-Status] 2009/08/07 16:03:27,180
IKE info: Phase-1 remote proposal 1 for peer HQ matched with local proposal 1

Es folgt der Zertifikate-Austausch, Phase2 und fertig.
Was läuft da falsch, bzw. mache ich einen Denkfehler?

Danke und Gruß
Sven

[maxtek]

Hi,

Laut erstem trace passen die Netzbeziehungen nicht und der Aufbau der Phase 2 scheitert daran. Das dürfte beim zweiten trace nicht anders aussehen. wo ist denn der Rest des traces der über adsl initiierten Verbindung?

gruss
nils

[svensen]

Hi nils,

Laut erstem trace passen die Netzbeziehungen nicht und der Aufbau der Phase 2 scheitert daran.

Ja, das dachte ich mir auch schon... Nur warum?

Das dürfte beim zweiten trace nicht anders aussehen. wo ist denn der Rest des traces der über adsl initiierten Verbindung?

Da sieht alles supi aus, wie schon geschrieben. Daher hatte ich den Rest des Traces auch weggelassen. Aber wenn's hilft, kommt hier der Rest (Namen und Adressen geändert):

Code: Alles auswählen

[VPN-Status] 2009/08/07 16:03:27,950
IKE info: Phase-1 [responder] for peer HQ between initiator id O=Firma,C=DE,CN=HQ, responder id O=Firma,C=DE,CN=GEGENSTELLE done
IKE info: SA ISAKMP for peer HQ encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)

[VPN-Status] 2009/08/07 16:03:27,950
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer HQ set to 97200 seconds (Responder)

[VPN-Status] 2009/08/07 16:03:27,950
IKE info: Phase-1 SA Timeout (Hard-Event) for peer HQ set to 108000 seconds (Responder)

[VPN-Status] 2009/08/07 16:03:28,050
IKE info: Phase-2 remote proposal 1 for peer HQ matched with local proposal 1

[VPN-Status] 2009/08/07 16:03:28,250
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer HQ set to 1800 seconds (Responder)

[VPN-Status] 2009/08/07 16:03:28,250
IKE info: Phase-2 SA Timeout (Hard-Event) for peer HQ set to 2000 seconds (Responder)

[VPN-Status] 2009/08/07 16:03:28,250
IKE info: Phase-2 [responder] done with 2 SAS for peer HQ rule ipsec-0-HQ-pr0-l0-r0
IKE info: rule:' ipsec 192.168.129.0/255.255.255.0 <-> 192.168.3.0/255.255.255.0 '
IKE info: SA ESP [0x2c241c98]  alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x7d911a2d]  alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 11.12.13.14 dst: 1.2.3.4  

[VPN-Status] 2009/08/07 16:03:28,260
VPN: wait for IKE negotiation from HQ (1.2.3.4)

[VPN-Status] 2009/08/07 16:03:28,280
IKE info: Phase-2 remote proposal 1 for peer HQ matched with local proposal 1

[VPN-Status] 2009/08/07 16:03:28,480
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer HQ set to 1800 seconds (Responder)

[VPN-Status] 2009/08/07 16:03:28,490
IKE info: Phase-2 SA Timeout (Hard-Event) for peer HQ set to 2000 seconds (Responder)

[VPN-Status] 2009/08/07 16:03:28,490
IKE info: Phase-2 [responder] done with 2 SAS for peer HQ rule ipsec-0-HQ-pr0-l0-r0
IKE info: rule:' ipsec 192.168.129.0/255.255.255.0 <-> 192.168.3.0/255.255.255.0 '
IKE info: SA ESP [0x3c5c47fe]  alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x61d02a23]  alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 11.12.13.14 dst: 1.2.3.4  

[IP-Router] 2009/08/07 16:03:29,170
IP-Router Rx (HQ, RtgTag: 0): 
DstIP: 192.168.1.75, SrcIP: 192.168.3.6, Len: 33, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 3283, SrcPort: 3283
Route: LAN Tx (INTRANET): 

[VPN-Status] 2009/08/07 16:03:29,490
VPN: HQ (1.2.3.4) connected

Beste Grüße
Sven

[maxtek]

moin!

Das einzige was mir da spontan auffällt ist die Tatsache, dass die Netze dann in umgekehrter Reihenfolge gelistet werden

IKE info: Phase-2 failed for peer def-main-peer: no rule matches the phase-2 ids 192.168.3.0/255.255.255.0 <-> 192.168.129.0/255.255.255.0

IKE info: Phase-2 [responder] done with 2 SAS for peer HQ rule ipsec-0-HQ-pr0-l0-r0
IKE info: rule:' ipsec 192.168.129.0/255.255.255.0 <-> 192.168.3.0/255.255.255.0 '

Mhhh ... Hast Du den LC support da schon mal bemüht und die Configs mitgeschickt?

gruss
nils

[svensen]

Das einzige was mir da spontan auffällt ist die Tatsache, dass die Netze dann in umgekehrter Reihenfolge gelistet werden

IKE info: Phase-2 failed for peer def-main-peer: no rule matches the phase-2 ids 192.168.3.0/255.255.255.0 <-> 192.168.129.0/255.255.255.0

IKE info: Phase-2 [responder] done with 2 SAS for peer HQ rule ipsec-0-HQ-pr0-l0-r0
IKE info: rule:' ipsec 192.168.129.0/255.255.255.0 <-> 192.168.3.0/255.255.255.0 '

Ja, das ist in der Tat eigenartig... Und war mir vorher noch gar nicht aufgefallen.

Mhhh ... Hast Du den LC support da schon mal bemüht und die Configs mitgeschickt?

Nein, das habe ich noch nicht gemacht. Hatte bisher mit dem LANCOM-Forum immer bessere Erfahrungen als mit dem Support. Aber vielleicht sollte ich das doch nochmal versuchen.

Danke und Gruß
Sven

[svensen]

Ich hab'noch was...

Bei der Gegenstelle ein "show vpn" hilft vielleicht bei der Aufklärung:

Code: Alles auswählen

> show vpn      

VPN SPD and IKE configuration:

  # of connections = 2

  Connection #1              
  (... geht woanders hin und funktioniert)

  Connection #2                 192.168.129.0/255.255.255.0:0 <-> 192.168.3.0/255.255.255.0:0 any

    Name:                       HQ
    Unique Id:                  ipsec-0-HQ-pr0-l0-r0
    Flags:                      main-mode
    Local  Network:             IPV4_ADDR_SUBNET(any:0, 192.168.129.0/255.255.255.0)
    Local  Gateway:             IPV4_ADDR(any:0, 11.12.13.14)
    Remote Gateway:             IPV4_ADDR(any:0, 1.2.3.4)
    Remote Network:             IPV4_ADDR_SUBNET(any:0, 192.168.3.0/255.255.255.0)

Es ist also vollkommen klar, dass die über 5.6.7.8 reinkommende Verbindung nicht richtig zugeordnet wird. Unter "Weitere entfernte Gateways" ist für die Gegenstelle HQ aber die entsprechende Adresse eingetragen. Nur offenbar wird diese nicht für die VPN-Regelerzeugung bzw. Aufbau von Netzbeziehungen ausgewertet.
Ich weiß jetzt nur nicht, ob das das erwünschte, bzw. vom Hersteller vorgesehene Verhalten des Routers ist, oder ob hier möglicherweise ein Fehler vorliegt. Oder eine Fehlkonfiguration. VPN-Regelerzeugung hab ich auf "Automatisch" und "Aufbau Netzbeziehungen " auf "Jede einzeln nach Bedarf"
Vielleicht kann man da auch über VPN-Firewall-Regeln weiterhelfen - nur wie die aussehen könnten, weiß ich nicht.

[backslash]

Hi svensen,

wenn du auf beiden Seiten redundante Einwahlen hast - und die Verbindung auch von beiden Seiten aus aufgebaut werden soll, dann mußt du mit dynamic VPN arbeiten, weil nur so die VPN-Regeln angepaßt werden können.

Wenn der Aufbau nur aus einer Richtung erfolgen soll, dann kannst du zwar auch ohne dynamic VPN arbeiten, mußt dann aber entweder den Aggressive-Mode (angreifbar) oder Zertifikate (aufwendig) nutzen

Gruß
Backslash

[svensen]

Danke, backslash.

Hab' jetzt den Tunnel auf dynamic VPN mit UDP-Paket umgestellt, funktioniert super. Dabei habe ich mich früher schon immer gefragt, wozu diese Option wohl gut sein könnte, wenn ja die IP-Adresse der Gegenstelle bekannt ist... Was ich bei Dynamic VPN nur so unübersichtlich finde, sind die Einträge unter Gegenstellen ISDN und in der PPP-Liste. Diese Tabellen haben ja im ursprünglichen Sinne nichts mit VPN zu tun.

Anyway, funktioniert. Danke.

Gruß
Sven

[backslash]

Hi svensen

Was ich bei Dynamic VPN nur so unübersichtlich finde, sind die Einträge unter Gegenstellen ISDN und in der PPP-Liste. Diese Tabellen haben ja im ursprünglichen Sinne nichts mit VPN zu tun.

aber mit dem Adreßaustausch über D- bzw. B-Kanal...

Gruß
Backslash

[p0ddie]

*bump* Sehr interessant, die Sache. Wenn ich die beiden Leitungen nicht im Load Balancer haben will, sondern definitiv immer über Leitung 1 Internet und VPN laufen lassen will und nur auf die zweite Leitung umgeschaltet werden soll, wenn die erste wegbricht, wie konfiguriere ich das dann?

Kann ich irgendwo Prioritäten für die Leitungen auswählen?

Ich frage, weil in meinem Fall Leitung 1 auf beiden Seiten eine VDSL-Leitung wäre und Leitung 2 eine langsame 2MBit/s QSC-Leitung.

Auch, wenn der Thread uralt ist, vielleicht kannst du, backslash, dazu doch noch etwas sagen! Danke

[backslash]

Hi p0ddie

Wenn ich die beiden Leitungen nicht im Load Balancer haben will, sondern definitiv immer über Leitung 1 Internet und VPN laufen lassen will und nur auf die zweite Leitung umgeschaltet werden soll, wenn die erste wegbricht, wie konfiguriere ich das dann?

Der einfachste Fall ist ein einfaches Backup-Szenario: Dazu trägst du die zweite Leitung einfach in der Backup-Tabelle (Kommunkation -> Ruf-Verwaltung -> Backup-Tabelle) als Backupleitung für die erste ein... Das geht aber nur, solange die zweite Leitung nicht für irgendwelche sonstigen Dienste genutzt wird...


Wenn die zweite Leitung nicht als reine Backupleitung dient, sondern immer Online ist, dann mußt du mit Policy based Routing arbeiten, d.h. du trägst zunächst zwei zusätzliche Defaultrouten ein, die du mit Routing-Tags - z.B. 1 und 2 - versiehst. Mit Hilfe dieser Routing-Tags kannst du nun in der VPN-Verbindungsliste (VPN -> Allgemein -> VPN-Verbindungsliste) festlegen, auf welcher der Leitungen die VPN-Verbindung aufgebaut werden soll.

Zum Umschalten im Fehlerfall bleibt dir leider nichts anderes übrig, als über die Aktionstabelle (Kommunikation -> Allgemein -> Aktions-tabelle) beim Auf- und Abbau der Verbindungen die Routing-Tags bei den VPN-Verbindungen passend umzusetzen

Gruß
Backslash

[p0ddie]

Cool, danke! Da das reine Backupleitungen sein sollen, werde ich das einfach mit der Backuptabelle machen, denke ich - das sollte das Einfachste sein. Eine andere Option, wie ich las wäre, das mit dynamic VPN zu machen. Ich spiele da mal rum, aber gut zu wissen,d ass es auf jeden Fall geht.