Routing Probleme, pfsense und WAN aus LAN nicht erreichbar
-
@tmevent said in Routing Probleme, pfsense und WAN aus LAN nicht erreichbar:
Auf dem LAN Interface ist es nicht aktiviert !
Ich würde mir nicht erwarten, dass ohne "IP Forwading" am Interface irgendein Paket über die pfSense von einer VPN Remoteseite oder aus dem Internet auf einer VM ankommt.
In dem Netz habe ich noch NSGs definiert die Eingehenden Datenverkehr regeln.
Ausgehender Verkehr muss da ebenso erlaubt werden.
-
WAN
|
Azure 192.168.0.1
|
Pfsense 192.168.0.4
|
PfSense 10.3.0.5
|
Azure-LAN (von mir meist als LAN bezeichnet oben)
|
Azure VM 10.3.0.4Die Tunnel habe ich außen vor gelassen
die Azure VM ist erreichbar aus den Tunneln und von der Pfsense.
Ich erreiche von der Azure VM aus aber nichts
-
@viragomann
Da bin ich nun einen Schritt weiter.Ich habe nun an allen Interfaces Port Forwarding aktiviert.
(Korrektur zu vorher, an 10.3.0.5 war es aktiviert, das hatte ich falsch im Kopf)
Nun erreiche ich die Pfsense von der Azure-VM aus, aber noch nicht das InternetDa ich von der PfSense aus ins Internet pingen kann, glaube ich nicht das es an der NSG Konfiguration von 192.168.0.0/24 liegt
-
@tmevent said in Routing Probleme, pfsense und WAN aus LAN nicht erreichbar:
Da ich von der PfSense aus ins Internet pingen kann,
Das ist aber auch neu?
glaube ich nicht das es an der NSG Konfiguration von 192.168.0.0/24 liegt
Nein, nicht wenn das Outbound NAT richtig arbeitet.
Was sind da für automatische Regeln konfiguriert?
-
@viragomann
Die Pfsense kam die ganze Zeit ins Internet.Ich erreiche von der GUI der Pfsense sowohl meine Azure Server, als auch das Internet.
-
@tmevent
Eine Regel für das LAN ist ja da. Aber warum gleich drei mal?
Und warum die anderen Netze?In Status > Interfaces hast du nur WAN und LAN?
Oder hast du doch etwas routed-IPSec (VTI) Tunnel konfiguriert? -
@viragomann
Unter Interfaces habe ich nur WAN und LANIch habe aktuell aber noch die statischen Routen eingetragen, die brauche ich nicht?
Dann lösche ich die. -
@tmevent
Wenn IPSec im Tunnel Mode (policy-based) ist, sind keine Routen nötig.
Das Routing wird automatisch von IPSec übernommen. In der Routingtabelle ist das aber nicht sichtbar.
Daher die Frage nach den SPDs. -
@viragomann
pfsense und Azure-VM erreichen sich jetzt gegenseitigüber die Tunnel erreiche ich aber meine VM nicht mehr
und das sind die SPD's denke ich mal ?
-
-
@tmevent said in Routing Probleme, pfsense und WAN aus LAN nicht erreichbar:
und das sind die SPD's denke ich mal ?
Wo die zu finden sind, habe ich doch oben geschrieben. Ich weiß nicht, ob hier im Widget richtig abgebildet wird, dass die Verbindung beiderseits in Ordnung ist.
Aber was soll der 2. Tunnel mit dem jeweils anderen Remote-Netz?
Möchtest du diese über Azure verbinden? -
sorry,
da is die TabelleFür mich unbekannt ist die ip x.y.z.89 ....
Die beiden Tunnel über die Pfsense zu verbinden wäre letztendlich die Kür ... ist aber kein Muss.
ich kann deaktiviere die zusätzlichen Phase 2 Einträge mal.
-
sobald ich diese Route aktiviere, finde ich die Azure-VM, deaktiviere ich sie, finde ich sie nicht mehr.
-
Hier mal die Routen, wenn ich keine statischen Routen aktiv habe
-
@tmevent said in Routing Probleme, pfsense und WAN aus LAN nicht erreichbar:
Für mich unbekannt ist die ip x.y.z.89 ....
Das ist ein Remote Endpunkt. Den solltest du eigentlich in einer Phase 1 definiert haben.
sobald ich diese Route aktiviere, finde ich die Azure-VM, deaktiviere ich sie, finde ich sie nicht mehr.
Das ist aber ein Remote-Netz. Das macht keinen Sinn.
Wenn du das LAN meinst, das muss auch anders gehen.
Mein einziges Azure Experiment liegt auch schon ein paar Monate zurück. Aber eine Route zum LAN brauchte es definitiv nicht. Ja, kann mich erinnern, dass Azure gerne alles über sein Gateway routet. Aber du hast geschrieben, die Gateway Konfiguration ist in Ordnung. In Ordnung heißt, im LAN muss die pfSense dein Gateway sein. Eventuell weiß da deine VM nichts davon.Da da hatte ich eine Site-2-Site IPSec laufen und einige Subnetze darüber verbunden, auch OpenVPN Access Server.
Mit der Forward- und NSG-Konfiguration klappte das dann tadellos. -
Für mich unbekannt ist die ip x.y.z.89 ....
Ich vermute, das es eine alte (dynamische) IP von 10.2.x.x war.Mit der Forward- und NSG-Konfiguration klappte das dann tadellos.
Einen Ping von der Azure VM auf 8.8.8.8 kann ich nachverfolgen auf pfsense, erst am Lan ausgehend, dann am WAN eingehend. bei der VM kommt der Reply aber nicht an.Forwarding habe ich aktuell an allen NICs aktiviert. Ich habe mich da gestern noch versucht einzulesen, bin aber noch nicht schlauer zumal die Dokumentationen die ich bisher gefunden haben sich immer auf eine 'normale' Portweiterleitung bezogen haben.
In den NSG's meines Azure-LANs habe ich neben den Default Regeln eine allow all.
Und die ICMP-Antwort sollte aus der Pfsense ihren Weg zurück kennen.Über die Tunnel erreiche ich (wenn Split Tunneling aus ist) auch das Internet nicht. Pings ins Azure-LAN sehe ich, Pings zu 8.8.8.8 nicht
-
@tmevent
Zum Thema IP-Weiterleitung habe ich nun einen passenden Link gefunden:
https://learn.microsoft.com/de-de/azure/virtual-network/tutorial-create-route-table-portalIch muss also an der Pfsense am WAN und am LAN Port IP-Weiterleitung an der NIC aktivieren.
Andere VMs die keinen Datenverkehr routen brauchen diese Option nicht.
-
@tmevent said in Routing Probleme, pfsense und WAN aus LAN nicht erreichbar:
In den NSG's meines Azure-LANs habe ich neben den Default Regeln eine allow all.
Gibt es das überhaupt? Soweit ich mich erinnern kann, braucht jedes einzelne Protokoll und jeder Port aktiviert eine gesonderte Regel.
Ich muss also an der Pfsense am WAN und am LAN Port IP-Weiterleitung an der NIC aktivieren.
Hast du ja längst gemacht, wie du geschrieben hast.
Ja, das muss auf jedem Interface aktiviert werden, das Pakete von anderen Quellen weiterleitet / durchroutet. Also auf einem Router auf allen Interfaces.
Über die Tunnel erreiche ich (wenn Split Tunneling aus ist) auch das Internet nicht. Pings ins Azure-LAN sehe ich
Von wo?
-
Gibt es das überhaupt? Soweit ich mich erinnern kann, braucht jedes einzelne Protokoll und jeder Port aktiviert eine gesonderte Regel.
Ja, die gibt es:!
Hast du ja längst gemacht, wie du geschrieben hast.
Es ging mir nur darum es noch mal festzuhalten (evtl. sucht irgendwann ja mal jemand hier nach Hilfe)Von wo?
Von einem Mobile Client aus der über IPsec verbunden ist.Ich habe nun ein bischen versucht die Pakete zu verfolgen(Diagnose>Paketverfolgung).
Wenn ich von meiner Azure-VM auf 8.8.8.8 pinge, sehe ich diesen Ping am LAN Port
20:41:46.674926 IP 10.3.0.4 > 8.8.8.8: ICMP echo request, id 1, seq 1054, length 40
und am WAN Port
20:45:53.162014 IP 8.8.8.8 > 10.3.0.4: ICMP echo reply, id 1, seq 1058, length 40Was mir unklar ist warum sehe ich den Ping nur eingehend und nicht ausgehend (oder gibt es da noch eine Option auch ausgehende Pakete zu sehen?
Da ich über Diagnose>Ping meine VM 10.3.0.4 sowohl vom LAN als auch vom WAN port aus erreiche, frage ich mich wo mein Ping verschwindet.
WAN
20:48:47.679123 IP 192.168.0.4 > 10.3.0.4: ICMP echo request, id 39016, seq 0, length 64
20:48:47.680056 IP 10.3.0.4 > 192.168.0.4: ICMP echo reply, id 39016, seq 0, length 64LAN
nichtsIrgendwie fehlen mir da einige Daten, der ausgehende Ping an 8.8.8.8, der Ping der pfsense auf dem LAN ..... Ich bekomme da nicht do ganz ein Bild zusammen.
-
Noch was ist mir aufgefallen / unklar:
In der ARP Tabelle sind 3 Einträge:
die Beiden NICs der pfsense
die Gateway IP meines WANMüsste ich da nicht noch meine Azure-VM finden ?