Routing klappt nicht
-
Hallo,
folgendes Szenario. Ich habe zwei Standort (A 192.168.178.0 ) (B 192.168.1.0) per VPN verbunden und kann die Clients hinter der pfSense auch per ping erreichen.Jetzt habe ich folgendes Routing unter Windows auf Standort A eingerichtet um den Client, in diesem Fall ein Konnektor, zu routen.
100.102.0.0 255.255.0.0 192.168.1.190Ein tracert auf 100.102.7.140 muss über den Konnektor laufen, geht aber nur über das Gateway.
Muss ich noch ein Routing in der pfSense einrichten ? Eigentlich doch nicht da ich die IP 192.168.1.190 per Ping vom Standort A erreichen kann. Oder ?
VG
C:\Users\Anmeldung-01>route print =========================================================================== Schnittstellenliste 5...02 cf a0 cb 0a 71 ......Intel(R) PRO/1000 MT Network Connection 1...........................Software Loopback Interface 1 4...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter 3...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface =========================================================================== IPv4-Routentabelle =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.10 25 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 192.168.178.0 255.255.255.0 Auf Verbindung 192.168.178.10 281 192.168.178.10 255.255.255.255 Auf Verbindung 192.168.178.10 281 192.168.178.255 255.255.255.255 Auf Verbindung 192.168.178.10 281 224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331 224.0.0.0 240.0.0.0 Auf Verbindung 192.168.178.10 281 255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 255.255.255.255 255.255.255.255 Auf Verbindung 192.168.178.10 281 =========================================================================== Ständige Routen: Netzwerkadresse Netzmaske Gatewayadresse Metrik 212.3.66.8 255.255.255.248 192.168.1.190 1 100.102.0.0 255.255.0.0 192.168.1.190 1 =========================================================================== IPv6-Routentabelle =========================================================================== Aktive Routen: If Metrik Netzwerkziel Gateway 3 331 ::/0 Auf Verbindung 1 331 ::1/128 Auf Verbindung 3 331 2001::/32 Auf Verbindung 3 331 2001:0:2851:782c:2493:f565:3dd2:dbb6/128 Auf Verbindung 3 331 fe80::/64 Auf Verbindung 3 331 fe80::2493:f565:3dd2:dbb6/128 Auf Verbindung 1 331 ff00::/8 Auf Verbindung 3 331 ff00::/8 Auf Verbindung =========================================================================== Ständige Routen: Keine C:\Users\Anmeldung-01>tracert 100.102.7.140 Routenverfolgung zu 100.102.7.140 über maximal 30 Hops 1 <1 ms <1 ms <1 ms pfinesRZ.localdomain [192.168.178.1] 2 18 ms 22 ms 28 ms 194.45.36.1 3 * * * Zeitüberschreitung der Anforderung. 4 fra1.cr1.ip-projects.de [194.45.196.20] meldet: Zielnetz nicht erreichbar. Ablaufverfolgung beendet. -
Hallo,
@achim55 said in Routing klappt nicht:
Jetzt habe ich folgendes Routing unter Windows auf Standort A eingerichtet um den Client, in diesem Fall ein Konnektor, zu routen.
100.102.0.0 255.255.0.0 192.168.1.190ist nur allzu dumm, dass Windows diese Route überhaupt akzeptiert. So etwas kann nicht funktionieren.
Als Routenziel sind nur IP-Adressen in an einer Schnittstelle des Rechners definierten Netzwerken möglich.Du kannst auf dem PC also bestenfalls eine Route auf die nächste pfSense setzen. Das macht aber keinen Sinn, wenn pfSense ohnehin das Standardgateway ist.
Die Route auf 192.168.1.190 muss jedenfall auf der pfSense A gesetzt werden. Wenn es nur für den einen Rechner sein soll, kannst du Policy Routing einsetzen.
Auf der B-Seite braucht es dann auch eine ausgehende NAT-Regel für die Pakete der A-Seite.
-
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?
-
@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.
