26
Pfsense: Routing zwischen Interfaces
Hallo Leute,
gleich vorweg:
Ich weiß, dass dieses Thema schon zig Mal im Internet behandelt wurde.
Ich habe mich hier jetzt selbst schon Stunden durchgeschlagen mit Lesen von Foren. Leider komme ich aber trotzdem nicht weiter.
Daher hoffe ich, dass ihr mir weiterhelfen könnt.
Mein Aufbau:
Mein Problem:
Mir ist es leider vom LAN Netz aus nicht möglich, Geräte im GAST Netz zu pingen.
Ich kann vom LAN Netz aus die "externe Seite" von der pfSense im GAST Netz (192.168.130.150) pingen.
Von der pfsense selbst kann ich die Geräte im GAST Netz pingen.
Windows-Firewall usw. ist alles deaktiviert.
Auch passen die Firewall Regeln auf der pfSense (habe ich kontrolliert in dem ich bei den Regeln logging aktiviert und diese dann im SystemLog kontrolliert habe)
lt. den zig Beschreibungen um Netz muss ich auch keine eigenen Routen erstellen, damit dies möglich ist.
Kann mir wer sagen, was ich hier übersehe oder wo hier der Fehler begraben liegt?
Herzlichen Dank im Voraus
Patrick
gleich vorweg:
Ich weiß, dass dieses Thema schon zig Mal im Internet behandelt wurde.
Ich habe mich hier jetzt selbst schon Stunden durchgeschlagen mit Lesen von Foren. Leider komme ich aber trotzdem nicht weiter.
Daher hoffe ich, dass ihr mir weiterhelfen könnt.
Mein Aufbau:
Mein Problem:
Mir ist es leider vom LAN Netz aus nicht möglich, Geräte im GAST Netz zu pingen.
Ich kann vom LAN Netz aus die "externe Seite" von der pfSense im GAST Netz (192.168.130.150) pingen.
Von der pfsense selbst kann ich die Geräte im GAST Netz pingen.
Windows-Firewall usw. ist alles deaktiviert.
Auch passen die Firewall Regeln auf der pfSense (habe ich kontrolliert in dem ich bei den Regeln logging aktiviert und diese dann im SystemLog kontrolliert habe)
lt. den zig Beschreibungen um Netz muss ich auch keine eigenen Routen erstellen, damit dies möglich ist.
Kann mir wer sagen, was ich hier übersehe oder wo hier der Fehler begraben liegt?
Herzlichen Dank im Voraus
Patrick
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 258365
Url: https://administrator.de/forum/pfsense-routing-zwischen-interfaces-258365.html
Ausgedruckt am: 21.12.2024 um 14:12 Uhr
26 Kommentare
Neuester Kommentar
Hast du explizit eine Firewall-Regel angelegt, die von LAN zum Gastnetz greift? Denk dran, dass für Ping ein spezieller Protokolltyp namens ICMP genutzt wird, Standardwert bei der Regelanlage ist TCP.
1
Außer dem LAN Inteface das in der Standard Konfig daherkommt mit einer any zu any Regel sind alle anderen Interfaces wie bei einer Firewall grundlegend üblich alle gesperrt.
In einer FW ist im Default alles verboten was nicht explizit erlaubt ist !!
In von dir eingerichteten Interfaces außer dem LAN Interface musst du also entsprechende FW Regeln erstellen !!
Kollege tikayevent hat ja schon richtigerweise darauf hingewiesen.
Weitere Grundlagen zu dem Thema findest du in den Threads dieser Forumstutorials:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
und auch
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
und ganz allgemein hier:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Bedenke immer auch 2 Grundregeln bei den Firewall regeln:
In einer FW ist im Default alles verboten was nicht explizit erlaubt ist !!
In von dir eingerichteten Interfaces außer dem LAN Interface musst du also entsprechende FW Regeln erstellen !!
Kollege tikayevent hat ja schon richtigerweise darauf hingewiesen.
Weitere Grundlagen zu dem Thema findest du in den Threads dieser Forumstutorials:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
und auch
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
und ganz allgemein hier:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Bedenke immer auch 2 Grundregeln bei den Firewall regeln:
- Regeln gelten immer nur inbound als vom Interface IN die Firewall rein
- Es gilt "First match wins !" im Regelwerk. Ist also eine der Regeln positiv, werden die nachfolgenden NICHT mehr abgearbeitet !! Reihenfolge zählt also auch in den Regeln !
Danke für eure Antwort.
Ich habe jetzt zum Testen eine Regel erstellt, die alles erlaubt:
Habe dies auch in den Logs kontrolliert:
Windows-Firewall ist immer noch deaktiviert. Und dennoch funktioniert es nicht.
Kann hier wirklich was an den Regeln falsch sein?
Danke
Ich habe jetzt zum Testen eine Regel erstellt, die alles erlaubt:
Habe dies auch in den Logs kontrolliert:
Windows-Firewall ist immer noch deaktiviert. Und dennoch funktioniert es nicht.
Kann hier wirklich was an den Regeln falsch sein?
Danke
Ich habe jetzt zum Testen eine Regel erstellt, die alles erlaubt:
Die drei darunter sind dann überflüssiger Unsinn !Und dennoch funktioniert es nicht.
Hast du auch den Rückweg bedacht ??Vom LAN geht zwar jetzt alles raus und auch ins Gast Segment aber wenn der Rechner im Gast Segment antwortet hast du da ja wieder ein Firewall Interface wo die Firewall lauert
Sie dir also auch dort das Regelwerk an !
Auch da gilt: Ist nix eingetragen ist alles verboten !
Kein Antwort Paket = Keine Verbindung ! So eichfach ist das !!
Fazit: Betrachte immer den GANZEN Weg eines Ethernet IP Paketes !
Habe mittlerweile den Fehler gefunden.
Auf den Gerät im GAST Netz war kein Standardgateway eingetragen.
Wenn man da was einträgt, funktioniert es.
Bzw. habe ich da das Problem, dass ich dort ein Gerät verwenden will, wo man selbst keinen Zugriff auf die NW-Einstellungen hat.
Und nachdem da standardmäßig kein Gateway eingetragen ist, funktioniert das eben so nicht.
Gibt es da jetzt noch irgend einen Trick, wie man das Firewallseitig "umgehen/beheben" kann?
Patrick
Auf den Gerät im GAST Netz war kein Standardgateway eingetragen.
Wenn man da was einträgt, funktioniert es.
Bzw. habe ich da das Problem, dass ich dort ein Gerät verwenden will, wo man selbst keinen Zugriff auf die NW-Einstellungen hat.
Und nachdem da standardmäßig kein Gateway eingetragen ist, funktioniert das eben so nicht.
Gibt es da jetzt noch irgend einen Trick, wie man das Firewallseitig "umgehen/beheben" kann?
Patrick
Hi,
ohne Routing wirst du nicht so einfach von einem Netz ins andere kommen... und ohne Gateway kommst du nicht zum Router...
Beste Grüße!
Edit: Du könntest natürlich per NAT die Ports vom Routerinterface ins andere Netz weiterleiten, dann hättest du eine lokale Adresse mit der du ohne Gateway arbeiten könntest... (Ist mal so ein Schnellschuss von mir...)
ohne Routing wirst du nicht so einfach von einem Netz ins andere kommen... und ohne Gateway kommst du nicht zum Router...
Beste Grüße!
Edit: Du könntest natürlich per NAT die Ports vom Routerinterface ins andere Netz weiterleiten, dann hättest du eine lokale Adresse mit der du ohne Gateway arbeiten könntest... (Ist mal so ein Schnellschuss von mir...)
@aqui: Das können die Paketfilter selbstständig, ansonsten würde man sich ja ständig unnötige Löcher bohren. Rückrouten ja, Firewallregeln in Antwortrichtung nein.
Sicher gibts irgendwelche speziellen oder alten Firewallsysteme, bei denen das nötig ist, aber die heutige gängigen haben da eine gewisse Eigenintelligenz.
@Badger: Ohne eingetragenes Gateway oder Router ist keine netzübergreifende Kommunikation möglich. Bei Geräten ohne Gatewayeintrag ist auch keine Firewall nötig, das Gerät weiß ja nicht, wohin mit den Paketen.
@BirdyB: Das mit dem NAT klappt nicht. Wenn würde es mit ProxyARP klappen, da aber auch nicht garantiert.
Sicher gibts irgendwelche speziellen oder alten Firewallsysteme, bei denen das nötig ist, aber die heutige gängigen haben da eine gewisse Eigenintelligenz.
@Badger: Ohne eingetragenes Gateway oder Router ist keine netzübergreifende Kommunikation möglich. Bei Geräten ohne Gatewayeintrag ist auch keine Firewall nötig, das Gerät weiß ja nicht, wohin mit den Paketen.
@BirdyB: Das mit dem NAT klappt nicht. Wenn würde es mit ProxyARP klappen, da aber auch nicht garantiert.
1
@tikayevent
Beim Forwarding innerhalb der Firewall Interfaces muss man das beachten.
Bis dato hab ich das an der pfSense noch nicht gefunden mit der Eigenintelligenz. Bei PFW Regeln am WAN Port z.B. da passiert das und das zeigt die FW auch mit einem entsprechenden Hinweis im GUI aber von LAN Port zu LAN Port hab ichs noch nicht gesehen...oder übersehen
Das können die Paketfilter selbstständig
Nein leider nicht ganz. Wenn du eine entsprechende Pass Regel am LAN Port hast am zweiten Port aber nicht wird das Antwort Paket geblockt.Beim Forwarding innerhalb der Firewall Interfaces muss man das beachten.
Bis dato hab ich das an der pfSense noch nicht gefunden mit der Eigenintelligenz. Bei PFW Regeln am WAN Port z.B. da passiert das und das zeigt die FW auch mit einem entsprechenden Hinweis im GUI aber von LAN Port zu LAN Port hab ichs noch nicht gesehen...oder übersehen
Zitat von @aqui:
@tikayevent
> Das können die Paketfilter selbstständig
Nein leider nicht ganz. Wenn du eine entsprechende Pass Regel am LAN Port hast am zweiten Port aber nicht wird das Antwort Paket
geblockt.
Beim Forwarding innerhalb der Firewall Interfaces muss man das beachten.
Bis dato hab ich das an der pfSense noch nicht gefunden mit der Eigenintelligenz. Bei PFW Regeln am WAN Port z.B. da passiert das
und das zeigt die FW auch mit einem entsprechenden Hinweis im GUI aber von LAN Port zu LAN Port hab ichs noch nicht gesehen...oder
übersehen
@tikayevent
> Das können die Paketfilter selbstständig
Nein leider nicht ganz. Wenn du eine entsprechende Pass Regel am LAN Port hast am zweiten Port aber nicht wird das Antwort Paket
geblockt.
Beim Forwarding innerhalb der Firewall Interfaces muss man das beachten.
Bis dato hab ich das an der pfSense noch nicht gefunden mit der Eigenintelligenz. Bei PFW Regeln am WAN Port z.B. da passiert das
und das zeigt die FW auch mit einem entsprechenden Hinweis im GUI aber von LAN Port zu LAN Port hab ichs noch nicht gesehen...oder
übersehen
Iich würde jetzt Kollege tikayevent zustimmen. "Innerhalb" (also z.b. von int1 zu int2) einer Firewall ist es doch vollkommen okay wenn die FW die Antwortpakete durchlässt -> Stateful Inspection. Für meine begriffe ist diese Eigenintelligenz seit langem Standard, oder?
Sicher aus Firewall Sicht wäre das dann nicht wenn sie Pakete mit gesetztem ACK Bit passieren lassen würde. Eher fahrlässig... Tut sie auch glücklicherweise nicht
Du liegst hier definitiv falsch, aqui. Deine Ausführungen sind nur bei statischen Paketfiltern zutreffend. PfSense hat aber eine SPI-Firewall.
Gruß
sk
Gruß
sk
1Zitat von @Badger:
Habe mittlerweile den Fehler gefunden.
Auf den Gerät im GAST Netz war kein Standardgateway eingetragen.
Wenn man da was einträgt, funktioniert es.
Bzw. habe ich da das Problem, dass ich dort ein Gerät verwenden will, wo man selbst keinen Zugriff auf die NW-Einstellungen
hat.
Und nachdem da standardmäßig kein Gateway eingetragen ist, funktioniert das eben so nicht.
Gibt es da jetzt noch irgend einen Trick, wie man das Firewallseitig "umgehen/beheben" kann?
Habe mittlerweile den Fehler gefunden.
Auf den Gerät im GAST Netz war kein Standardgateway eingetragen.
Wenn man da was einträgt, funktioniert es.
Bzw. habe ich da das Problem, dass ich dort ein Gerät verwenden will, wo man selbst keinen Zugriff auf die NW-Einstellungen
hat.
Und nachdem da standardmäßig kein Gateway eingetragen ist, funktioniert das eben so nicht.
Gibt es da jetzt noch irgend einen Trick, wie man das Firewallseitig "umgehen/beheben" kann?
Ja ist ganz einfach. Da Du initial ja nur von LAN nach Gast-Netz zugreifen möchtest, maskierst Du einfach die Source-IP des ausgehenden Traffics auf die des outgoing Interfaces. Also stink normales Source-NAT/Masquerading. Ich hab jetzt schon einige Jahre nicht mehr mit pfSense gearbeitet, aber meiner Erinnerung nach musst Du hierfür "Advanced Outbound NAT" aktivieren und konfigurieren. Beachte dabei die Konsequenzen für den LAN-to-WAN-Traffic!
Siehe https://doc.pfsense.org/index.php/Outbound_NAT
Gruß
sk
2
@aqui: ich hatte früher mehrere pfSense-Systeme produktiv im Betrieb, teilweise in Clusterinstallationen und mit 16 Interfaces (VLAN versteht sich).
Ich habe NIEMALS nur eine Regel für Antwortpakete geschrieben, diese werden automatisch durchgeschoben. Selbst beim Grundprodukt m0n0wall ist es nicht nötig.
Jetzt arbeite ich mit LANCOM, bintec und FortiNet. Auch hier schreibe ich keine einzige Regel für die Antwortpakete.
Ich habe NIEMALS nur eine Regel für Antwortpakete geschrieben, diese werden automatisch durchgeschoben. Selbst beim Grundprodukt m0n0wall ist es nicht nötig.
Jetzt arbeite ich mit LANCOM, bintec und FortiNet. Auch hier schreibe ich keine einzige Regel für die Antwortpakete.
1
Hi Badger,
.
Da es sich um LAN-Verbindung innerhalb der pfSense handelt, bedarf es keines Gateways.
Das funktioniert dann zwar auch, ist aber eigentlich so nicht richtig.
Definitiv regeln das alles die Rules auf den einzelnen Interfaces, wo bei Dir etwas nicht passt.
Gruß orcape
Auf den Gerät im GAST Netz war kein Standardgateway eingetragen.
Wenn man da was einträgt, funktioniert es.
Deutsche Übersetzung aus dem pfSense-GUI...Wenn man da was einträgt, funktioniert es.
Wenn diese Schnittstelle eine Internetverbindung ist, eine vorhandene Gateway aus der Liste auswählen oder einen neuen hinzufügen über den Link oben.In lokalen LANs sollte das upstream-Gateway 'none' Da es sich um LAN-Verbindung innerhalb der pfSense handelt, bedarf es keines Gateways.
Das funktioniert dann zwar auch, ist aber eigentlich so nicht richtig.
Definitiv regeln das alles die Rules auf den einzelnen Interfaces, wo bei Dir etwas nicht passt.
Gruß orcape
OK, ich gebe mich geschlagen bei der Übermacht, werde das aber trotzdem nochmal zur Sicherheit (und zur persönlichen Klarstellung) ausprobieren
Hi Aqui,
Trifft wohl zu, was da gesprochen wurde.....
Ist Weihnachten, da kann man zu Gunsten des Gänsebratens schon mal etwas daneben liegen...
Gruß & schöne Feiertage...orcape
....ausprobieren
...habe ich auch schon getan...Trifft wohl zu, was da gesprochen wurde.....
Ist Weihnachten, da kann man zu Gunsten des Gänsebratens schon mal etwas daneben liegen...
Gruß & schöne Feiertage...orcape
Vertrauen ist gut...Kontrolle ist besser
Nach den Feiertagen melde ich mich auch wieder zurück 
Erstmal danke für eure Antworten.
@..sk..:
Danke dir, werde das ausprobieren!
@orcape:
Wenn hier etwas falsch sein soll: kannst du mir sagen, wie ich den Fehler lokalisieren soll? In den Logs usw ist alles ohne Fehler.
Habe dann ein Testgerät in das besagte Netzwerk gehängt. Und sobald ich den Testgerät einen Gateway zuweise, geht ping usw ohne Probleme.
Entferne ich diesen, geht nichts mehr.
Erstmal danke für eure Antworten.
@..sk..:
Danke dir, werde das ausprobieren!
@orcape:
Wenn hier etwas falsch sein soll: kannst du mir sagen, wie ich den Fehler lokalisieren soll? In den Logs usw ist alles ohne Fehler.
Habe dann ein Testgerät in das besagte Netzwerk gehängt. Und sobald ich den Testgerät einen Gateway zuweise, geht ping usw ohne Probleme.
Entferne ich diesen, geht nichts mehr.
Hi,
Du musst auch für das ICMP-Protokoll (Ping) explizit eine Rule eintragen, sonst wird das nichts.
Ohne Regeln sind die Interfaces untereinander geblockt, Du machst mit dem Gateway nur das Scheunentor auf.
Gruß orcape
Und sobald ich den Testgerät einen Gateway zuweise, geht ping usw ohne Probleme.
Entferne ich diesen, geht nichts mehr.
Hast Du denn eine Rule ausgehend auf dem Interface eingetragen?Entferne ich diesen, geht nichts mehr.
Du musst auch für das ICMP-Protokoll (Ping) explizit eine Rule eintragen, sonst wird das nichts.
Ohne Regeln sind die Interfaces untereinander geblockt, Du machst mit dem Gateway nur das Scheunentor auf.
Gruß orcape
Mein Gott orcape, lies doch noch einmal den kompletten Thread! Das Thema ist doch durch: Der Client kennt die Rückroute nicht. Die Lösung wurde aufgezeigt. Das betrifft das Firewallregelwerk in keinster Weise und reisst auch keine zusätzlichen Sicherheitslücken.
Gruß
sk
Gruß
sk
Hi,
@..sk..
Den Rest übernehmen die Rules der FW und das funktioniert so, wie ich mir das vorstelle.
Da aber der "Weg nach Rom" wohl sehr unterschiedlich ausfallen kann, bin ich gerne bereit noch dazu zu lernen.
Ich muß hier @tikayevent Recht geben...
So eine pfSense ist eben keine FritzBox und nicht wirklich für Otto Normalverbraucher gedacht, auch wenn die sie immer häufiger in Gebrauch haben.....
Gruß orcape
@..sk..
aber meiner Erinnerung nach musst Du hierfür "Advanced Outbound NAT" aktivieren
In meiner pfSense-Konfiguration (WAN,LAN,DMZ,WLAN) ist definitiv nur "Automatic-NAT" eingestellt, es ist ausser dem "WAN-Dynamic-Gateway" kein weiteres Gateway definiert.Den Rest übernehmen die Rules der FW und das funktioniert so, wie ich mir das vorstelle.
Da aber der "Weg nach Rom" wohl sehr unterschiedlich ausfallen kann, bin ich gerne bereit noch dazu zu lernen.
Das Thema ist doch durch: Der Client kennt die Rückroute nicht. Die Lösung wurde aufgezeigt.
...hier wäre aber denn doch noch Klärungsbedarf oder geben wir @aqui nun doch Recht ?Ich muß hier @tikayevent Recht geben...
Ich habe NIEMALS nur eine Regel für Antwortpakete geschrieben, diese werden automatisch durchgeschoben.
..ist bei mir genau so und das funktioniert.So eine pfSense ist eben keine FritzBox und nicht wirklich für Otto Normalverbraucher gedacht, auch wenn die sie immer häufiger in Gebrauch haben.....
Gruß orcape
Zitat von @orcape:
So eine pfSense ist eben keine FritzBox und nicht wirklich für Otto Normalverbraucher gedacht, auch wenn die sie immer
häufiger in Gebrauch haben.....
Gruß orcape
So eine pfSense ist eben keine FritzBox und nicht wirklich für Otto Normalverbraucher gedacht, auch wenn die sie immer
häufiger in Gebrauch haben.....
Gruß orcape
Bin halt auch noch am lernen. Aber wird schon
Ist halt trotzdem gegenüber der FritzBox ein mächtigeres Werkzeug!
Und dank eurer Hilfe beseitige ich hoffentlich die letzten Probleme auch noch
Zitat von @orcape:
In meiner pfSense-Konfiguration (WAN,LAN,DMZ,WLAN) ist definitiv nur "Automatic-NAT" eingestellt, es ist ausser dem
"WAN-Dynamic-Gateway" kein weiteres Gateway definiert.
Den Rest übernehmen die Rules der FW und das funktioniert so, wie ich mir das vorstelle.
Da aber der "Weg nach Rom" wohl sehr unterschiedlich ausfallen kann, bin ich gerne bereit noch dazu zu lernen.
In meiner pfSense-Konfiguration (WAN,LAN,DMZ,WLAN) ist definitiv nur "Automatic-NAT" eingestellt, es ist ausser dem
"WAN-Dynamic-Gateway" kein weiteres Gateway definiert.
Den Rest übernehmen die Rules der FW und das funktioniert so, wie ich mir das vorstelle.
Da aber der "Weg nach Rom" wohl sehr unterschiedlich ausfallen kann, bin ich gerne bereit noch dazu zu lernen.
Dann entferne mal bei einem Host in der DMZ das Standardgateway...
Zitat von @orcape:
> Das Thema ist doch durch: Der Client kennt die Rückroute nicht. Die Lösung wurde aufgezeigt.
...hier wäre aber denn doch noch Klärungsbedarf oder geben wir @aqui nun doch Recht ?
> Das Thema ist doch durch: Der Client kennt die Rückroute nicht. Die Lösung wurde aufgezeigt.
...hier wäre aber denn doch noch Klärungsbedarf oder geben wir @aqui nun doch Recht ?
Nochmal: Im vorliegenden Fall kennt der Host im Gastnetz die Route zurück ins interne Netz nicht. Oder anders ausgedrückt: Der Empfänger kann dem Absender nicht antworten, weil er den Weg zur Absenderadresse nicht kennt. Was hat das mit dem Firewallregelwerk der pfSense zu tun? Nichts! Der Host im Gastnetz schickt überhaupt keine Antwortpakete über die pfSense zurück zum Host im internen LAN. Da kann das Firewallregelwerk auf der pfSense 100mal stimmen - spielt überhaupt keine Rolle. Vermische doch nicht immer gedanklich die Wegefindung der beteiligten Hosts mit dem Firewallregelwerk des zu querenden Routers - das eine hat mit dem anderen nichts zu tun.
Gruß
sk
Thema Rückroute....
Ihr habt Recht und man kann Entwarnung geben. Ein Testaufbau hat das eindeutig gezeigt das Antwortpakete ohne explizite Regel bei der pfSense (und vermutlich auch allen anderen FWs) durchkommen.
Sorry for the confusion...
Ihr habt Recht und man kann Entwarnung geben. Ein Testaufbau hat das eindeutig gezeigt das Antwortpakete ohne explizite Regel bei der pfSense (und vermutlich auch allen anderen FWs) durchkommen.
Sorry for the confusion...
Zitat von @sk:
Ja ist ganz einfach. Da Du initial ja nur von LAN nach Gast-Netz zugreifen möchtest, maskierst Du einfach die Source-IP des
ausgehenden Traffics auf die des outgoing Interfaces. Also stink normales Source-NAT/Masquerading. Ich hab jetzt schon einige
Jahre nicht mehr mit pfSense gearbeitet, aber meiner Erinnerung nach musst Du hierfür "Advanced Outbound NAT"
aktivieren und konfigurieren. Beachte dabei die Konsequenzen für den LAN-to-WAN-Traffic!
Siehe https://doc.pfsense.org/index.php/Outbound_NAT
Gruß
sk
Ja ist ganz einfach. Da Du initial ja nur von LAN nach Gast-Netz zugreifen möchtest, maskierst Du einfach die Source-IP des
ausgehenden Traffics auf die des outgoing Interfaces. Also stink normales Source-NAT/Masquerading. Ich hab jetzt schon einige
Jahre nicht mehr mit pfSense gearbeitet, aber meiner Erinnerung nach musst Du hierfür "Advanced Outbound NAT"
aktivieren und konfigurieren. Beachte dabei die Konsequenzen für den LAN-to-WAN-Traffic!
Siehe https://doc.pfsense.org/index.php/Outbound_NAT
Gruß
sk
Sorry für die späte Antwort. Aber habe erst jetzt Zeit zum testen gefunden.
Aber die Lösung von ..sk.. ist genau der richtige Weg!
Danke dir!
Gern geschehen!
Danke für die Rückmeldung.
Gruß
sk
Danke für die Rückmeldung.
Gruß
sk
