PfSense - ESXi 6.5 - Internet verbindung

Sind die über 2 als WAN Ports definierte Interfaces verbunden ??
Dann ist das klar und auch logisch warum dem so ist:

• Der WAN Port macht NAT (IP Adress Translation) im Default. Diese NAT Firewall kannst du ohne Port Forwarding nicht überwinden.
• Per Default sind RFC 1918 IP netze auf dem WAN Port geblockt. Das müsstest du aufheben bei 10er, 172.16er oder 192.168er Adressierung.
• Obendrein ist eine DENY any any regel auf dem WAN aktiv.

Fazit: das WAN Interface ist 3fach verrammelt. Aus gutem Grund, denn in "normalen" Szenarien hängt da das Internet drauf.
Bei dir ist das ja nicht der Fall, deshalb solltest du zur Kopplung keinen als WAN Port definiertes Interface nehmen sondern logischerweise immer ohne NAT dort arbeiten.
Dann reicht es das entsprechende Regelset dort zu aktivieren und dann kann dort auch Traffic passieren.
Natürlich nur sofern das gewollt ist.
Das zeigt das auf deiner oder deinen pfSense irgendo die Default Route oder ein Gateway Eintrag fehlt !!!
Hast du den Internet Router oder das Internet Gateway unter System -> Routing definiert ??

• Dort MUSS es als Default Gateway eingerichtet sein (Gateway Monitoring deaktivieren).
• Dann MUSS es im 2ten Schritt auf dem Interface was zum Internet Router führt dort unter "IPv4 Upstream gateway" im Auswahlfenster definiert sein !!

Erst dann ist das richtig konfiuguriert.
Unter Diagnostics -> Ping muss dann zwingend die 8.8.8.8 pingbar sein wenn du dort als "Source address" das pfSense Interface angibst was die Verbindung auf den Internet Router hast, also genau das wo oben auch das Upstream Gateway definiert ist.
Das MUSS klappen, ansonsten brauchst du gar nicht erst weiterzumachen.
Sehr hilfreich ist auch das Traceroute unter Diagnostics -> Traceroute. Das zeigt dir dann alle Routing Hops an die z.B. ein Traceroute auf das Ziel 8.8.8.8 ausführt. Da wo es nicht weitergeht ist auch der Fehler.
Bei dir mit sehr großer Wahrscheinlichkeit also ein fehlendes oder falsch konfiguriertes Gateway.
8.8.8.8 oder irgendwelche andere "nackte" IP Adresse im Internet muss ja logischerweise von dem pfSense Interface pingbar sein was die Verbindung zum Internet Router hat !
Das kann auch: 82.149.225.21 (administrator.de) oder 193.99.144.85 (heise.de) usw. sein !
ACHTUNG hier:
Wenn dein pfSense Interface was zum Internet Router geht kein NAT macht, also keine Adress Translation, dann brauchst du natürlich eine statische Route auf dem Internet Router in deine lokalen Netze.
Ansonsten würde der Internet Router die zum Provider routen und damit dann ins Nirwana...logisch.
Hier musst du also aufpassen ob NAT an den pfSense Internet Ports aktiv ist oder nicht.
Ist dem so kannst du im Internet Router mit einer statischen Summary Route z.B. alle 10er Netze auf die pfSense routen ala:
Zielnetz: 10.0.0.0, Maske: 255.0.0.0, Gateway: <WAN Port ip pfSense>
Wie gesagt nur wenn du kein NAT machst, was in deinem Setup empfehlenswert ist !
Traceroute ist hier wie gesagt dein bester Freund
Richtig aber WAS genau meinst du mit "deaktiviert" ??
Bedenke das das bei einer Firewall immer fatal ist, denn ganz OHNE Rules BLOCKT die Firewall gnadenloss alles an dem Interface, dann geht gar nix mehr.
Du müsstest mit "deaktivieren" dann eine sog. "Scheunentor Regel" aktivieren, die * * any zu any erlaubt.
...was den schon oben geäußerten Verdacht eines fehlerhaft definierten Default Gateways bei dir verhärtet !!!
Ebenso die fehlenden statischen Routen im Internet Router auf die lokalen LANs an der pfSense !
Das ist auch sehr gut so und solltest du in deinem Setup auch so belassen. NAT wäre in deinem Design kontraproduktiv und würde das Setup unnötig verkomplizieren.
Ping ist ICMP Protokoll ! Vergiss das nicht wenn du Regeln aufsetzt.
Dein Beispiel von "eth1" zeigt dort z.B. das dort eine ICMP Regel vollkommen fehlt. Dadurch gehen keinerlei Pings z.B. durch dieses Interface ! Hast du das beachtet ??
Auch wenn du ICMP erlaubst wie an eth2 zu eth0 musst du bei einer Firewall auch immer den Antwortweg beachten ! Der Ping geht dann zwar zu eth0 kommt dort am Ziel an dasa dann mit einem ICMP Echo Reply antwortet aber wenn dann z.B. an eth0 auch die ICMP erlauben Regel fehlt dann bleibt die Antwort dort hängen.
Also immer den Rückweg auch auf dem Radar haben !!

Es ist aber auch zu vermuten das all dies aus dem oben schon erwähnten falschen Gateway Setup und den vermutlich auch fehlenden statischen Routen im Internet Router resultiert.
Die eine oder andere falsche Regel mag dazukommen.
Das ist aber alles einstellbar.
Vielleicht helfen dir noch ein paar Routing Grundlagen zum Verständnis:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Das war damit gemeint


Warum meinst du das es nicht so ist ?? Das ist ein ziemlicher Trugschluss !
Stell dir doch ganz einfach immer mal den Weg eines IP Paketes im Netzwerk vor. Dann ist das doch kinderleicht zu verstehen...
Nehmen wir mal an du hast von Netz 1 zu Netz 2 TCP 80 erlaubt in den Inbound Regeln an Netz 1. An Netz 2 hast du es aber verboten.
Dann geht ein HTTP Request von Netz 1 zu einem Zielhost in Netz 2, der antwortet und das Antwortpaket hat als Zieladresse eine Netz 1 Adresse die dann geblockt wird.
Wenn du also rein auf IP Adressen das Regelwerk hast gilt sehr wohl auch der Rückweg bei TCP !!!
Das obige löst du indem du Netz 2 zu Netz 1 TCP verbindungen nur mit gesetztem ACK Bit erlaubst:


Damit können dann Antwort Pakete aus Netz 2 passieren ins Netz 1 aber es können aktiv keine Verbindungen aus dem Netz 2 ins Netz 1 gemacht werden.
Du siehst also der Rückweg ist so oder so IMMER relevant und muss daher immer zwingend beachtet werden.
Vermutlich scheitern deine Regeln an diesem deinem Irrglauben ?!

Zum Rest:
Es ist generell schlecht und KEIN guter Stil statische Routen auf Endgeräte zu konfigurieren. Das sollte man niemals machen, nur im absoluten Notfall.
Routen sollen immer Router oder Firewalls !!
Diese statische Route solltest du also zwingend im Router unter der 10.201.0.1 definieren !!
Mal ganz davon abgesehen das die von dir dort konfigurierte Route 192.168.168.0 255.255.255.0 192.168.168.253 ja auch totaler Blödsinn ist.
Denke doch mal bitte etwas logisch nach !!!
Stelle dir wieder vor wie ein Paket transportiert wird !
Du sagst deinem Windows Client hier das er ein IP Netz was er NICHT kennt über ein Gateway erreicht dessen IP Adresse selber in dem Netzwerk liegt was er NICHT kennt !!
Wie bitte stellst du dir vor das dieser Rechner diese Gateway Adresse jemals erreichen kann ?
Sorry aber diesen Routing Schwachsinn erkennst du sicherlich selber, oder ?!
Klar und erwartbar also das diese Blödsinn in die Hose geht.

Bitte lies dir dazu unbedingt diese_Geschichte über den Weg eines gerouteten IP Paketes durch, die das transparent veranschaulicht ! So musst du dir die Wegefindung und die dazu korrespondierenden Regeln und Routing immer vorstellen.

Fazit: Lösche den Routing Blödsinn in den Endgeräten ganz schnell. Korrigiere deine Routen !
Bitte aber RICHTIG und in den Gateways und NICHT auf den Endgeräten !!!

Nochmal ganz langsam.....
Dein Winblows Client hat die folgende IP Adressierung (DNS usw. außen vor es geht erstmal nur ums Routing): IP 10.201.0.2 /24
GW 10.201.0.1
Soweit richtig. Das Gerät ist Teil des IP Netzes 10.201.0.0 /24 Es "kennt" also einzig nur dieses IP Netz und keine anderen. Wenn es Daten in andere Netze schicken soll oder muss wie z.B. ins 192.168.168.0er Netz sendet es also alles an die Gateway IP in der Hoffnung das das Gateway den Weg zum Ziel kennt.
In dem IP Paket des Clients steht dann als Absender IP 10.201.0.2 und als Ziel IP 192.168.168.1. So kommt es am Gateway an
Soweit so gut...klasssiches IP Verhalten im IP Stack des Endgerätes.
Jetzt konfigurierst du dem Client eine statische Route: Ziel: 192.168.168.0 255.255.255.0 GW: 192.168.168.253
Mal abgesehen davon das die Route kompletter Blödsinn ist denn das Gateway liegt ja niemals in dem Netz was erreicht werden soll..aber egal, wir betrachten es mal so.
Damit stürzt du den Client nun in ein Dilemm.
Er hat ja nun ein Paket im Stack mit Absender IP 10.201.0.2 und als Ziel IP 192.168.168.1.
Da er das Ziel nicht kennt sieht der Client in seine Routing Tabelle.
Außer dem Default Gateway was in seinem eigenen Netz steht und er erreichen kann findet er dort einen Eintrag für das Ziel. Soweit so gut
Um zum Ziel zu kommen muss er das Gateway 192.168.168.1 erreichen können was aber wiederum in einem Netz liegt was der Client nicht kennt und wofür er zwingend ein Gateway benötigt über das er dieses Ziel erreicht. Da das 192.168.168.0er Netz nicht direkt an ihm dran ist kann er dieses netz nicht oder nur über ein Gateway erreichen das in einem Netz liegt was der Client erreichen kann. Das ist ja einzig nur das 10.201.0.0er Netz.
Du erkennst vermutlich nun das Problem und wie unsinnig die Route für ihn ist. Diese falsche und unsinnige Route bewirkt das er das Paket verwirft und nichtmal ans Default Gateway 10.201.0.1 schickt. Macht also dein Problem doppelt schlimm.
Kann es sein das dir hier etwas Grundlagen zur einfachen IP Kommunikation fehlen ??

Vergiss also diese unsinnige Route und lösche die so schnell wie möglich. belasse es beim Default Gateway. Das ist ja sicher die pfSense, oder ?
Wenn die ein Bein im 192.168.168.0er Netz hast benötigst du dort logischerweise auch keine Route, denn das Bein (Interface) ist ja dann direkt an ihr angeschlossen und die FW "kennt" dann logischerweise dieses Netz.
Liegt es auf einer anderen Firewall oder Router dann braucht sie eine statische Route dahin über ein Interface was sie "kennt".
Einfachste und simplete IP Routing Logik. Ist wie beim Auto und den Verkehrsschildern
Da hast du absolut Recht ! Aber fasse dich da zuallererst mal an die eigene Nase !!!
Wozu bitte musst du dann dem Client einemn sinnfrei zusätzliche statische Route geben wenn das 192.168.168.0er Netz direkt an dem Default Gateway des Clients 10.201.0.1 angeschlossen ist.
Dann brauchst du weder eine ohnehin sinnlose Route auf dem Client noch eine auf dem Gateway.
Wenn der Ping auf das 192.168.168.0er Interface des Gateways oder andere Geräte in diesem Netz nicht klappt dann liegt es zu 99% an den Firewall Regeln des Gateways oder...
Wenn es andere Geräte im 192.168.168.0er Netz sind bei denen an einem fehlerhaften Gateway.
Diese müsste ja für die Antwort auch auf das 192.168.168.0er Bein der Firewall zeigen damit die Antwort ankommt.
Zeigt es hingegen z.B. auf einen Internet Router im 192.168.168.0er Netz was vermutlich der Fall bei deiner PC NIC ist ?! hast du wieder ein Problem.
Hat dieser Router dann keine statische Route auf das 10.201.0.0er Netz (via pfSense Gateway im 192.168.168.0er Netz) schickt er das Antwortpaket in Richtug Internet provider und damit dann ins Nirwana.
Da sind wir dann mal wieder beim Thema Rückweg....!!!

Lies dir nochmal das hiesige Routing Tutorial zu dem Thema durch (ohne das NAT bzw. ICS Thema) dort steht an einem sehr einfachen Beispiel mit 2 Netzen alles beschrieben was man dazu wissen muss.
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Diese Skizze verdeutlich hoffentlich auch nochmal zusätzlich etwas die Routing Logik für dich ?!

Klasse, Glückwunsch !!
Nicht denken sondern nachdenken !!
Nein, da es sich hier um Firewalls ! handelt ist das nicht der Fall. Auf den Interfaces gilt immer als Default Regel: DENY any any ! Es ist also explizit alles verboten.
Wären es reine Router hättest du Recht die blockieren nix aber bei Firewalls geht ohne Regeln nix am Interface.
Das ist aber ne Binsenweisheit die nun jeder Netzwerker kennt.

Fazit: Damit die miteinander reden musst du auf den Koppelinterfaces die das 10.101.0.0 /25er Koppelnetz bedienen auch entsprechende Regeln definieren !!
Im Zweifel also immer eine "Scheunentor" Regel: IPv4 PASS any any. Damit wird dann wie bei einem Router alles erstmal durchgelassen was IPv4 ist. (Protocoll ist hier "any" !)

Ist so oder so in komplexeren FW Designs immer schlau das so zu machen um erstmal die generelle IPv4 Connectivity zu testen und dann danach an den Interfaces Stück für Stück die Schotten dichtzumachen.
So weißt du immer wenn gerade irgendwas blockt und kannst es immer wieder rückgängig machen.
Besonders einfach mit dem Aktivieren und Deaktivieren der Regel. So kann man die Scheunentor Regel immer per Mausklick wegnehmen oder zuschalten wenn sie gleich als Erste im Regelwerk steht (Reihenfolge zählt !)
Das ist natürlich Quatsch...sorry.
Du kannst soviel Routen und Gateways im Setup definieren wie du lustig bist. Ob sie aber auch SINNVOLL sind ist eine andere Frage. Siehe deine Gruselroute oben. Konfigurieren kann man viel
Das "sie sich nicht sehen" hat ja vermutlich mit den Regeln dort zu tun sofern die beiden Interfaces physisch verbunden sind !
Fazit: Prüfe hier also die Regeln oder nutze erstmal das "Scheunentor" auf beiden Seiten testweise !
Das ist auch richtig so.
Es betrifft aber nur die IP Netze die NICHT direkt angeschlossen sind, also die, die die FW deshalb nicht kennt oder nicht kennen kann. Siehe Zeichnung oben !!
Wie gesagt mit entsprechenden Regeln und wenn die Interfaces physisch (also Layer2) verbunden sind MUSS das gehen !!!

Nutze hier zum Test immer die Ping Funktion unter Diagnostics und gib als Absender IP immer das eigene Interface an was auf die andere FW verbindet und als Ziel das andere FW Interface im gleichen Netz.
So pingst du immer eine Punkt zu Punkt Verbindung und kannst niemals Gefahr laufen das die andere Seite durch eine falsche Absender IP in Routing Probleme rennt wenn bei dir das Routing wieder nicht stimmen sollte.
Punkt zu Punkt geht IMMER !! Auch ohne GW und Routen !
Wenn nicht hast du ein physisches Verbindungsproblem !
Klares NEIN !
Ist doch auch logisch, denn die Firewall ist ja immer ein Router !
Sie ist aber ein Router mit einem Filter an JEDEM Interface, das ist der kleine aber feine Unterschied. Das macht die Sache tricky und man muss doppelt aufpassen das Filter UND Routing passen !
Also erstmal alles aufmachen mit Scheunentor, dann langsam dichtmachen.... Das ist der Trick