Routing Probleme, pfsense und WAN aus LAN nicht erreichbar

tmevent

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

@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-portal

Ich 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.

viragomann

@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?

tmevent

@viragomann

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 40

Was 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 64

LAN
nichts

Irgendwie 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.

tmevent

Noch was ist mir aufgefallen / unklar:
In der ARP Tabelle sind 3 Einträge:
die Beiden NICs der pfsense
die Gateway IP meines WAN

Müsste ich da nicht noch meine Azure-VM finden ?

tmevent

Und noch etwas out of topic was mir aufgefallen ist:

In der Firewall tauchen private IP Adressen auf die in meinen Netzen eigentlich nicht existieren, sowohl im LAN als auch im WAN.
Alles brav geblockt, wobei mit der any - any im LAN dürfte sie ja gar nicht geblockt sein (?)

Evtl. kannst Du mir da ja helfen, mein Wissen aufzufrischen.

viragomann

@tmevent said in Routing Probleme, pfsense und WAN aus LAN nicht erreichbar:

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 40

Ich würde mir am WAN erwarten, zumindest auch das ausgehende Paket zu sehen.
Aber wie auch immer, dass das Ziel am WAN 10.3.0.4 ist, heißt, dass es anderswo bereits genattet wurde. Dieses andere Geräte sollte aber gar kein Paket mit der Quell-IP 10.3.0.4 gesehen haben.(?)
Ja, das Azure SDN sieht alles und könnte das schon hinbekommen, aber es sollte sich korrekt verhalten.

Das könnte darauf hindeuten, dass das Outbound NAT nicht funktioniert.
Am WAN müsste dann auch ein ausgehendes Paket zu sehen sein, mit der Quell IP des WAN Interfaces.

Ein Load Balancer ist da nicht zufällig auch im Spiel?

Ich kann mich erinnern, dass ich mal an einem Punkt war, wo ich mich gefragt hatte, wofür ich mehrere Interfaces eingerichtet habe, wenn eh alle Pakete am selben ankommen (VMs mit mehreren Interfaces kosten auch mehr). Aber ich glaube, das hatte mit dem LB zu tun.
Ich habe es dann auch zumindest versuchsweise mit einem Interface konfiguriert, also eine Router-on-a-Stick Konfiguration. Hat ebenso gut funktioniert.

Aber soweit ich mich erinnern kann, war dieses Verhalten mit der entsprechenden Azure Routingtabelle zu beheben.

Noch was ist mir aufgefallen / unklar:
In der ARP Tabelle sind 3 Einträge:

Keine Ahnung. Aber auf ARP würde ich da nicht allzu viel geben. Das ist auf Azure meines Wissens ohnehin nutzlos.

Zu den seltsamen IPs weiß ich auch nichts. Ich kann mich nur erinnern, dass es ein paar zentrale Services auf Azure gibt, mit denen alle Geräte immer kommunizieren, wie DNS. Allerdings haben die öffentliche IPs, die aber von außen meist nicht zu erreichen sind.

Warum springt hier keiner ein, der mit Azure besser vertraut ist? Bei mir ist das schon eine Zeit zurück und ich plane auch nicht, mich damit in absehbarer Zeit nochmals eingehender zu beschäftigen. Meine Firma hat zum Glück nun einen anderen Weg eingeschlagen. ;-)
Vielleicht solltest du "Azure" in Thema mit aufnehmen, damit sich die richtigen Leute hier einfinden.

tmevent

@viragomann
Danke für den Tipp und vielen Dank schon mal für die Unterstützung bis hierhin.
Ich habe einen neuen Post gemacht, da ich hier das Topic nicht ändern konnte.
Neuer Post mit AZURE im Topic

Wenn Du mal im Bereich Veranstaltungen Unterstützung brauchen solltest, helfe ich gerne, da liegen meine Kernkompetenzen :-)

tmevent

@viragomann

Ein Load Balancer ist da nicht zufällig auch im Spiel?
Installiert habe ich keinen und wenn es nicht irgendwo ein Haken gibt der den aktiviert ist auf keinen Fall einer im Spiel.

Keine Ahnung. Aber auf ARP würde ich da nicht allzu viel geben. Das ist auf Azure meines Wissens ohnehin nutzlos.
Ok, ich hatte mich da nur gewundert als ich die Tablle gesehen habe.

viragomann

@tmevent
Danke für das Angebot. Könnte mal sein...

Gut möglich auch, dass die Chancen auf Hilfe in einem anderen Forum besser stehen. Bspw. reddit oder administrator.de.
Azure mit seinem SDN spielt da nach ganz anderen Regeln als ein Standard-Router wie pfSense, und ich glaube dort liegt das Problem.