Fehlermeldung nach vielen Stunden - Keine Regel für ID's...

Hagen2000 · Beitrag von **Hagen2000** » 13 Nov 2014, 11:15

Hallo zusammen,

ich hatte hier im Forum schon ähnliche Fälle gefunden, bin aber aus den Antworten nicht schlau geworden.
Die Netzwerkbeziehungen sind hier eigentlich trivial, d.h. es liegt eine LAN-LAN-Kopplung vor.
Wir haben für eine standortübergreifende Entwicklung ein weiteres VPN konfiguriert, die Gegenstelle ist von Check Point.
VPN funktioniert soweit, aber so nach ca. 1 Tag erscheint im LANmonitor folgende VPN-Fehlermeldung:

Code: Alles auswählen

Keine Regel für ID's gefunden - unbekannte Verbindung oder fehlerhafte ID (z.B. IP-Netzwerkdefinition) (Passiver Verbindungsaufbau, IPSec) [0x3201]

Wir der Fehler gelöscht, so wechselt der Status der VPN-Verbindung auf:

Code: Alles auswählen

Anliegender Ruf von GEGENSTELLE

Was will mir die obige Fehlermeldung sagen (0x3201)?
Wo muss ich ansetzen, um die Fehlersituation dauerhaft zu vermeiden?
Was ist eigentlich ein passiver Verbindungsaufbau bei VPN?

Vielen Dank für Eure Hilfe!

backslash · Beitrag von **backslash** » 13 Nov 2014, 12:37

Hi Hagen2000,

hier stimmen die Netzbeziehungen nicht überein: Die Gegenstelle (Checkpoint) fordert eine Beziehung, die im LANCOM nicht erlaubt wurde. Am Einfachsten machst du einen VPN-Status-Trace davon und schaust darin nach, welche Netzbeziehung dei Gegenstelle gefordert hat. Danach hast due zwei Möglichkeiten: Entweder du richtest diese Netzbeziehung auch im LANCOM ein oder du korrigierst die Konfig der Gegenstelle (d.h. nimmst dort die Netzbeziehung raus)

Gruß
Backslash

Hagen2000 · Beitrag von **Hagen2000** » 13 Nov 2014, 13:31

Hallo Backslash,

hier mal ein VPN-Status Trace vom Verbindungsaufbau. Für mich schaut das alles plausibel aus.

Code: Alles auswählen

[VPN-Status] 2014/11/13 13:04:07,921  Devicetime: 2014/11/13 13:04:08,006
vpn-maps[25], remote: GEGENSTELLE, nego, static-name, connected-by-name

[VPN-Status] 2014/11/13 13:04:07,921  Devicetime: 2014/11/13 13:04:08,006
VPN: start IKE negotiation for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/13 13:04:07,921  Devicetime: 2014/11/13 13:04:08,006
VPN: WAN state changed to WanProtocol for GEGENSTELLE (1.1.1.1), called by: 00xxxxxx

[VPN-Status] 2014/11/13 13:04:07,921  Devicetime: 2014/11/13 13:04:08,066
IKE info: Phase-2 SA Rekeying Timeout (Soft-Event) for peer GEGENSTELLE set to 23040 seconds (Initiator)

[VPN-Status] 2014/11/13 13:04:07,921  Devicetime: 2014/11/13 13:04:08,066
IKE info: Phase-2 SA Timeout (Hard-Event) for peer GEGENSTELLE set to 28800 seconds (Initiator)

[VPN-Status] 2014/11/13 13:04:07,921  Devicetime: 2014/11/13 13:04:08,067
IKE info: Phase-2 [inititiator] done with 2 SAS for peer GEGENSTELLE rule ipsec-0-GEGENSTELLE-pr0-l0-r0
IKE info: rule:' ipsec 10.x.x.x/255.255.255.0 <-> 192.168.y.y/255.255.255.0 '
IKE info: SA ESP [0xa000bddc]  alg AES_CBC keylength 256 +hmac HMAC_SHA outgoing
IKE info: SA ESP [0x19372dea]  alg AES_CBC keylength 256 +hmac HMAC_SHA incoming
IKE info: life soft( 23040 sec/1600000 kb) hard (28800 sec/2000000 kb)
IKE info: tunnel between src: 2.2.2.2 dst: 1.1.1.1  

[VPN-Status] 2014/11/13 13:04:09,093  Devicetime: 2014/11/13 13:04:09,067
VPN: GEGENSTELLE connected

Ich hoffe, alle vertraulichen Daten korrekt anonymisiert zu haben. Unter dem Begriff "Netzbeziehungen" stelle ich mir vor, dass der VPN-Tunnel das Netz 10.x.x.x/24 mit dem Netz 192.168.y.y/24 verbindet. Wie komme ich hier weiter?

backslash · Beitrag von **backslash** » 13 Nov 2014, 16:25

Hi Hagen2000,

Ich hoffe, alle vertraulichen Daten korrekt anonymisiert zu haben.

ja...

Unter dem Begriff "Netzbeziehungen" stelle ich mir vor, dass der VPN-Tunnel das Netz 10.x.x.x/24 mit dem Netz 192.168.y.y/24 verbindet.

ja genau darum geht es...

Wie komme ich hier weiter?

bis hier ist der Fehler noch nicht aufgetreten. Du mußt nun den Trace solange mitlaufen lassen bis der Fehler auftritt, dann findest du im Trace, welche Netzbeziehung von der Gegenseite angefordert, aber vom LANCOM nicht akzeptiert wurde. Das sieht dann so aus:

Code: Alles auswählen

[VPN-Status] 2000/03/28 07:31:57,730
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  x.x.x.x/255.255.255.0 <->  y.y.y.y/255.255.255.0
IKE log: 073157.000000 Default message_negotiate_sa: no compatible proposal found
IKE log: 073157.000000 Default dropped message from 1.1.1.1 port 1234 due to notification type NO_PROPOSAL_CHOSEN
IKE info: dropped message from peer GEGENSTELLE 1.1.1.1 port 1234 due to notification type NO_PROPOSAL_CHOSEN

x.x.x.x <-> y.y.y.y beschreibt dann die abgelehnte Nertzbeziehung.

Problematisch wird es, wenn das LANCOM etwas fordert, was die Gegenseite ablehnt, denn das sieht man nur durch eine lapidare Meldung der Gegenstelle:

Code: Alles auswählen

[VPN-Status] 2014/11/13 16:17:24,357
IKE info: NOTIFY received of type NO_PROPOSAL_CHOSEN for peer GEGENSTELLE


[VPN-Status] 2014/11/13 16:17:24,357
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12546

[VPN-Status] 2014/11/13 16:17:24,357
VPN: Error: IPSEC-I-No-proposal-matched (0x3102) for GEGENSTELLE (1.1.1.1)

hier mußt du dann auf der Gegenseite tracen, was da nicht akzeptiert wurde...

Oder aber du schaust dir die VPN-Policies per "show vpn" an. Da bekommst du dann eine Liste der konfigurierten Netzbeziehungen in der Form:

Code: Alles auswählen

  Connection #5  ikev1          192.168.100.0/255.255.255.0:0 <-> 192.168.200.0/255.255.255.0:0 any

    Name:                       GEGENSTELLE
    Unique Id:                  ipsec-3-GEGENSTELLE -pr0-l2-r0
    Flags:                      main-mode
    Local  Network:             IPV4_ADDR_SUBNET(any:0, x.x.x.x/255.255.255.0)
    Local  Gateway:             IPV4_ADDR(any:0, 2.2.2.2)
    Remote Gateway:             IPV4_ADDR(any:0, 1.1.1.1)
    Remote Network:             IPV4_ADDR_SUBNET(any:0, y.y.y.y/255.255.255.0)

Wenn die Gegenseite etwas ähnliches bietet, dann kannst du auch darüber die Netzbeziehungen vergleichen.

Gruß
Backslash

Hagen2000 · Beitrag von **Hagen2000** » 17 Nov 2014, 10:32

Hallo Backslash,

ich habe nochmal gründlich das LCOS Referenzhandbuch zum Thema VPN-Beziehungen durchgearbeitet und keine Fehler finden können, auch ein "show vpn" hat nichts unerwartetes zu Tage gefördert.

Folgende Bemerkung von Dir hat jedoch indirekt geholfen:

Problematisch wird es, wenn das LANCOM etwas fordert, was die Gegenseite ablehnt, denn das sieht man nur durch eine lapidare Meldung der Gegenstelle:
Code: Alles auswählen
[VPN-Status] 2014/11/13 16:17:24,357
IKE info: NOTIFY received of type NO_PROPOSAL_CHOSEN for peer GEGENSTELLE

Was mich schon immer gestört hatte, waren diese IKE- und IPsec-Proposal-Listen, die der Wizard erstellt. Ich habe für die VPN-Verbindung jetzt eigene Listen erstellt, die jeweils nur ein einziges Proposal enthalten, das jeweils exakt die Parameter hat, die für die Gegenstelle verwendet werden sollen. Dabei ist mir aufgefallen, dass die Gültigkeitszeit für das IKE-Proposal mit 108.000 Sekunden von den geforderten 86.400 Sekunden abwich. Ähnliches beim IPsec-Proposal: 28.800 statt gefordert 216.000 Sekunden.

Ich war immer davon ausgegangen, dass im Zweifelsfall die kürzere der beiden Zeiten gelten würde. War das ein Irrtum?
War die Abweichung der Gültigkeitszeiten letztlich das Problem?

Die Fehlermeldung ist jedenfalls bislang nicht mehr aufgetreten.

backslash · Beitrag von **backslash** » 17 Nov 2014, 12:41

Hi Hagen2000

Ich war immer davon ausgegangen, dass im Zweifelsfall die kürzere der beiden Zeiten gelten würde. War das ein Irrtum?
War die Abweichung der Gültigkeitszeiten letztlich das Problem?

Die Zeiten sollten eigfentlich kein Problem sein... Nicht unterstützte Verschlüsselungs- oder Hashing-Algorithmen schon eher. Das müßtest du aber auf der Gegenseite tracen - oder jetzt einfach glücklich sein, da der Fehler nicht mehr auftritt...

Gruß
Backslash

Hagen2000 · Beitrag von **Hagen2000** » 17 Nov 2014, 14:12

Hallo Backslash,

hm. In den vom Wizard erstellten Proposal-Listen war das erste Proposal jeweils das passende, daher hatte ich diese Listen erst einmal verwendet. Letztlich verwenden meine von Hand erstellten Listen jetzt jeweils eine Kopie des jeweils ersten Proposals - mit angepasster Gültigkeitsdauer.

Vielleicht liegt der Unterschied ja auch darin, dass jetzt keine von der Gegenstelle unakzeptierten Proposals (bzgl. Verschlüsselung / Hash) in den Proposal-Listen auftauchen und somit auch nicht durchprobiert werden. Leider kann ich ohne größeren Aufwand keine Informationen über das Geschehen an der Gegenstelle erhalten.

Ich bin auch dafür, die Sache jetzt abzuschließen.

Auf jeden Fall vielen Dank für die Hilfe.

Hagen2000 · Beitrag von **Hagen2000** » 21 Nov 2014, 16:14

So, jetzt ist der Fehler wieder aufgetreten. Folgendes hat der Tracer aufgezeichnet:

Code: Alles auswählen

[VPN-Status] 2014/11/21 11:32:21,341  Devicetime: 2014/11/21 11:32:27,352
VPN: GEGENSTELLE (1.1.1.1)  disconnected


[VPN-Status] 2014/11/21 11:39:51,560  Devicetime: 2014/11/21 11:39:57,534
IKE info: Phase-1 remote proposal 1 for peer GEGENSTELLE matched with local proposal 1

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,589
IKE info: Phase-1 [responder] for peer GEGENSTELLE initiator id  172.16.a.b, responder id  2.2.2.2
IKE info: initiator cookie: 0xef666e83c40e6971, responder cookie: 0x94d23095e4095573
IKE info: SA ISAKMP for peer GEGENSTELLE encryption aes-cbc authentication SHA1
IKE info: life time ( 86400 sec/ 0 kb)

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,589
IKE info: Phase-1 SA Rekeying Timeout (Soft-Event) for peer GEGENSTELLE set to 77760 seconds (Responder)

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,589
IKE info: Phase-1 SA Timeout (Hard-Event) for peer GEGENSTELLE set to 86400 seconds (Responder)

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,616
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 113957.616072 Default message_negotiate_sa: no compatible proposal found
IKE log: 113957.616115 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,616
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,616
VPN: WAN state changed to WanCalled for GEGENSTELLE (1.1.1.1), called by: 009cba0c

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,618
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,618
vpn-maps[25], remote: GEGENSTELLE, idle, static-name

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,620
selecting next remote gateway using strategy eFirst for GEGENSTELLE
     => no remote gateway selected

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,620
selecting first remote gateway using strategy eFirst for GEGENSTELLE
     => CurrIdx=0, IpStr=>1.1.1.1<, IpAddr=1.1.1.1, IpTtl=0s

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,621
VPN: installing ruleset for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,621
VPN: WAN state changed to WanDisconnect for GEGENSTELLE (1.1.1.1), called by: 009cba0c

[VPN-Status] 2014/11/21 11:39:51,591  Devicetime: 2014/11/21 11:39:57,621
VPN: WAN state changed to WanIdle for GEGENSTELLE (1.1.1.1), called by: 009cba0c

[VPN-Status] 2014/11/21 11:39:53,748  Devicetime: 2014/11/21 11:39:59,616
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 113959.616398 Default message_negotiate_sa: no compatible proposal found
IKE log: 113959.616442 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:39:53,748  Devicetime: 2014/11/21 11:39:59,616
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:39:53,748  Devicetime: 2014/11/21 11:39:59,616
VPN: WAN state changed to WanCalled for GEGENSTELLE (1.1.1.1), called by: 009cba0c

[VPN-Status] 2014/11/21 11:39:53,748  Devicetime: 2014/11/21 11:39:59,616
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:39:55,826  Devicetime: 2014/11/21 11:40:01,616
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114001.616290 Default message_negotiate_sa: no compatible proposal found
IKE log: 114001.616333 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:39:55,826  Devicetime: 2014/11/21 11:40:01,616
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:39:55,826  Devicetime: 2014/11/21 11:40:01,616
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:39:57,794  Devicetime: 2014/11/21 11:40:03,616
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114003.616712 Default message_negotiate_sa: no compatible proposal found
IKE log: 114003.616755 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:39:57,794  Devicetime: 2014/11/21 11:40:03,617
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:39:57,794  Devicetime: 2014/11/21 11:40:03,617
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:39:59,873  Devicetime: 2014/11/21 11:40:05,616
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114005.616531 Default message_negotiate_sa: no compatible proposal found
IKE log: 114005.616575 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:39:59,873  Devicetime: 2014/11/21 11:40:05,616
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:39:59,873  Devicetime: 2014/11/21 11:40:05,616
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:40:01,841  Devicetime: 2014/11/21 11:40:07,616
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114007.616998 Default message_negotiate_sa: no compatible proposal found
IKE log: 114007.617041 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:01,841  Devicetime: 2014/11/21 11:40:07,617
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:01,841  Devicetime: 2014/11/21 11:40:07,617
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)

[VPN-Status] 2014/11/21 11:40:03,919  Devicetime: 2014/11/21 11:40:09,617
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114009.617897 Default message_negotiate_sa: no compatible proposal found
IKE log: 114009.617940 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:03,919  Devicetime: 2014/11/21 11:40:09,618
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:03,919  Devicetime: 2014/11/21 11:40:09,618
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)


[VPN-Status] 2014/11/21 11:40:07,857  Devicetime: 2014/11/21 11:40:13,617
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114013.617977 Default message_negotiate_sa: no compatible proposal found
IKE log: 114013.618020 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:07,857  Devicetime: 2014/11/21 11:40:13,618
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:07,857  Devicetime: 2014/11/21 11:40:13,618
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)


[VPN-Status] 2014/11/21 11:40:11,794  Devicetime: 2014/11/21 11:40:17,618
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114017.618202 Default message_negotiate_sa: no compatible proposal found
IKE log: 114017.618245 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:11,794  Devicetime: 2014/11/21 11:40:17,618
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:11,794  Devicetime: 2014/11/21 11:40:17,618
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)


[VPN-Status] 2014/11/21 11:40:15,732  Devicetime: 2014/11/21 11:40:21,618
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114021.618572 Default message_negotiate_sa: no compatible proposal found
IKE log: 114021.618614 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:15,732  Devicetime: 2014/11/21 11:40:21,618
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:15,732  Devicetime: 2014/11/21 11:40:21,618
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)


[VPN-Status] 2014/11/21 11:40:19,888  Devicetime: 2014/11/21 11:40:25,618
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114025.619005 Default message_negotiate_sa: no compatible proposal found
IKE log: 114025.619048 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:19,888  Devicetime: 2014/11/21 11:40:25,619
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:19,888  Devicetime: 2014/11/21 11:40:25,619
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)


[VPN-Status] 2014/11/21 11:40:23,716  Devicetime: 2014/11/21 11:40:29,619
IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0
IKE log: 114029.619574 Default message_negotiate_sa: no compatible proposal found
IKE log: 114029.619618 Default dropped message from 1.1.1.1 port 500 due to notification type NO_PROPOSAL_CHOSEN

[VPN-Status] 2014/11/21 11:40:23,716  Devicetime: 2014/11/21 11:40:29,619
policy manager error indication: GEGENSTELLE (1.1.1.1), cause: 12801

[VPN-Status] 2014/11/21 11:40:23,716  Devicetime: 2014/11/21 11:40:29,619
VPN: Error: IPSEC-R-No-rule-matched-IDs (0x3201) for GEGENSTELLE (1.1.1.1)


[TraceStopped] 2014/11/21 16:00:33,357
Used config:
# Trace config
trace + VPN-Status @ GEGENSTELLE

Unser Partner hatte mir als zusätzliche "VPN-ID" die 172.16.a.b genannt. Damit konnte ich nichts anfangen, d.h. ich konnte es in der LANCOM-Konfiguration nirgends unterbringen.
Was kann ich tun, damit der VPN-Tunnel nicht in den Fehlerzustand läuft?

backslash · Beitrag von **backslash** » 21 Nov 2014, 18:29

Hi Hagen2000

Unser Partner hatte mir als zusätzliche "VPN-ID" die 172.16.a.b genannt. Damit konnte ich nichts anfangen, d.h. ich konnte es in der LANCOM-Konfiguration nirgends unterbringen.
Was kann ich tun, damit der VPN-Tunnel nicht in den Fehlerzustand läuft?

der Trace sagt es dir doch schon:

Code: Alles auswählen

IKE info: Phase-2 failed for peer GEGENSTELLE: no rule matches the phase-2 ids  172.16.0.0/255.255.0.0 <->  10.x.x.x/255.255.255.0

Da fordert die Gegenseite eine Netzbeziehung zwischen 172.16.0.0/255.255.0.0 und dem 10er-Netz, d.h. auf der Gegenseite existiert das 172.16.x.x-Netz und von dort kommt ein Paket in dein 10er-Netz. Leg einfach eine Route zum 172.16.x.x-Netz an und binde sie auf die VPN-Verbindung:

Code: Alles auswählen

IP-Address       IP-Netmask       Rtg-tag  Peer-or-IP        Distance  Masquerade  Active   Comment
------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.0.0       255.255.0.0      0        GEGENSTELLE       0         No          Yes

Gruß
Backslash

Hagen2000 · Beitrag von **Hagen2000** » 21 Nov 2014, 18:42

Ok - so etwas hatte ich befürchtet.
1. Ich möchte nicht, dass mit dem Subnetz 172.16.0.0 kommuniziert wird. Vermutlich muss ich dann zusätzlich eine Firewall-Regel einrichten, die dieses Netz wieder sperrt. Muss ich dabei etwas bestimmtes beachten?
2. Was wäre für den (hypothetischen) Fall zu tun, dass das Subnetz 172.16.0.0 bereits zu einer anderen Gegenstelle geroutet wird?

backslash · Beitrag von **backslash** » 24 Nov 2014, 12:22

Hi Hagen2000,

1. Ich möchte nicht, dass mit dem Subnetz 172.16.0.0 kommuniziert wird. Vermutlich muss ich dann zusätzlich eine Firewall-Regel einrichten, die dieses Netz wieder sperrt. Muss ich dabei etwas bestimmtes beachten?

eigentlich nicht... einfach eine Regel anlegen, die einkommenden Traffic aus dem 172.16er-Netz blockt:

Code: Alles auswählen

Name:    Block-172-16-inbound
Aktion:  zurückweisen
Quelle:  Netzwerk 172.16.0.0/255.255.0.0
Ziel:    alle Stationen
Dienste: alle Dienste

Was wäre für den (hypothetischen) Fall zu tun, dass das Subnetz 172.16.0.0 bereits zu einer anderen Gegenstelle geroutet wird?

Versieh die 172.16er Route zur VPN-Gegenstelle mit einem Routing-Tag - dann wird sie im Normalfall nicht mehr gefunden. Fall du selbst doch irgendwann mal Pakete in das Netz schicken willst, dann kannst du das immer noch mit einer Firewallregel erledigen, die diesen Traffic passend umtaggt:

Code: Alles auswählen

Name:         Allow-172-16-outbound
Routing-Tag:  Tag der VPN-Route ins 172.16er-Netz
Aktion:       übetragen
Quelle:       Netzwerk 10.x.x.x/255.255.255.0
Ziel:         Netzwerk 172.16.0.0/255.255.0.0
Dienste:      alle Dienste

Gruß
Backslash

LANCOM-Forum.de

Fehlermeldung nach vielen Stunden - Keine Regel für ID's...

Fehlermeldung nach vielen Stunden - Keine Regel für ID's...

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's

Re: Fehlermeldung nach vielen Stunden - Keine Regel für ID's