Probleme mit VPN-Tunneln

[ThomasE]

Hallo allerseits,

nachdem wir jetzt für die kleineren Auffälligkeiten zumindest einen Erklärungsansatz haben, würde ich jetzt gerne auf ein Thema kommen, was uns noch richtig großes Kopfzerbrechen bereitet.

Wir haben eine ziemlich komplexe Netzwerkinfrastruktur mit diversen Cisco Routern und zwei ASAs, die wir perspektivisch vollständig auf OPNsense migrieren wollen. Im ersten Schritt übernimmt OPNsense lediglich die Funktion des Access-Routers, und obwohl das noch vergleichsweise einfach ist, erleben wir hier bereits ein Phänomen, auf das wir uns keinen Reim machen können:

Hinter der OPNsense befindet sich ein weiterer Cisco-Router, der ca. 80 VPN-Tunnel (Cisco EZVPN) terminiert. Die Tunnel werden von entsprechenden Gegenstellen aufgebaut und sind permanent vorhanden. An einzelnen Standorten erfolgt alle 24h mal eine Zwangstrennung. Dieser Aufbau läuft seit vielen Jahren ausgesprochen stabil. Sofern wir die Firewall-Funktionalität der OPNsense komplett deaktivieren, läuft das System auch weiterhin störungsfrei. Sobald wir die Firewall aber aktivieren, brechen uns gelegentlich einzelne Tunnel weg. Es gibt keine erkennbare Systematik, welche Tunnel wegbrechen noch, wann sie es tun. Es ist immer mal ein mutmaßlich zufälliger Tunnel alle paar Minuten. Schaltet man die Firewall komplett ab, werden alle Tunnel wieder aufgebaut, schaltet man sie wieder an, beginnt das Spiel von vorn.

Hat irgendjemand eine Erklärung für dieses Phänomen oder zumindest eine Idee, wie man es weiter untersuchen könnte?

LG
Thomas

[Rolly82]

Benutzt "Cisco EZVPN" irgendwelche Proprietären Protokolle?
Kenn das von Lancom, diese können im MainMode (Klassisches IKE) "Dynamisches VPN" dabei übermittelt der Aufbauende Router (je nach Einstellung) seine WAN-IP per ISDN, ICMP- oder UDP-Paket.
Evtl. macht Cisco hier ja etwas ähnliches.

Oder aber der DPD-Timer ist größer wie der Aging-Timer der Firewall

[ThomasE]

Benutzt "Cisco EZVPN" irgendwelche Proprietären Protokolle?
Kenn das von Lancom, diese können im MainMode (Klassisches IKE) "Dynamisches VPN" dabei übermittelt der Aufbauende Router (je nach Einstellung) seine WAN-IP per ISDN, ICMP- oder UDP-Paket.
Evtl. macht Cisco hier ja etwas ähnliches.

Ich muss gestehen, dass ich bei Cisco jetzt nicht so wahnsinnig tief drin stecke, weil ich das System nur übernommen habe.

Oder aber der DPD-Timer ist größer wie der Aging-Timer der Firewall

Die DPD-Einstellung auf dem Cisco, der den Tunnel aufbaut, ist

Code: [Select]

crypto isakmp keepalive 60 20 periodic

Klar könnte ich das jetzt testweise mal runterdrehen, aber trotzdem erklärt das doch nicht, warum der Tunnel, nachdem er einmal weggeflogen ist, nicht ganz normal wieder aufgebaut wird. Der Router bleibt im "AG_INIT_EXCH" einfach hängen - bis ich die Firewall wieder kurzzeitig ausschalte...

[Patrick M. Hausen]

Mal mit der "Close Action" Einstellung gespielt? Die hatte ich für ein ähnliches Problem in einem Gateway-Gateway Setup extra eingebaut. Setz die doch mal auf "Restart".

[Ketanest]

Was mir spontan einfällt: Static Port bei NAT (Falls vorhanden)?

Gruß
Ketanest

[ThomasE]

Mal mit der "Close Action" Einstellung gespielt? Die hatte ich für ein ähnliches Problem in einem Gateway-Gateway Setup extra eingebaut. Setz die doch mal auf "Restart".

Die wäre wo zu finden?

Je mehr wir die Situation analysieren, desto verwirrender wird alles...

Zunächst mal der Versuchsaufbau:

Wir haben einen VPN-Initiator I, der von einer dynamischen, öffentlichen IP kommt, wir haben einen VPN-Terminator T, der an einer statischen öffentlichen IP lauscht und dazwischen ist die OPNsense mit einem externen Interface in Richtung Internet und einem internen Interface in Richtung VPN-Terminator:

Code: [Select]

I --- (Internet) --- OPNsense --- T
Wir haben uns jetzt einen Initiator herausgegriffen, der gerade Probleme machte und haben sowohl auf dem internen als auch auf dem externen Interface der OPNsense gesnifft, wobei wir die öffentliche IP (IPv4) des Initiators als Filter (Quelle und Ziel) verwendet haben. Dabei war deutlich erkennbar, wie der Initiator alle 10 Sekunden ein ISAKMP-Paket zum Terminator schickt. Die Pakete sind jeweils identisch, sie gehen auf dem externen Interface der OPNsense rein und auf dem internen Interface unverändert wieder raus. Wir haben also ein

Code: [Select]

I -> OPNsense -> T
I -> OPNsense -> T
I -> OPNsense -> T
I -> OPNsense -> T
...

So weit, so normal. Spannend wird es in dem Moment, wo wir die Firewall deaktivieren. Dann antwortet der Terminator nämlich plötzlich, die zwei Geräte unterhalten sich munter über die OPNsense und bauen schließlich den Tunnel auf:

Code: [Select]

I -> OPNsense -> T
T -> OPNsense -> I
I -> OPNsense -> T
T -> OPNsense -> I
...

Das heißt konkret, dass das Gerät, was die VPN-Tunnel terminiert, auf mysteriöse Weise zu erkennen scheint, ob die Firewall auf der OPNsense-Maschine läuft und wenn dies der Fall ist, selten und zufällig entscheidet: "Nö, mit Dir rede ich jetzt einfach mal nicht."

Kann sich irgendjemand einen Reim auf dieses Verhalten machen?

VLG
Thomas

[Patrick M. Hausen]

Mal mit der "Close Action" Einstellung gespielt? Die hatte ich für ein ähnliches Problem in einem Gateway-Gateway Setup extra eingebaut. Setz die doch mal auf "Restart".

Die wäre wo zu finden?

In den Phase 1 Einstellungen für IPsec. Heißt "Close Action". Betrifft eigentlich Phase 2, aber da die zwangsläufig für alle Phase 2 SAs identisch ist, hab ich sie in den Dialog für Phase 1 eingebaut.

[ThomasE]

Irgendwie wird die Sache hier immer verrückter. Bei dem Versuch, mögliche Auslöser zu identifizieren, haben wir jetzt abermals ein Verhalten, für das wir keinerlei Erklärung haben.

Zunächst einmal haben wir eine fließende Regel erstellt, die pauschal alles erlaubt - sowohl IPv4 als auch IPv6. Das ist natürlich keine Dauerlösung, aber irgendwo müssen wir ja anfangen. Sobald diese Regel aktiv ist, sind die Tunnel stabil.

Danach habe ich die Regel deaktiviert und stattdessen zwei einzelne Regeln erstellt - eine für IPv4 und eine für IPv6. Nach meinem Verständnis dürfte das eigentlich keinen Unterschied machen, aber es tut es doch, denn jetzt fliegen uns gelegentlich wieder Tunnel weg.

Jetzt mal unabhängig von der Frage, ob uns das bei unserem Problem weiter hilft: Was genau ist der Unterschied zwischen einer Regel für IPv4 und IPv6 und je einer Regel für IPv4 und einer für IPv6?

[Patrick M. Hausen]

Das kommt darauf an, ob du Aliase für Netze und/oder Ports/Protokolle benutzt. ICMP Echo ist z.B. nicht gleich ICMPv6 Echo. Daher funktioniert m.W. eine kombinierte Regel für "ping" z.B. nicht.

[ThomasE]

Das kommt darauf an, ob du Aliase für Netze und/oder Ports/Protokolle benutzt. ICMP Echo ist z.B. nicht gleich ICMPv6 Echo. Daher funktioniert m.W. eine kombinierte Regel für "ping" z.B. nicht.

Keine Aliase, keine speziellen Ports - nichts dergleichen. Wo immer man etwas eintragen kann, steht "any" drin - außer bei "TCP/IP Version", wo einmal "IPv4" respektive "IPv6" und einmal "IPv4+IPv6" drin steht.

[Patrick M. Hausen]

Dann ist das m.W. äquivalent. Du kannst mit ˋpfctl -s rulesˋ gucken, was das UI produziert.

[ThomasE]

Japp, die Regeln sind erwartungsgemäß identisch - geändert haben sich lediglich die Labels:

Code: [Select]

diff rules_separate.txt rules_combined.txt
10c10
< block drop in inet from <__automatic_4d3d3f57_0> to any
---
> block drop in inet from <__automatic_fa85a120_0> to any
78,79c78,79
< pass log quick inet all flags S/SA keep state label "c4beb8516b06f135878263748159eae9"
< pass log quick inet6 all flags S/SA keep state label "b49860d1c8e0221bf9580fde5a390b7d"
---
> pass log quick inet all flags S/SA keep state label "a8ca2a7f333146379aa92d950d6d7f9f"
> pass log quick inet6 all flags S/SA keep state label "a8ca2a7f333146379aa92d950d6d7f9f"
Und trotzdem führt die eine Variante reproduzierbar zu o.g. Fehler, die andere nicht.