08.02.2017

11635

PfSense zwei Netze verbinden

Hallo zusammen,

ich habe hier ein Problem mit meiner pfSense. Ich möchte, dass das LAN und das RADIUS Netz ohne Probleme miteinander kommunizieren können. Zurzeit ist jedoch nur die Kommunikation in eine Richtung möglich (RADIUS ins LAN).

Ist ja eigentlich ein einfacher Aufbau aber irgendwas scheine ich zu übersehen. Wenn mehr Infos benötigt werden einfach Bescheid geben

Der Netzaufbau sieht wie folgt aus:

Firewall Regeln für das LAN Interface

Firewall Regeln für das RADIUS Interface:

Bin Dankbar für alle Tipps und/oder Lösungen

MfG

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 328798

Url: https://administrator.de/forum/pfsense-zwei-netze-verbinden-328798.html

Ausgedruckt am: 15.04.2025 um 23:04 Uhr

26 Kommentare

Neuester Kommentar

Hallo,

zeig mal bitte die Interface settings her.

Gruß

Warum ist auf dem 2. Screenshot als IPv6 Interface WAN ausgewählt? Ist das beim LAN Interface Tab?

Im Grunde sind es 3 lächerliche Punkte:

Darauf achten das kein Interface NAT (IP Adress Translation) aktiviert hat. Beide Ports sollten also reine LAN Ports sein.
Firewall Regel auf LAN1: ALLOW Source: LAN1_network, Port: any - Destination: Any, Port: Any
Firewall Regel auf LAN2: ALLOW Source: LAN2_network, Port: any - Destination: Any, Port: Any

Fertisch !
Das wären die einfachsten Regeln mit denen es sofort zum Fliegen kommt.

Gute Frage, ich hab die nicht von Grund auf konfiguriert und habs jetzt raus genommen

Also unter Firewall/NAT darf nirgends was eingetragen sein + die beiden Regeln die ich schon habe?

Zitat von @raffzwo:
Also unter Firewall/NAT darf nirgends was eingetragen sein

Wenn du es nicht explizit brauchst, dann nein.

Zitat von @raffzwo:
die beiden Regeln die ich schon habe?

IPv4 LAN net * * * *
IPv4 Radius net * * * *

So sollen deine Regeln ausschauen.

Gruß

Habe ich gemacht, aufrufen der weboberfläche der AP's oder das pingen eines notebooks im RADIUS netz funktionieren trotzdem nicht

der ping auf das interface des RADIUS netz läuft ohne probleme durch nur weiter gehts halt nicht

Ist das Windows ??

Richtige IP Adressierung hast du mit ipconfig geprüft ? Gateway pfsense etc. ?
Pingen ist ab Win 7 per Default deaktiviert, musst du also er aktivieren in der lokalen Firewall:

https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen

Die Win Firewall blockiert per default ALLES was aus Fremden IP Netzen kommt und lässt nur lokalen Traffic zu. Auch hier musst du die lokale FW anpassen das sie dann aus fremden IPs für deine Anwendung zulässt !!

Ansonsten IMMER ins Firewall Log der pfsense sehen !!
Dort steht explizit was geblockt wird und nicht durchgeht ! Ggf. vorher löschen und die Reihenfolge im Setup anpassen (aktuellster Eintrag oben) um die Übersichtlichkeit zu erhöhen.
Die Ping über das Diagnostic Menü der pfSense prüft ebenfals nochmal die Connectivity von der FW Seite !!
Hier immer auf die Absender IP achten und entsprechend richtig setzen !

Okay mit den settings nochmal getestet:

NOTEBOOK RADIUS:

PC LAN:

So funktioniert der ping von rechner zu rechner das ist wunderbar.. hatte wohl vergessen die FW vom notebook mal auszuschalten mein fehler tut mir leid

dennoch habe ich das problem dass meine AP's nicht erreichbar sind und da ich faul bin und das gerne von meinem platz aus managen möchte würde ich gern wissen ob ihr dafür einen lösungsansatz für mich habt

naja, dann verrate uns welche APs das sind und wie du die konfiguriert hast.
Wenn die eine passende IP und ein passendes GW haben, dann muss das funktionieren.

Gurß

hatte wohl vergessen die FW vom notebook mal auszuschalten mein fehler tut mir leid

Ist leider unser täglich Brot hier im Forum...wir sind da abgehärtet

habe ich das problem dass meine AP's nicht erreichbar sind

Wie meinst du das ??

Hast du APs in beiden Segmenten ?
Die APs in einem Segment erreichen den Radius Server im anderen nicht ?
oder...oder ??

Das ist unklar.
Wenn es mit deinem Test PC jetzt geht kann es nur noch an der AP Adressierung liegen. Mit 98%ider Wahrscheinlichkeit hast du dort keins oder ein falsches Gateway definiert.
APs funktionieren IP seitig nicht anders als deine Ping Test PCs !!

Alle AP's befinden sich im RADIUS netz und sind auch von dort erreichbar ich möchte nur dass sie vom LAN aus konfigurierbar sind
IPs:
3x D-LINK DAP-1353 1x ALLNET ALL02850N
192.168.20.50 - 53 /24

bei allen ist 192.168.20.1 als GW eingetragen

Und wenn du auf der PfSense unter Diagnostics - Ping als Interface Radius auswählst und einen Ping auf die Geräte absetzt, klappts dann?

Ansonsten Diagnostic - Capture Packet, Filter auf die Destination IP des AP und lasse einen Ping von einem Client im LAN los auf den AP, dann siehst du ja was passiert.

Gruß

ich möchte nur dass sie vom LAN aus konfigurierbar sind

Das ist problemlos möglich. Es funktioniert ja auch schon mit deinen beiden Test PCs in den 2 IP Segmenten.
Wenn die sich pingen können klappt das ja generell.
Da du ja auch Scheunentor regeln auf der Firewall definiert hast also any zu any auf beiden Interfaces ist da dann so oder so alles offen.
Das wäre sehr verwunderlich wenn das mit den APs nicht möglich wäre. Würde dann eher für einen falsche Subnetzmaske oder sowas sprechen.

Teste mal einen Ping von der FW GUI aus mit dem .20.1 Interface als Absender, sproch also ob die FW die APs direkt selber auf dem eigenen Interface pingen kann.
Was noch hilfreich wäre mal unter Diagnostics -> Packet Capture einen Capture zu machen wenn du von den APs (am besten) oder anderem Endgrät im .20.0er netz mal das FW Interface pingst.

Zitat von @michi1983:
Und wenn du auf der PfSense unter Diagnostics - Ping als Interface Radius auswählst und einen Ping auf die Geräte absetzt, klappts dann?

Klappt

Zitat von @michi1983:
Ansonsten Diagnostic - Capture Packet, Filter auf die Destination IP des AP und lasse einen Ping von einem Client im LAN los auf den AP, dann siehst du ja was passiert.

Vielleicht stellst du das Level of detail mal etwas höher damit man auch was sieht

13:35:10.683199 8c:89:a5:b9:a0:c0 > 68:05:ca:1d:58:97, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 17369, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.68 > 192.168.20.50: ICMP echo request, id 1, seq 576, length 40
13:35:15.290768 8c:89:a5:b9:a0:c0 > 68:05:ca:1d:58:97, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 17393, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.68 > 192.168.20.50: ICMP echo request, id 1, seq 577, length 40
13:35:20.287361 8c:89:a5:b9:a0:c0 > 68:05:ca:1d:58:97, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 17407, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.68 > 192.168.20.50: ICMP echo request, id 1, seq 578, length 40
13:35:25.280389 8c:89:a5:b9:a0:c0 > 68:05:ca:1d:58:97, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 17431, offset 0, flags [none], proto ICMP (1), length 60)
192.168.0.68 > 192.168.20.50: ICMP echo request, id 1, seq 579, length 40

Mmmhhh zeigt ja das die Ping ankommen an der FW.
Spannend wäre jetzt mal ein Capture auf dem Radius Segment um zu sehen WAS da vom angepingten Endgerät zurückkommt ?? Bzw. ob die Pings dort überhaupt ankommen !

Was hier hilft:

Auf einem deiner TestPC mal Wireshark installiern und laufen lassen mit einer .20.x IP
Dann diesen Wireshark PC mal von einem Client im .0.0er Netz anpingen und checken ob dort überhaupt Pings ankommen

Sollte das klappen, dann liegt der Fehler ganz klar am AP selber, denn dann kann der nicht mit geroutetem Traffic umgehen. Was aber sehr sehr ungewöhnlich wäre.
Man kann dann nur vermuten das er seine Gateway IP nicht richtig registriert oder aktiviert hat und Pakete aus anderen netzen ignoriert werden.
Ggf. hilft da mal ein Reboot oder sowas.

Hast du auf den APs und auf der PfSense jeweils die aktuellste Firmware geflashed? (vorher die config sichern überall).
Und dann würde ich mal diese Geräte alle neu starten, ev. hängt irgendwo noch eine alte Einstellung.

EDIT:
@aqui, müsste da oben beim trace nicht ein echo reply mit dabei sein?

müsste da oben beim trace nicht ein echo reply mit dabei sein?

Meinst du Traceroute ?? Echo Reply gibts immer bei Ping. Traceroute arbeitet mit TTL Counter und Ping.

Zitat von @aqui:

müsste da oben beim trace nicht ein echo reply mit dabei sein?

Meinst du Traceroute ?? Echo Reply gibts immer bei Ping. Traceroute arbeitet mit TTL Counter und Ping.

Nein, sorry, ich meinte bei dem Capture oben den der TO geposted hat.

Zitat von @michi1983:
Hast du auf den APs und auf der PfSense jeweils die aktuellste Firmware geflashed? (vorher die config sichern überall).
Und dann würde ich mal diese Geräte alle neu starten, ev. hängt irgendwo noch eine alte Einstellung.

Mache ich jetzt mal

EDIT:

Firmware Update eines DAP-1353 von 3.15 auf 3.16 gemacht und hatte keine Auswirkung auch nach einem neustart nicht

Moin,

sicher das du da nicht irgend wo nen Dreher drin hast? Bsp Gateway vertauscht oder sowas?

Gruß Spirit

Kann eigentlich wirklich nur noch sowas sein.
Ich hab das eben mal nachgebaut hier im Labor auf einer pfSense 2.3.2 auf einem APU2 Board.
Windows Rechner und Linux als Client auf der einen Seite (LAN Port) und einen Cisco AP 1100, einen TP-Link und einen Apple AP auf der anderen Seite (OPT1 Port).
Cisco hat ne statische IP die anderen APs beziehen eine dynamische mit DHCP von der pfSense.
Funktioniert alles auf Anhieb und fehlerlos. Sowohl Ping als auch GUI Zugriff auf die APs über HTTP und HTTPS.

Da musst irgendwas falsch konfiguriert oder kabelseitig falsch gesteckt sein...was anderes bleibt nicht mehr.

Frage Netzwerke LAN, WAN, Wireless

Mehr von raffzwo

Gebäudeverkabelung 10Gigabit LWLraffzwo - 35 Kommentare

Heiß diskutiert