14
Pfsense, Zugriff von Vlan auf anderes Vlan klappt nicht
Hallo Experten,
ich versuche, bei meiner pfsense von einem VLan auf ein anderes Vlan zuzugreifen (in dem Fall mein VoIP-Station). Leider klappt das nicht. Hier meine Regeln:
Ich kann die Station problemlos anpingen. Bin ich in dem gleichen Vlan, habe ich Zugriff.
Wer kann mir da weiterhelfen?
ich versuche, bei meiner pfsense von einem VLan auf ein anderes Vlan zuzugreifen (in dem Fall mein VoIP-Station). Leider klappt das nicht. Hier meine Regeln:
Ich kann die Station problemlos anpingen. Bin ich in dem gleichen Vlan, habe ich Zugriff.
Wer kann mir da weiterhelfen?
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: 2569321527
Url: https://administrator.de/forum/pfsense-zugriff-von-vlan-auf-anderes-vlan-klappt-nicht-2569321527.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
14 Kommentare
Neuester Kommentar
Hi,
mache mal eine Regel auf dem LanProduktiv Netz:
Allow any protocol "from Admin PC" to "Phone IP" oder "VOIP-Station-IP", logging enabled.
Dann mach mal Ping und versuche zu administrieren.
Anhand der Logs kannst du dann ggf. den Fehler etwas eingrenzen.
ggf. erlaubt das Phone oder die VOIP Station nur den Zugriff aus dem internen Netz.
nur zur Info: wenn du allow any to any Regeln in beide Richtungen setzt, ist eine Firewall "etwas überflüssig".
Gruß
CH
mache mal eine Regel auf dem LanProduktiv Netz:
Allow any protocol "from Admin PC" to "Phone IP" oder "VOIP-Station-IP", logging enabled.
Dann mach mal Ping und versuche zu administrieren.
Anhand der Logs kannst du dann ggf. den Fehler etwas eingrenzen.
ggf. erlaubt das Phone oder die VOIP Station nur den Zugriff aus dem internen Netz.
nur zur Info: wenn du allow any to any Regeln in beide Richtungen setzt, ist eine Firewall "etwas überflüssig".
Gruß
CH
Hallo.
Wie sind denn die Geräte in den VLANs konfiguriert (IP / Subnetz-Maske / Gateway)?
Welche IP Adresse Bereiche sind denn gewählt?
Gibt es noch Floating Rules?
Gruß
Marc
Wie sind denn die Geräte in den VLANs konfiguriert (IP / Subnetz-Maske / Gateway)?
Welche IP Adresse Bereiche sind denn gewählt?
Gibt es noch Floating Rules?
Gruß
Marc
Zitat von @ChriBo:
nur zur Info: wenn du allow any to any Regeln in beide Richtungen setzt, ist eine Firewall "etwas überflüssig".
nur zur Info: wenn du allow any to any Regeln in beide Richtungen setzt, ist eine Firewall "etwas überflüssig".
Für den ersten Funktionstest sollte das OK sein.
Aber sobald alles läuft und Ports und IP Aliase erstellt und in Regeln verwurstet sind, sollten diese beide Regeln nicht mehr existieren.
Gruß
Marc
Hallo Zusammen,
ja, das würde ich natürlich dann eingrenzen. Aber erst einmal muss ich rausfinden, woran das liegt. Ich scheine keinen Weg zurück zu haben. Aber was muss ich dann machen?
Floating Rules sind nicht angelegt:
Hier scheint das Problem zu liegen (cannot resolve), aber warum?
ja, das würde ich natürlich dann eingrenzen. Aber erst einmal muss ich rausfinden, woran das liegt. Ich scheine keinen Weg zurück zu haben. Aber was muss ich dann machen?
Floating Rules sind nicht angelegt:
Hier scheint das Problem zu liegen (cannot resolve), aber warum?
Cannot resolve hat etwas mit DNS zu tun, ist aber hier sehr wahrscheinlich nicht die Problematik wenn du mit deinen Tests rein nur mit IP Adressen aus dem 11er und 66er Netz arbeitest und nicht mit FQDN Hostnamen.
Zum Thema richtiges DNS Settings auf der Firewall ist hier alles erklärt !
Vermutlich liegt der Fehler nicht an der Firewall selber, denn dein funktionierender Ping zwischen den VLAN zeigt das ja das alles soweit richtig ist.
An deinem Ruleset liegt es de facto auch nicht, denn du hast ja any zu any Scheunentorregeln gesetzt die alles auf machen und damit alles erlauben was IP spricht.
Du solltest sie ggf. erstmal so setzen das Source immer auf das jeweilige lokale LAN Segment gesetzt ist und dann den Rest any any.
Vermutlich liegt es, wie Kollege @Looser27 unten schon richtig sagt, schlicht und einfach an den Endgeräten und ganz sicher wenn es Winblows Rechner sind. Die lokale Winblows Firewall blockt per Default alles was nicht aus dem jeweiligen lokalen LAN kommt und muss dann entsprechend customized werden.
Ggf. solltest du dein Augenmerk also auch einmal darauf werfen ?!
Zum Thema richtiges DNS Settings auf der Firewall ist hier alles erklärt !
Vermutlich liegt der Fehler nicht an der Firewall selber, denn dein funktionierender Ping zwischen den VLAN zeigt das ja das alles soweit richtig ist.
An deinem Ruleset liegt es de facto auch nicht, denn du hast ja any zu any Scheunentorregeln gesetzt die alles auf machen und damit alles erlauben was IP spricht.
Du solltest sie ggf. erstmal so setzen das Source immer auf das jeweilige lokale LAN Segment gesetzt ist und dann den Rest any any.
Vermutlich liegt es, wie Kollege @Looser27 unten schon richtig sagt, schlicht und einfach an den Endgeräten und ganz sicher wenn es Winblows Rechner sind. Die lokale Winblows Firewall blockt per Default alles was nicht aus dem jeweiligen lokalen LAN kommt und muss dann entsprechend customized werden.
Ggf. solltest du dein Augenmerk also auch einmal darauf werfen ?!
Moin,
wenn es sich um eine Siemens Basis handelt, so muss der Zugriff aus anderen Netzen explizit in der Station erlaubt werden.
Gruß Looser
P.S.: Gilt natürlich auch für andere Hersteller, die den Zugriff aus anderen Netzen default verbieten.
wenn es sich um eine Siemens Basis handelt, so muss der Zugriff aus anderen Netzen explizit in der Station erlaubt werden.
Gruß Looser
P.S.: Gilt natürlich auch für andere Hersteller, die den Zugriff aus anderen Netzen default verbieten.
2
Wie sieht denn nun die einzelnen Geräte Konfiguriert? "Kennen" die denn beide ihre jeweiligen Gateways?
Wie sieht denn generell die Topologie aus? Sind da Switches involviert, welche eventuell ACLs definiert haben?
Nicht immer alles aus der Nase ziehen lassen, auch nicht an einem Freitag
EDIT:
Das wird wahrscheinlich der Hase im Pfeffer sein. Genauso wie die Vermutung von @aqui mit der lokalen Firewall.
Gruß
Marc
Wie sieht denn generell die Topologie aus? Sind da Switches involviert, welche eventuell ACLs definiert haben?
Nicht immer alles aus der Nase ziehen lassen, auch nicht an einem Freitag
EDIT:
Zitat von @Looser27:
wenn es sich um eine Siemens Basis handelt, so muss der Zugriff aus anderen Netzen explizit in der Station erlaubt werden.
wenn es sich um eine Siemens Basis handelt, so muss der Zugriff aus anderen Netzen explizit in der Station erlaubt werden.
Das wird wahrscheinlich der Hase im Pfeffer sein. Genauso wie die Vermutung von @aqui mit der lokalen Firewall.
Gruß
Marc
"Kennen" die denn beide ihre jeweiligen Gateways?
Wenn nicht, würde ja auch ein Ping scheitern der ja aber fehlerlos rennt wie oben beschrieben !Sind da Switches involviert, welche eventuell ACLs definiert haben?
Sollte keine Rolle spielen. Der Ping geht ja durch. 
Und bei ACLs müssten diese Switches routen (L3) was sicher beim TO nicht der Fall ist in einem L2 VLAN Umfeld wenn er zentral über die Firewall routet. Der funktionierende Ping zeigt eher auf die Endgeräte als Buhmänner...
@radiogugu: Sorry, bin totaler Anfänger!
Also, ich habe einen Switch von Mikrotik CRS326 und daran hängen zwei Mikrotik Accesspoints hAP-ac2. Ins Internet geht es problemlos und auch VoIP funktioniert (Gigaset Go Box 100).
Auf den Mikrotiks habe ich VLan konfiguriert und das scheint auch alles zu klappen. Die Mikrotiks laufen im Switch-Mode und das Routing macht die pfsense.
Bezüglich Gateways habe ich nichts speziell eingerichtet. Meiner Meinung nach sollte das doch mit den Regeln ootb laufen.
Was soll ich noch liefern? Ich schaue jetzt mal nach, ob es evtl. an der Siemens Box liegt!
Also, ich habe einen Switch von Mikrotik CRS326 und daran hängen zwei Mikrotik Accesspoints hAP-ac2. Ins Internet geht es problemlos und auch VoIP funktioniert (Gigaset Go Box 100).
Auf den Mikrotiks habe ich VLan konfiguriert und das scheint auch alles zu klappen. Die Mikrotiks laufen im Switch-Mode und das Routing macht die pfsense.
Bezüglich Gateways habe ich nichts speziell eingerichtet. Meiner Meinung nach sollte das doch mit den Regeln ootb laufen.
Was soll ich noch liefern? Ich schaue jetzt mal nach, ob es evtl. an der Siemens Box liegt!
Zitat von @aqui:
Und bei ACLs müssten diese Switches routen (L3) was sicher beim TO nicht der Fall ist in einem VLAN Umfeld wenn er über die Firewall routet.
"Kennen" die denn beide ihre jeweiligen Gateways?
Wenn nicht, würde ja auch ein Ping scheitern der ja aber fehlerlos rennt wie oben beschrieben !Sind da Switches involviert, welche eventuell ACLs definiert haben?
Sollte keine Rolle spielen. Der Ping geht ja durch. Und bei ACLs müssten diese Switches routen (L3) was sicher beim TO nicht der Fall ist in einem VLAN Umfeld wenn er über die Firewall routet. Oh weise Worte.
Werde mich ins Wochenende legen. Zu lange wach gewesen
Gruß
Marc
Die Mikrotiks laufen im Switch-Mode und das Routing macht die pfsense.
Oha...wirklich Switch Mode only ? Dann dürfen auf dem MT CRS keine VLAN IP Interfaces definiert sein !! Mit Ausnahme eines einzigen was im Management IP Netz / VLAN liegt. Ist dem so ?Hier bekommt Kollege @radiogugu dann doch wieder Recht das dann eine Skizze und die beteiligten Switches und ihre Konfig relevant werden.
Nicht das du mit dem CRS da einen paralleln Router zur FW aktiviert hast ?!
Wenn du das allerdings sicher ausschliessen kannst (Tracreroute wäre hier hilfreich !) dann zeigt der Ping das soweit alles richtig ist und es bleibt bei den Endgeräten und deren lokalen Firewalls.
Hallo Zusammen,
die Lösung ist von Looser27. Die Siemens Station war das Problem
Unter IP-Konfiguration von der Gigaset kann man "Weitere Einstellungen" aktivieren und dort unter Fernverwaltung war der Zugriff aus anderen Netzen auf Nein gestellt. Nach Umstellen auf Ja und einem Neustart hatte ich dann Zugriff und alles ist gut!
Noch eine ergänzende Frage: Es gibt da auch ein VLAN Tagging in den Optionen von der Gigaset. Was kann man denn damit machen und wäre eine Nutzung sinnvoll? Ich habe das Gerät ja in einem separaten VLan. Oder ist das nur bei Einstellung für den ISP sinnvoll?
Vielen Dank an alle und schönes Wochenende! Ich bin happy
die Lösung ist von Looser27. Die Siemens Station war das Problem
Unter IP-Konfiguration von der Gigaset kann man "Weitere Einstellungen" aktivieren und dort unter Fernverwaltung war der Zugriff aus anderen Netzen auf Nein gestellt. Nach Umstellen auf Ja und einem Neustart hatte ich dann Zugriff und alles ist gut!
Noch eine ergänzende Frage: Es gibt da auch ein VLAN Tagging in den Optionen von der Gigaset. Was kann man denn damit machen und wäre eine Nutzung sinnvoll? Ich habe das Gerät ja in einem separaten VLan. Oder ist das nur bei Einstellung für den ISP sinnvoll?
Vielen Dank an alle und schönes Wochenende! Ich bin happy
Nein, für den ISP nicht, denn VLAN Tagging ist immer Layer2 und wird bekanntlich nicht über Routing Grenzen übertragen und damit auch niemals an deinen ISP gesendet.
Aber evtl. hat es eine Relevanz für dich aber das kommt drauf an....
Die Option hat bei VoIP Endgeräte eher nichts mit dem VLAN per se zu tun, denn Endgeräte werden bekanntlich immer UNtagged angebunden.
Sie macht aber dennoch Sinn bei VoIP Geräten wenn man die Voice Daten im Netzwerk priorisieren möchte oder muss.
Hier gibt es 2 Arten der Priorisierung:
Deine Frage bezieht sich hier mehr auf den Punkt 1 also der Priorisierung mit 802.1p. Die 802.1p CoS Bits sind immer Teil eines 802.1q Headers sprich also des VLAN Headers. Das bedingt das eine Layer 2 Priorisierung der Voice Daten ein Frame VLAN Tagging des Endgerätes erzwingt um den Sprachdaten eine entsprechende Priorisierungs Information mitzugeben damit ein Switch oder anderes Endgerät diese Daten immer bevorzugt behandelt beim Weiterleiten.
Hier siehst du es auch einmal praktisch an einem Wireshark Trace eines 802.1q VLAN getaggten Paketes mit der VLAN ID 14:
0 = keine Priorisierung. Bei Sprachdaten würde man es auf 5 oder 6 setzen !
Vermutlich übersteigt aber diese Antwort schon dein Anfängerwissen so das wir es damit erstmal belassen...?!
Sollten dich weitere Details interessieren hat dieser Thread noch ein paar mehr Infos zum Thema Quality of Service für Sprachdaten.
Aber evtl. hat es eine Relevanz für dich aber das kommt drauf an....
Die Option hat bei VoIP Endgeräte eher nichts mit dem VLAN per se zu tun, denn Endgeräte werden bekanntlich immer UNtagged angebunden.
Sie macht aber dennoch Sinn bei VoIP Geräten wenn man die Voice Daten im Netzwerk priorisieren möchte oder muss.
Hier gibt es 2 Arten der Priorisierung:
Deine Frage bezieht sich hier mehr auf den Punkt 1 also der Priorisierung mit 802.1p. Die 802.1p CoS Bits sind immer Teil eines 802.1q Headers sprich also des VLAN Headers. Das bedingt das eine Layer 2 Priorisierung der Voice Daten ein Frame VLAN Tagging des Endgerätes erzwingt um den Sprachdaten eine entsprechende Priorisierungs Information mitzugeben damit ein Switch oder anderes Endgerät diese Daten immer bevorzugt behandelt beim Weiterleiten.
Hier siehst du es auch einmal praktisch an einem Wireshark Trace eines 802.1q VLAN getaggten Paketes mit der VLAN ID 14:
Vermutlich übersteigt aber diese Antwort schon dein Anfängerwissen so das wir es damit erstmal belassen...?!
Sollten dich weitere Details interessieren hat dieser Thread noch ein paar mehr Infos zum Thema Quality of Service für Sprachdaten.
Dann noch bitte als gelöst markieren
