badger
Goto Top

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:
de0e7afd0d3d9b2449b82a40ee704cb3

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

Content-Key: 258365

Url: https://administrator.de/contentid/258365

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: tikayevent
tikayevent 23.12.2014 um 16:19:05 Uhr
Goto Top
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.
Mitglied: aqui
aqui 23.12.2014 um 16:28:58 Uhr
Goto Top
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:
  • 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 !
Das sollte dein "Problem" sehr schnell lösen !!
Mitglied: Badger
Badger 23.12.2014 um 16:46:09 Uhr
Goto Top
Danke für eure Antwort.

Ich habe jetzt zum Testen eine Regel erstellt, die alles erlaubt:
299ee99cc0006463ca5cf909601f7750

Habe dies auch in den Logs kontrolliert:
b139741488c7841601df5e876db47f9f

Windows-Firewall ist immer noch deaktiviert. Und dennoch funktioniert es nicht.

Kann hier wirklich was an den Regeln falsch sein?

Danke
Mitglied: aqui
aqui 23.12.2014 um 17:06:29 Uhr
Goto Top
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 face-wink
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 !
Mitglied: Badger
Badger 23.12.2014 um 17:17:57 Uhr
Goto Top
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
Mitglied: BirdyB
BirdyB 23.12.2014 aktualisiert um 17:36:54 Uhr
Goto Top
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...)
Mitglied: tikayevent
tikayevent 23.12.2014 um 20:52:08 Uhr
Goto Top
@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.
Mitglied: aqui
aqui 24.12.2014 um 12:02:17 Uhr
Goto Top
@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 face-wink
Mitglied: Philipp711
Philipp711 24.12.2014 um 14:57:50 Uhr
Goto Top
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 face-wink

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?
Mitglied: aqui
aqui 24.12.2014 um 15:27:35 Uhr
Goto Top
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 face-wink
Mitglied: sk
sk 24.12.2014 um 15:55:18 Uhr
Goto Top
Du liegst hier definitiv falsch, aqui. Deine Ausführungen sind nur bei statischen Paketfiltern zutreffend. PfSense hat aber eine SPI-Firewall.

Gruß
sk
Mitglied: sk
Lösung sk 24.12.2014, aktualisiert am 25.01.2015 um 15:33:49 Uhr
Goto Top
Zitat 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?

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
Mitglied: tikayevent
tikayevent 24.12.2014 um 16:56:53 Uhr
Goto Top
@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.
Mitglied: orcape
orcape 24.12.2014 aktualisiert um 17:18:04 Uhr
Goto Top
Hi Badger,
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 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
Mitglied: aqui
aqui 25.12.2014 aktualisiert um 13:01:58 Uhr
Goto Top
OK, ich gebe mich geschlagen bei der Übermacht, werde das aber trotzdem nochmal zur Sicherheit (und zur persönlichen Klarstellung) ausprobieren face-wink
Mitglied: orcape
orcape 25.12.2014 um 13:10:24 Uhr
Goto Top
Hi Aqui,
....ausprobierenface-wink
...habe ich auch schon getan...
Trifft wohl zu, was da gesprochen wurde.....face-wink
Ist Weihnachten, da kann man zu Gunsten des Gänsebratens schon mal etwas daneben liegen...face-wink
Gruß & schöne Feiertage...orcape
Mitglied: aqui
aqui 25.12.2014 um 13:14:16 Uhr
Goto Top
Vertrauen ist gut...Kontrolle ist besser face-wink
Mitglied: Badger
Badger 28.12.2014 aktualisiert um 19:13:05 Uhr
Goto Top
Nach den Feiertagen melde ich mich auch wieder zurück face-smile

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.
Mitglied: orcape
orcape 28.12.2014 um 20:05:44 Uhr
Goto Top
Hi,
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?
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
Mitglied: sk
sk 28.12.2014 um 20:48:29 Uhr
Goto Top
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
Mitglied: orcape
orcape 29.12.2014 um 00:17:07 Uhr
Goto Top
Hi,
@..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.....face-wink
Gruß orcape
Mitglied: Badger
Badger 29.12.2014 aktualisiert um 00:32:38 Uhr
Goto Top
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.....face-wink
Gruß orcape

Bin halt auch noch am lernen. Aber wird schon face-smile
Ist halt trotzdem gegenüber der FritzBox ein mächtigeres Werkzeug!
Und dank eurer Hilfe beseitige ich hoffentlich die letzten Probleme auch noch face-smile
Mitglied: sk
sk 29.12.2014 aktualisiert um 01:27:51 Uhr
Goto Top
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.

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 ?

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


Gruß
sk
Mitglied: aqui
aqui 01.01.2015, aktualisiert am 26.01.2015 um 11:26:58 Uhr
Goto Top
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... face-wink
Mitglied: Badger
Badger 25.01.2015 um 15:34:54 Uhr
Goto Top
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

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!
Mitglied: sk
sk 25.01.2015 um 23:05:37 Uhr
Goto Top
Gern geschehen!
Danke für die Rückmeldung.

Gruß
sk