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.

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

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

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 11. Juni 20187 j von RubberDog

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

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.

 

Bearbeitet 11. Juni 20187 j von RubberDog

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

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

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.

Wenn du auf dem LAN Interface vom pfSense aber ein echo reply siehst, muss das ja iwo hingehen.

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

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

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 13. Juni 20187 j von RubberDog

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

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.

Wäre natürlich möglich, dass das das Problem ist.
 

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

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.

Die Lösung:

Mein Kollege hat beim erstellen der pfSense-VM eine kleinigkeit übersehen.
Der Host ist ein SmartOS, und das ist per default "etwas" restriktiver, was IP und Mac-Spoofing angeht.
NAT ohne Spoofing haut nicht so wirklich hin, und.. tja.