Zum Inhalt springen

pfSense - kein Ping LAN -> WAN möglich


RubberDog

Empfohlene Beiträge

Moin,

ich spiele momentan zum ersten mal mit pfSense herum.
Nach einer Standard-Installation und minimaler Konfiguration kann ich allerdings nicht vom LAN ins WAN pingen.

Kurz zum Aufbau:
LAN-Seite ist 10.10.0.0/16, nur VMs drinnen.
WAN-Seite ist ein /24. Das zugehörige Gateway wurde eingetragen.
Alles spielt sich im IPv4 ab.

Über das WebGUI zu pfSense kann ich 8.8.8.8 oder google.de pingen mit Source WAN, Source LAN.
Die VM kann ich pingen mit Source LAN, Source WAN durch Firewallregeln blockiert.
VMs können sich gegenseitig pingen.
Von den VMs aus kann ich das LAN-Interface von pfSense pingen, aber nicht das WAN-Interface oder irgendeine WAN-IP.
Im VM-Netz werden IPs per DHCP von einem anderen Server vergeben. Subnetmask 255.255.0.0/16, Gateway die LAN-IP von pfSense.


Firewallregeln sind default nach Installation, NAT Outbound steht auf "Automatic".
Von intern nach extern pingen sollte also eigentlich problemlos möglich sein.

Hat jemand spontan eine Idee, was ich falsch gemacht haben könnte?
Weitere nötige Infos gern auf Nachfrage.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 51 Minuten schrieb _n4p_:

hast du beim ping n timeout oder no route to host?

Weder noch, die Shell gibt mir nur 100% packet loss zurück.

vor 51 Minuten schrieb _n4p_:

was hast du bei den Interfaces in pfSense konfiguriert? GW bei WAN eingetragen und kein GW bei LAN?

Richtig. WAN hat das Gateway aus dem /24, in dem das Interface sitzt. LAN hat keines.
Testweise hatte ich die LAN-IP von pfSense mal als GW für das LAN-Interface eingetragen, half aber auch nicht - daher wieder entfernt.


Edit:
Unter Windows bekomme ich beim gleichen Versuch ein Timeout.

Bearbeitet von RubberDog
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 8 Minuten schrieb _n4p_:

irgendwelche ICMP Regeln in der Firewall? falls ja, prüfen und bei bedarf mal logging aktivieren.

Nein, default-Regeln.
Alles darf raus, kein Pass für rein. Sollte angeblich funktionieren.
Testweise ICMP Echo-Reply WAN -> LAN   Src ANY / Dest ANY eingestellt, keine Änderung.

Packet Capture auf dem LAN-Interface mitlaufen lassen. Dort wird ein Echo Reply 8.8.8.8 > 10.10.0.50 (eine der VMs) angezeigt, siehe Screenshot. Kommt aber nichts an der VM an.

 

pfsense.png.56ce43407728852568cbf7e462521ce4.png

Bearbeitet von RubberDog
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Minute schrieb _n4p_:

in dem fall wird es nach pfSense gefiltert. ob von der VM selbst oder dem Host oder iwas das noch dazwischen steht.

Okay, dann versteh' ich es noch weniger.

Hinter pfSense hängen direkt die VMs. Hab's versucht mit nem Windows Server (Firewallsetting "Domäne") wie auch ein Ubuntu 18.04, keine Firewall o.ä.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hat sonst vielleicht noch jemand eine Idee?

Dass das ganze nach pfSense noch gefiltert wird, kann ich mir nicht vorstellen.
Wie bereits erwähnt, es befindet sich nichts mehr dazwischen - und ein ping von der VM an das LAN-Interface von pfSense geht ja auch durch.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wird ICMP-Verkehr auf den Maschinen eventuell lokal geblockt?

Wenn du das Packet auf LAN-Seite siehst, liegt es definitiv an den lokalen Maschinen, dass es dort verworfen wird, falls zwischen der pfSense-Kiste und den VMs nicht mehr geroutet wird.

GIb mal genauer den Netzwerkaufbau an (mit IP-Adressen - für WAN-Seite meinetwegen auch anonymisiert - auf LAN-Seite die IPs sind von außen ja eh nicht erreichbar, da die privaten Netze im Internet nicht geroutet werden.)

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 16 Stunden schrieb _n4p_:

du kannst noch unter diagnostics -> routes die routen ansehen ob da was falsch ist.

Die Routen sehen soweit korrekt aus.
 

vor einer Stunde schrieb Crash2001:

Wenn du das Packet auf LAN-Seite siehst, liegt es definitiv an den lokalen Maschinen, dass es dort verworfen wird, falls zwischen der pfSense-Kiste und den VMs nicht mehr geroutet wird.

War auch schon eine Vermutung. Ist leider nicht der Fall, pinge ich das LAN-Interface der pfSense vom Client aus, kommt der reply an.

vor einer Stunde schrieb Crash2001:

GIb mal genauer den Netzwerkaufbau an (mit IP-Adressen - für WAN-Seite meinetwegen auch anonymisiert - auf LAN-Seite die IPs sind von außen ja eh nicht erreichbar, da die privaten Netze im Internet nicht geroutet werden.)

Ne Skizze - nicht hübsch, zeigt aber den Aufbau.

 

Edit:
VMs bekommen derzeit per DHCP ab 10.10.0.50 - 10.10.0.249.
pfSense LAN Interface hat die 10.10.0.250.
Subnetmask jeweils 255.255.0.0.

Ja, ich könnte es kleiner skalieren. Ist aber bloß ein Testaufbau, auf Details kommt's noch nicht an.

Bearbeitet von RubberDog
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 11 Stunden schrieb RubberDog:

War auch schon eine Vermutung. Ist leider nicht der Fall, pinge ich das LAN-Interface der pfSense vom Client aus, kommt der reply an.

Dieses Ausschlussverfahren taugt halt nicht. ich kann durchaus die FW so einrichten das Hosts aus dem eigenen Netz pingen dürfen und sonst halt niemand. Ohne einen Blick in die FW-Regeln auf den VMs oder dem Host/Hypervisor, hilft die Aussage nicht.

Per DHCP mal einer phys. Maschine ein Lease aus dem Pool zuweisen. Versuchen zu pingen. Wireshark/...

Link zu diesem Kommentar
Auf anderen Seiten teilen

FW-Regeln sind default.
Alles ausm LAN darf raus, nichts (ausser reply-to) rein.
Testweise hatte ich alle ICMP von aussen auf Pass.

Keine Ahnung ob ich's hier auch schon gesagt hatte;
Ein Packet Capture auf dem LAN-Interface von pfSense zeigt sowohl den ausgehenden Echo Request, als auch den eingehenden ICMP echo reply.

Nach ein wenig weiterer Analyse gehen wir derzeit von einem Problem mit dem ESXi Hypervisor aus, und haben den Support von VMware mit einbezogen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 15 Minuten schrieb Crash2001:

Habt ihr denn einfach mal eine andere Virtualisierungsumgebung ausprobiert, ob es damit dann geht als Gegentest? Wäre eventuell schneller, als aufs Debugging vom Hersteller zu warten...

Leider haben wir gerade keinen Server übrig, auf dem wir alles nochmal mit anderem Hypervisor testen können.
Zeitkritisch ist das ganze glücklicherweise nicht, so dass wir schon etwas auf die Log-Analyse des Herstellers warten können.
Bis dahin gibt es auch noch genug anderes zu tun.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...