[gelöst] Probleme mit dem VPN-Router

[FWStarter]

Es geht nicht darum das Routing zu ändern sondern festzustellen welchen Weg die Pakete hin- und zurück gehen.

[FWStarter]

Wieso eigentlich Route 10.157.10.0/24 über 10.150.32.129?
Müßte eigentlich Route 10.157.10.0/24 über 192.168.31.129 sein.

[kosta]

Es geht nicht darum das Routing zu ändern sondern festzustellen welchen Weg die Pakete hin- und zurück gehen.

Um genau zu sein, korrekt, damit könnte man das 100% sagen, aber der unwissenschaftlicher Test mit ständigen Routen hat's auch getan.

Wieso eigentlich Route 10.157.10.0/24 über 10.150.32.129?
Müßte eigentlich Route 10.157.10.0/24 über 192.168.31.129 sein.

Gute Frage. Weil man eigentlich immer schon lan-seitig geroutet haben.
Aber die Sense kennt ja auch die WAN Seite...

Lass mich probieren...

[kosta]

Leider nein. Ich glaube das liegt an der Konfiguration des VPN Routers, und den kann ich, außer WAN und LAN IP, nicht konfigurieren.

[FWStarter]

Sorry, hab Mist geschrieben, die 192.168.31.129 ist die WAN Schnittstelle für das VPN. Klar, kann nicht funktionieren.

Besteht Zugriff auf den VPN Router?

Ansonsten tatsächlich auf dem Switch mittels Port-Mirroring den Uplink zum VPN Server messen. Es könnte auch auf Probleme mit der MTU bzw. MSS vorliegen. Das ist aber ohne Messung ein Griff in die Glaskugel.

[kosta]

Dachte mir eh
Nein, kein Zugriff auf den VPN Router.
Ich kann eine WAN/LAN IP Änderung anfordern, aber dafür muss die Verbindung bestehen.
Wenn sie nicht vorhanden ist, muss der Router versendet werden damit er umkonfiguriert werden kann.

MTU/MSS hat man zwar probiert, aber wie gesagt, liegt am Routing, denn es funktioniert wenn man richtig routet (Hinweg und Rückweg ohne OPNsense). Oder halt Hinweg UND Rückweg durch die OPNsense.

Und eben muss probieren ob ich das zweite machen kann. Und wenn die Probleme dann nach wie vor auftreten, dann werde ich noch über MTU nachdenken.

[FWStarter]

Aber anstatt noch mehr Zeit und Energie in diese verbastelte Umgebung zu investieren, würde ich vorschlagen das Netzwerk richtig und konform aufbauen. Aktuell Firewall, VPN Gateway und Clients in einem Adressbereich ist was Sicherheit angeht sehr bedenklich.
Klemm die LAN Schnittstelle des VPN an ein DMZ Interface der OPNsense und die Sache ist was das Routing und die Sicherheit angeht geritzt.

[kosta]

Verstehe grad nicht was dein Problem ist.
VPN Router ist eine Anforderung und hier lässt der Betreiber keine Anpassungen zu (mit Ausnahme von der WAN IP). Aus. Bringt nix darüber zu diskutieren. LAN-Netz ist fix.
Und das betrifft auch das Thema Netz, ich muss den Router LAN-seitig in das Client-Netz hängen, anders geht es nicht wirklich. TECHNISCH genau gesehen würde es gehen würde ich die Clients in ein anderes Netzwerk verschieben, dazwischen 1:1 NAT schalten würde, bringt eine absolut unnötige Komplexität in das ganze und keine wirklich höhere Sicherheit. Eventuell auch mit NAT, dann müsste ich wiederum die einzelnen IPs die aus RZ angesprochen werden müssen alle händisch routen, hin und retour. Es ist vorgesehen, vom RZ aus (der uns den VPN Router bereitstellt), dass der Router im gleichen Netz wie die Clients ist.
Und das ist deswegen, weil der Zugriff auf den Router erfolgt ausschließlich aus dem gleichen Netz - die LAN IP kann nicht geändert werden, die WAN IP kann angepasst werden.

Was würde ich an Sicherheit, aus deiner Sicht gewinnen, wenn ich den Router auf ein getrenntes Interface klemmen würde?

[JeGr]

> Was würde ich an Sicherheit, aus deiner Sicht gewinnen, wenn ich den Router auf ein getrenntes Interface klemmen würde?
 
Simpel. Das ist ein fremdes Gerät, dass ich nicht selbst kontrolliere, das ein fremdes Netz angebunden hat, aber in MEIN LAN reinwill. Das hänge ich dann eben nicht direkt in mein LAN, sondern mache damit eine Art DMZ, ein Transfernetz zwischen dem Fremdgerät und meiner Firewall/Router. Dann kann es auch nie zu sowas wie asymmetrischem Routing kommen und genau solche Phänomene wie lange Wartezeiten, Lags, Latenzen und Co sind das Resultat was dann passiert.

Und in den allermeisten Fällen (>95%) war das bislang noch nie ein Problem, wenn ein Hersteller, Anbieter oder sonstwer seine eigene Hardware positionieren will im Haus, die dann via Transfernetz anzubinden, damit man ordentliches Routing hat. "Anders geht es nicht" ist da kein Argument. Sofern man das mit der Gegenseite ordentlich ausdiskutiert und durchspricht, war das noch nie ein Problem.

Alles andere sind in solchen Fällen nur Workarounds die mal gehen, mal nicht, einem aber auch gut auf den Fuß fallen können. Daher stimme ich da FWStarter zu, ich würde da lieber mit der Gegenseite aushandeln "Hey konfiguriert bitte euer LAN von eurem Router um, wir haben da sonst böse Probleme im Netz weil die Clients nicht sauber arbeiten können" und das wars. Alle anderen Zugriffe sowohl von als auch zu Remote bleiben ja exakt gleich. Die Clients greifen immer noch von den gleichen IPs auf die gleichen IPs auf der anderen Seite zu, NUR das LAN IF des FremdRouters muss geändert werden und wenn der kein extra WAN hat, dann wars das. Wenn er noch extra WAN hat, dann braucht es noch eine Route (zum Client LAN) mehr, aber das wars dann. Mit dem macht man nen Transfernetz, konfiguriert die Routen sauber und dann läuft auch brav jedes Paket über die Firewall zum VPN Router über deren VPN zu deren Netz und wieder GENAU diesen Weg zurück und nicht dann falsch direkt zum Client.

Ich hatte erst vor ein paar Wochen bei einem Kunden und deren externen Dienstleister die gleiche unnötig sinnlose Diskussion, bei der man zigfach stumpf alle möglichen anderen Sachen ausprobiert hat, immer mit der Aussage "nein das liegt nicht am Routing das machen wir immer so..." - irgendwann hat dann Gott sei Dank der Chef beim Kunden selbst auf den Tisch gehauen und gesagt es wird jetzt so gemacht wie vorgeschlagen. Kurz drauf gabs keine komischen Lags, Delays, stinklangsamen VPN Verbindungen oder sonstigen mysteriösen Probleme mehr, die man vorher hatte und niemand wusste wo sie herkommen.

Cheers

[kosta]

Also ich kann nachfragen ob sie bereit sind am LAN Interface die Adresse zu ändern, aber das erlaubte Netz ja belassen. Dann kann ich natürlich ein Transfernetz machen. Das letzte mal als wir darüber gesprochen haben hies es nein… aber jetzt kenne ich paar Leute mehr. Glaubt mir, das hier ist kein typischer Dienstleister und was wir fordern ist in dem Bereich wo wir sind, sehr untypisch.
Wir können uns gerne über details per PM austauschen, aber die Infos möchte ich nicht zwingend im Forum posten, Firma usw.

Aber: warum zweites WAN?? Das Gerät (Cisco) hat sicher genug Ports, aber was für Zweck?
Aktuell hat Cisco ein WAN und LAN Port.
LAN am Cisco ändern, auf OPNsense stöpseln, damit Transfernetz abbilden.
Statische Routen:#
Cisco: unser LAN via Transfernetz.
OPNsense: Netze im RZ via Transfernetz.

[Patrick M. Hausen]

Also generell muss das so wie von Kosta geplant schon funktionieren. Ich habe das selbst mit einer Sidewinder Firewall und einem separaten VPN-Gateway so im Einsatz.

Die Sidewinder (OPNsense) hat eine statische Route in Richtung der VPN-Ziele hinter dem Gateway. Beide haben dafür "ein Bein" im LAN. Alle Clients im LAN haben die Sidewinder als Default-Gateway.

Was passiert, wenn ein Client eine Verbindung zu einem Ziel im VPN-Tunnel initiiert ist normalerweise folgendes:

1. Der Client schickt sein SYN an die Sidewinder/OPNsense.
2. Die schickt das weiter an den VPN-Gateway, von dort wird es weitergeroutet zum Ziel.
3. Die Antwort-Pakete kommen natürlich direkt vom VPN-Gateway zum Client. Weshalb sollte der das über die Firewall schicken? Ist ja ein LAN!
4. Das ist wichtig: normalerweise sollte die Firewall dem Client ein "ICMP redirect" für die Zieladresse zustellen. Das bedeutet, sie sagt "ich kümmere mich ja gerne um Deinen Traffic, aber wenn Du gleich den Typen da nebenan damit bewirfst, geht es schneller".
5. Der Client schickt üblicherweise alle weiteren Pakete direkt an den VPN-Gateway.

Wenn das nun nicht so funktioniert wie es soll, kann ich mir dafür folgende Gründe vorstellen:

- Die Firewall verschickt keine ICMP redirects oder der Client ignoriert sie.
- Die Firewall trackt aus irgendwelchen Gründen die TCP-Connections, die nur zur Hälfte über sie laufen und blockt dann, weil der State nicht passt.

Speziell letzterer Fehler kann eigentlich nur auftreten, wenn man keine "permit all" Regel auf dem LAN hat. Die ist in so einem Setup aber genau aus diesem Grund zwingend erforderlich. Der Haken im UI "Static route filtering - Bypass firewall rules for traffic on the same interface" sollte eigentlich genau das tun.

Wenn er das nicht tut, dann haben wir hier wohl einen Bug. Probier es zumindest zum Debugging mal mit "permit all" und dann können wir weitersehen.

Gruß
Patrick

[kosta]

Probier es zumindest zum Debugging mal mit "permit all" und dann können wir weitersehen.

Damit schon versucht.
Das erste was ich getan habe um zu troubleshooten war im Prinzip alles zu deaktivieren was nicht notwendig ist, und alles zu öffnen - auf jeden Netz existieren zwei Rules für Troubleshooting, einmal TCP/UDP allow all, einmal ICMP allow all. Rest nach Bedarf, da es fast nie auftritt.
Alle Rules deaktiviert, diese zwei überall aktiviert.
Mit und ohne Haken versucht, und das Problem bestand.

Was mich aber ärgert ist dass es eine Weile funktioniert hat (siehe History), als mir empfohlen wurde den Haken zu setzen, waren die Probleme weg. Aber dann fingen sie wieder an und ich habe keine Ahnung was wirklich passieren konnte, damit es nicht mehr geht. Am Vortag habe ich eigentlich nur mit IPsec Tunnels probiert, was ich zwischen 2 Standorten habe (die normal funktionieren).

Jetzt habe ich mittlerweile einiges drauf, viel schon konfiguriert, möchte das jetzt nicht mehr auseinanderreißen ;-)

[FWStarter]

Die OPNsense macht genau das was se soll. Es ist eine stateful inspection Firewall und diese muss den Traffic in beide Richtungen kontrollieren! Ansonsten werden die Pakete verworfen. Das ist aber nur für TCP/IP aufgrund des Handshakes gültig.

Bau das Netzwerk einfach richtig auf ohne Krücken, wie es auch JeGr schrieb.


Wenn du diese Krücke weiterbetreiben möchtest muss der Haken bei "Bypass Firewall Rules for traffic on the same interface" gesetzt sein oder du baust dir das selbst mit 2 Firewall Regeln.
Dazu brauchst du eine normale für das IN Interface und eine Floating Regel.
-> wurde bereits negativ getestet.

[kosta]

Ihr besteht drauf dass ICH das will.
1) bisher wusste ich das nicht besser, Sophos hat perfekt funktioniert, jetzt weiß ich, und bin DAFÜR dass man es ändert.
2) ihr kennt nicht "unser" RZ, ihr kennt nicht die Firma und die Regeln die in Namen von Sicherheit die dort betrieben werden (sehr berechtigt).

Genug zu sagen dass wir diese Firewall in eine Konstellation implementieren die vom RZ eigentlich gar nicht vorgesehen wird.

Wenn es dort nein heißt, dann ist es so, und da fährt die Eisenbahn drüber. ICH kann dann nur die Wege rundherum suchen.

Morgen schauen wir mal ob ich die richtige Kollegen erreiche, dann versuchen wir mal das Thema Transfernetz.

Mir wurde noch immer nicht beantwortet:
Warum zweiter WAN? Wenn ich es richtig verstehe, eher wäre sinnvoll zweite LAN-Schnittstelle, mit ein anderen IP die ich für das Transfernetz verwende und ein statisches Routing "unser LAN via neues Interface". WAN bleibt WAN, eine Schnittstelle die auf der OPNsense hängt und dem VPN-Router die Anbindung ins Internet gibt.

[FWStarter]

Warum ein zweites WAN? Steht nirgends und macht doch gar keinen Sinn. Der LAN Port des VPN Routers gehört an ein Interface der OPNSense Firewall.

Ganz ehrlich, was Eure Firma macht oder nicht ist mir ziemlich wurscht. Wenn einer in Eurem RZ Ahnung vom Netzwerkdesign hätte, dann hättet ihr schon längst ein Gespräch gehabt.
Ihr scheint sehr viele Netzwerkbaustellen in der Firma zu haben aber nicht die richtigen Leute die das notwendige Wissen haben um die Anforderungen Professionell umzusetzen.
Wenn alle Stricke reißen holt Euch Rat von einem Systemhaus oder noch besser, lasst es aus einer Hand umsetzen.

Sorry, das klinkt sauhart aber manchmal ist es besser sich Hilfe zu holen als sich komplett zu verzetteln.