Routing klappt nicht
-
@achim55 said in Routing klappt nicht:
Hi, ich verstehe das nicht so ganz. Unter VPN habe ich doch das entfernte Netzwerk stehen.
Also sollte doch alles was an 192.168.1.190 geht über VPN raus gehen, oder?Ja, ich gehe davon aus, dass das auch zutrifft.
Aber woher soll die pfSense wissen, dass sie Pakete, die für 100.102.0.0/16 bestimmt sind, über die VPN nach B schicken soll anstatt aufs Standardgateway, wenn du ihr das nicht mitteilst?
Noch einmal, die Route auf Windows mit einer Remote-IP aus dem B-Netz ist nutzlos, nachdem das System den Host nicht direkt, sondern nur über Router, erreichen kann.
Für die pfSense gilt wieder das gleiche: Die Pakete können nur auf den nächsten Router geroutet werden, nicht auf eine IP dahinter (bei NAT Weiterleitungen ist das anders). Für die pfSense A ist das die VPN IP von B.
Auf der pfSense A kannst du dafür 100.102.0.0/16 zu den "IPv4 Remote Networks" hinzufügen. Auf der pfSense B braucht es eine statische Route für dieses Netz, die dann auf 192.168.1.190 zeigt, ansonsten schickt diese die Pakete auf ihr Standardgateway, also vermutlich ins Internet.Was soll mit den Paketen auf 192.168.1.190 passieren? Werden die von da weiter ins Internet geleitet, oder ist der Host selbst für diese IPs zuständig?
-
@achim55 Wie es @viragomann schon sagt. Wenn 10.102.0.0/16 auf der anderen Seite des VPNs ist, dann muss der Netzbereich zusätzlich mit bei entfernte IPv4 Netzwerke mit auf den Tunnel draufkonfiguriert werden, damit die pfSense weiß dass der Kram per VPN rüber soll. Nur weil du irgendwas auf der A Seite auf Windows konfigurierst, kommt das deshalb nicht automagisch auf Seite B an. Du sendest schließlich deine Pakete NICHT an 192.168.1.190, sondern die sind an irgendwas mit 10.102.x.y addressiert und NUR das interessiert den Routing Stack der Firewall. Mit dem kann sie nichts anfangen, also raus ans default GW damit, Ende Gelände.
Wenn das übers VPN soll, muss es in die VPN Konfiguration vom OVPN Tunnel mit rein. Und die Sense auf B Seite muss dann damit umgehen können, bzw. muss dann ne statische Route o.ä. haben, in der sie weiß, dass 10.102.0.0/16 an 192.168.1.190 geht - den DIE Kiste kennt dann tatsächlich die IP weil sie dort lokal vorhanden ist. Seite A weiß aber davon überhaupt nichts, da ist also die völlig falsche Baustelle um eine Route dahinzusetzen da das Ziel nicht lokal und damit unbekannt ist.
Zudem völlig richtig bemerkt vom Kollegen, dass Windows da Murks macht und die Route überhaupt annimmt. Non-local Routen sind böses gehacke und machen nur unnötig Probleme. Dürften gar nicht akzeptiert werden, sondern müssten mit Kommentar dass sie nicht lokal bekannt sind abgelehnt werden. Sowas darf nur erlaubt werden, wenn übersteuert mit Parameter und ein HW Interface angegeben wird. Alles andere ist BlackMagicMurks ;)
Cheers
-
Danke für die Erklärung von Euch. Werde die Tage noch mal an das routen gehen, was nicht so meine Stärke ist, wie ihr bemerkt habt.
VG
-
@achim55 said in Routing klappt nicht:
Danke für die Erklärung von Euch. Werde die Tage noch mal an das routen gehen, was nicht so meine Stärke ist, wie ihr bemerkt habt.
VG
Wir lernen doch alle stetig dazu :)
-
@jegr said in Routing klappt nicht:
10.102.0.0/16
Mache heute mal weiter :-)
Also muss ich die 10.102.0.0/16 unter Entfernte IPv4 Netzwerke mit eintragen, quasi so:192.168.1.0/24, 10.102.0.0/16
und am Standort B ein statische Route auf die auf die 192.168.1.190 legen. Werde es mal testen ;-)
-
@viragomann said in Routing klappt nicht:
192.168.1.190
Hi, ich versuche mal eine kurze Erklärung was mit den Paketen auf der 192.168.1.190 passiert. ;-)Standort A ist ein RZ wo ein Windows-Terminal-Server steht. Standort B eine Praxis.
Die Standorte sind über VPN verbunden.Die Clients greifen auf den Server per RDP auf die Praxissoftware zu.
Durch die Einführung der Telematik kam die KoCoBox ins Spiel, die am Standort B verbaut ist.
Jetzt kommt KIM - gematik dazu.
Das heißt Rezepte, Krankschreibungen etc. laufen über die KoCoBox und dieses KIM Modul wird mit in die Praxissoftware eingespielt.
Dieses Modul mit der 10.102.0.0/16 versucht die o.g. Dokumente verschlüsselt per KIM über die Box zu senden, die unter der IP 192.168.1.190 läuft.
-
@achim55 said in Routing klappt nicht:
Also muss ich die 10.102.0.0/16 unter Entfernte IPv4 Netzwerke mit eintragen
Du hast zu Anfang
100.102.0.0 255.255.0.0
geschrieben. Das wäre aber ein öffentliches Netz, daher habe ich nach dem Sinn gefragt, dieses auf die Remoteseite zu routen.
-
Die Gematik bietet ihre Dienste auf public IPs an, die aber nur über den VPN Tunnel der KoCoBox erreicht werden können.
So kann jeder public DNS den Dienst an die richtige IP verweisen, aber nur berechtige Personen oder Systeme diese über den Tunnel zur Gematik erreichen.
Daher muss man dann ggf. ne Proxy Ausnahme setzen und das Routing anpassen. -
Jetzt bin ich total verwirrt ;-)
Wie gesagt routing ist nicht meine Welt. Die Gematik wird von einer Fremdfirma eingerichtet.
Auf der Remouteseite, Standort B, steht die KoCoBox mit der IP 192.168.1.190.Ein tracert vom Terminalserver aus muss über die KoCoBox raus gehen. Hat wohl etwas mit der Verschlüsselung zu tun, vermute ich.
Wie muss ich das denn nun machen das ein tracert von der 100.102.0.0 über die KoCoBox läuft und nicht über das Standardgateway ?
Irgendwie muss das durch den VPN Tunnel.Besten Dank
-
Du muss halt an Standort A die IP: 100.102.7.140/32 in die Phase 2 des Tunnels mit aufnehmen.
Damit weiß dann die pfSense auf Seite A das diese zur Seite B geroutet werden muss.Auf Seite B dann die CoCoBox als Gateway mit der IP: 192.168.1.190 anlegen.
Dann eine statische Route anlegen: 100.102.7.140 255.255.255.255 192.168.1.190, fertig.
-
Du meinst ein multi WAN auf der Seite B anlegen ? Die pfSense auf der Seite B ist je das Gateway und als "Modem" dient eine Fritzbox.
-
Das hat nix mit multi WAN zu tun, denn es wird ja nur diese eine IP oder das eine Netz über dieses GW geroutet.
-
-
Achja, in der CoCoBox muss dann noch für das von dir verwendete RFC1918 Netz die Route zur pfSense auf der Seite der CoCoBox rein.
Hoffe du kannst einfach 192.168.0.0/16 auf GW setzen.
