OPNsense Forum
International Forums => German - Deutsch => Topic started by: kosta on June 29, 2021, 06:57:27 pm
-
Hallo,
ich habe heute versucht unseren 2. Router ins Netz zu hängen.
Lt. Skizze ist es so:
Produktivnetz 10.150.32.0/24, GW .254
192.168.31.254 als Gateway ("WAN") für VPN-Router. Dieser hat 192.168.31.129 wanseitig.
Lanseitig ist er wie auch OPNsense im 10.150.32.0/24 Netz, mit seiner IP 10.150.32.129.
Clients können ihm finden (ping).
So, aus meiner Sicht, eine statische Route am OPNsense müsste reichen, die besagt 10.157.10.0/24 via 10.150.32.129.
Dafür kann ich eben ein Gateway am ix0 erstellen, IP 10.150.32.129. Und die statische Route via dem Gateway routen.
Das Problem bei der Sache ist: OPNsense kennt "10.150.32.129" nicht, ping funkt nicht. Der Client schon und ping funkt.
Und da stehe ich bisschen auf der Leitung... die Sense müsste den Router doch via 10.150.32.129 finden können?
Getestet auf der Sophos, kann ich pingen.
So für die statischen Routen brauche ich den GW-Eintrag auf jeden Fall.
Das Problem scheint es zu sein, dass der VPN-Router via 10.150.32.129 nicht angesprochen werden kann.
Idee wo das Problem sein könnte?
-
So, heute der zweite Versuch. Tatsächlich lag es an der falschen Verkabelung - ich hatte einen Dreher in der Doku leider. Korrigiert und heute ging alles normal online - VPN-Router normal erreichbar, verbindet sich per VPN, und ich kann das ferne Netz erreichen.
Unsere Remote Server sind Citrix-basiert.
Man kommt auf die Citrix Anmeldeseite, man kann sich anmelden und Remote-Sitzung starten. Alles gut und flott.
Aber, die Sitzung ist extrem instabil.
Die Sitzung friert immer wieder (so etwa geht 20sek, friert 5 sekunden), insofern dass man nichts anklicken oder bewegen kann. Lokal ist alles gut (also friert nicht die Applikation, sondern wirklich die Sitzung).
Ich habe nen ping laufen lassen von der lokalen Maschine zum Remote Server - tadellos.
Genuaso wie auch Gateway Monitoring, keine Ausfälle.
Dann habe ich wieder unsere alte Sophos angehängt - stabil.
Die OPNsense ist erstmal ziemlich "offen" konfiguriert. Also eingehend sind alle LAN/VLAN Interfaces alles erlaubt und NAT ist default an WAN Address für jedes Interface, inkl. Interface für den VPN-Router.
Ich habe auch beachtet für Port 500 Static Port einzustellen (am Interface des VPN-Routers).
VPN-Router baut meines Wissens nach einen IPsec Tunnel auf.
Citrix Workspace ist bestimmt nicht die neueste Version, da wir aktuell eine bestimmte Version (hab jetzt den Rechner nicht vor mir) im Produktiveinsatz haben.
Habt ihr Idee woran das liegen könnte?
Wichtig ist mir dass ich sehe erstmal und recht zügig ob die wichtigsten Sachen gut und stabil funken, dann wird alles zugemacht und stufenweise erlaubt. Aktuell hängt wieder die Sophos dran, die OPNsense hänge ich aktuell nur zum konfigurieren an, dann wieder retour zur Sophos, da ich nächste Woche Urlaub habe, möchte ich keine fixe Umstellung vorher machen.
Ich habe für morgen ein Termin mit einer Support-Firma, aber schadet nicht hier auch zu fragen, was eure Ideen sind, falls welche?
-
Lösung:
"Bypass firewall rules for traffic on the same interface" anhaken.
-
Das Problem ist zurück. Der Haken hat damals scheinbar was bewirkt, aber aktuell bewirkt er nix.
Die Internet-Leitung sowie die VPN-Leitung des Cisco-Routers scheint stabil zu sein, kein einziger Ping-Aussetzer.
Jedoch Citrix geht so gut wie gar nicht. Geht vielleicht 2 Sekunden, und dann nix für 10 Sekunden usw.
Das einzige was ich gestern gemacht habe sind die IPSec Tunnels, das funktionierte noch gut, aber ich habe gestern die Citrix Anbindung nicht getestet.
Aktuell habe ich auf der OPNsense ausgehend aus allen LANs alles erlaubt. WAN eingehend nur die Firewall-IP, damit ich von außen auf das Management-Intf komme (vorübergehend bis sie in den Produktivbetrieb geht).
Schalte ich auf Sophos zurück, tadellos alles.
Verbinde ich mich mit Citrix direkt über Internet, also nicht durch den VPN-Router, ist auch stabil. NUR wenn man durch den Router geht, ist es instabil.
Bitte, hat jemand eine ähnliche Erfahrung oder habt ihr die kleinste Idee woran das liegen könnte?
-
Hast Du mal tcpdump auf den relevanten Interfaces angeworfen und geguckt, was mit den Paketen passiert?
-
Noch nicht, ist der nächste to-do. Dann guck ich mal im WS. Zuerst muss ich alle Mitarbeiter auf die externe Anbindung umstellen, damit ich allgemein auf die Sense umschalten kann und in Ruhe troubleshooten. Da ich kein OK bekomme abends oder am WE zu arbeiten, muss ich das von 8-17h machen, und Wege finden wie ich die Mitarbeiter am wenigsten belaste.
-
Also gut, ich habe 3 interfaces ausgewertet. ix0 (LAN), igb0 (WAN) und ibg3 (Port für Cisco WAN).
Ich sag gleich im Vorhinein, bin kein WS Profi.
Ich habe versucht die Zeiten annährend zu stoppen, und mit Timestamps verglichen.
Der Ausfall kam bei ca. 09:00Sek, wiederbelebt gegen 00:19, also Dauer von ca. 10 Sekunden.
Was mir auffällt ist dass die Probleme mit TCP Retransmission zwischen OPNsense und Cisco passieren, zwischen Client und OPNsense ist alles gut. Aber vielleicht ist das normal und WS zeigt es nur so, weil es muss ja erstmal von PC -> OPNsense -> Cisco gehen?
Soll ich die ganzen Captures posten mit einem Passwort, kann ich nach Wunsch gerne per PM zukommen lassen. Würde ungern die ganzen Captures im Netz offen stellen.
-
Und noch ist mir aufgefallen dass am LAN Interface, trotz Allow All Rule, Pakete geblockt werden wenn der Citrix Ausfall passiert. Und zwar nur an dem Host mit Destination Citrix Server, wo ich mit Citrix verbunden bin.
Ist es nicht vielleicht was umgekehrtes? Firewall blockt die ungültigen Pakete oder so?
Und ich bin soweit ziemlich sicher dass es nicht Citrix und OPNsense Kombi ist, denn die Anbindung ohne VPN-Router (alternative Auth-Methode) geht tadellos.
-
Hier ist der ganze Log auf ix0 während des Freezes.
Freeze beginnt bei ca. Paket 235 and fängt sich wieder bei Paket 643.
https://pastebin.com/ka4HFaNq
source-ip ist der Rechner, dest-ip is server-ip in der Citrix session.
Ideen?
-
Die TCP Retransmissions haben es erklärt: es kam zum asynchronen Routing. Das Problem gab es bei Sophos nicht, wir wissen nicht warum, aber bei OPNsense tritt es auf.
Es passierte weil die Pakete die Richtung RZ gingen über OPNsense geführt wurden, aber auf dem Retourweg direkt zum Client gingen, die OPNsense bekam davon nichts. Irgendwie aufgrund von States kannte sich OPNsense nicht mehr aus, und die Situation kam zustande.
Die Lösung ist auf dem Client die statischen Routen für die Netze im RZ einzurichten.
Ist aber bei uns nicht einsetzbar, es sollte auf den Clients keine statischen Routen kommen, denn die Mitarbeiter gehen manchmal über einen Weg und manchmal über den anderen, und wenn man die statische Route setzt, geht der eine Weg nicht mehr...
Also ich verzweifel langsam, speziell deswegen, weil auf der Sophos alles netzwerktechnisch funkte. Wechselgründe waren andere.
Hat jemand Idee ob es möglich ist die Sache mit OPNsense alleine zu lösen?
-
Idee: macht es Sinn auf der OPNsense ein neues physikalisches Interface zu erstellen, mit der IP aus dem gleichen Netz wie LAN, also zB. 10.150.32.253/32 und dort den VPN-Router dranstöpseln? Damit würden die Retour-Pakete ja auf der Sense landen, oder?
-
Du kannst keine zwei Interfaces im selben Subnet haben. Das verletzt alle Regeln, wie IP Routing funktioniert. Ja, man kann das irgendwie hin hacken, aber es macht keinen Spaß ;)
Ich guck mir Dein Setup nochmal an ... sorry, bin erst später in den Thread eingestiegen.
-
Das verletzt alle Regeln, wie IP Routing funktioniert
Zwei Gateways klar, aber warum nicht zwei Interfaces? Ist ja nur ein Port mit einer IP, die man sonst nirgendwo verwenden soll.
Danke, klar.
-
Ich würde an Deiner Stelle nicht auf der OPNsense messen sondern auf dem Switch das Port-Mirroring aktivieren und die Datenpakete eines Clients mittels Wireshark auswerten.
Das läßt sich binnen Sekunden feststellen über welchen Weg die Pakte gehen.
Handelt es sich um ein managebarer Switch?
-
Kann ich machen, aber ich denke erstmal die Ursache wurde gefunden, hier bedarf es aus meiner Sicht keine weiteren Messungen (die Zeit ist auch knapp, die Migration ist voll im Gange).
Fakt ist dass es am Routing liegt.
Ja, Switch ist L3, ist aber nicht aktiviert, da alles mit VLAN und via OPNsense gemacht wird. Sehe keinen Vorteil das Routing am Switch zu betreiben.
-
Es geht nicht darum das Routing zu ändern sondern festzustellen welchen Weg die Pakete hin- und zurück gehen.
-
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.
-
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...
-
Leider nein. Ich glaube das liegt an der Konfiguration des VPN Routers, und den kann ich, außer WAN und LAN IP, nicht konfigurieren.
-
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.
-
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.
-
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.
-
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?
-
> 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
-
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.
-
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
-
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 ;-)
-
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.
-
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.
-
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.
-
Macht eh keinen Sinn, muss JeGr wohl missverstanden haben.
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.
Ist schon gut, solche Empfehlungen bringen hier nix.
-
Klar - muss man nicht alles im Forum breittreten :)
Quintessenz ist aber, dass einen eigenen Router bei meinem Peer fordern schon ne Ecke mehr ist, als "nur ein Tunnel". Kann auch durch diverse PCIs etc. Vorgabe sein - ohne Frage. Aber dann muss man sich trotzdem immer auch an die Gegebenheiten beim Kunden anpassen, denn der hat ja auch intern seine Auflagen und Regeln. Nur weil ich da meine eigene Kiste reinhängen will, kann sich ja der Kunde selbst nicht verbiegen :)
> Aber: warum zweites WAN?? Das Gerät (Cisco) hat sicher genug Ports, aber was für Zweck?
Ich hatte nicht gesagt zweites WAN (in Aussage), sondern als Frage weil ich nicht weiß, WAS euer VPN Partner euch da für ne Kiste hinstellt. Es gibt auch einige, die dann ihr eigenes Internet mitliefern oder ne eigene WAN Leitung vor Ort fordern. Daher die Frage (ob er eigenes WAN hat! nicht DASS er eines hat :) ).
Wenn der Cisco VPN macht und das über ein Interface, das gleichzeitig eben für ihn quasi WAN/LAN ist, dann ist es umso einfacher und man muss weniger beachten, das war die Aussage, die ich machen wollte damit. Wenn der noch selbst eigenes WAN hat für sein VPN, dann muss man ggf. das Transfernetz zu diesem Cisco eben als wirkliches Upstream WAN konfigurieren (mit aktivierten Gateway Settings im Interface) statt nur als weiteres LAN/VLAN. Nur darum hatte ich gefragt. :)
-
Also ich hatte heute schon mal das Gespräch mit den Leuten aus dem RZ und wie ich schon vorgeahnt habe:
"Machen wir nicht, ist nicht vorgesehen".
Nun habe ich denen mehr Druck gemacht (im Sinne von "wir können nicht arbeiten wenn das so nicht umgesetzt wird"), Netzplan geschickt, und jetzt schauen sie sich das mal an.
Sie sagten mir auch, dass das die erste Anfrage ever ist, um so etwas zu machen, und das glaube ich denen sofort, denn es gibt bei denen KEINEN anderen Kunden (von knappen 3000 Kunden die dort hosten) der eine eigene IT wie wir hat.
Deswegen ist es eine Sonder-Sonderlösung, und das müssen sie erstmal gut prüfen lassen.
Ich sagte schon unser Unternehmen ist hier sehr sehr speziell.
Wenn der Cisco VPN macht und das über ein Interface, das gleichzeitig eben für ihn quasi WAN/LAN ist, dann ist es umso einfacher und man muss weniger beachten, das war die Aussage, die ich machen wollte damit. Wenn der noch selbst eigenes WAN hat für sein VPN, dann muss man ggf. das Transfernetz zu diesem Cisco eben als wirkliches Upstream WAN konfigurieren (mit aktivierten Gateway Settings im Interface) statt nur als weiteres LAN/VLAN. Nur darum hatte ich gefragt. :)
Cisco wird standardmäßig mit WAN und LAN Ports konfiguriert und ist standardmäßig der EINZIGE Router im Unternehmen. WAN ist normalerweise direkt ans Internet angeschlossen, auf LAN DHCP, klassisch halt, und das Transfernetz ist das LAN Netz.
Bei uns: zusätzlichee Firewall (OPNsense), die für Cisco Zugang zum WAN herstellt. LAN ist aktuell nach wie vor das default Transfernetz.
Was ich aktuell anstrebe, ist die Konfiguration eines weiteren LAN-Ports mit dem Transfernetz (neues Netz, unabhängig vom aktuellen Clientnetz), und wie schon gesagt, einer statischen Route am Cisco und OPNsense die jeweils über das Netz routet.
Vorallem finde ich es so seltsam dass sie sich so anstellen, denn das Transfernetz zwischen Cisco und OPNsense ist eigentlich NUR bei uns und hat mit den Netzen im RZ gar nix zu tun... von daher...
-
Na also, geht ja ;-)
Waren heute lange Gespräche aber wir sind auf eine Konstellation gekommen die für uns richtig ist und für das RZ akzeptabel. Und zwar:
Wir müssen unser lokales Netzwerk ändern (bereits passiert): 10.10.10.0/24
Neues Transfernetz: 10.146.35.1 (sense) und 10.146.35.2 (vpn-router)
Statische Routen über Transfernetz...
Auf dem VPN Router wird unser ursprüngliches Netz eingerichtet und dort ein 1:1 NAT aus 10.10.10.0 ins 10.146.32.0 gemacht.
Sonst statische NATs für Drucker, einzelne Server...
Eine simplere Lösung wie neues Transfernetz und wir behalten 10.146.32.0 ginge nicht.
Bin gespannt ob das so funkt wie geplant. Dabei aber auch ein Vorteil: wir können zusätzliche Netze oder IPs NATen (lassen), was bisher nicht ginge. So lange alles am 10.146.32.0/24 im VPN-Router endet, alles gut.
-
Thema ist abgeschlossen, die Umstellung ist gemacht und wie empfohlen, funktioniert tadellos.
Ich muss euch auch ein großes Dankeschön für etwas Druck aussprechen, denn nur damit hat es jetzt endlich sauber geklappt.
-
Freut mich zu lesen. Auch wenns eine schwere Geburt war, manchmal muss man sich da doch auf der Gegenseite durchboxen :)