9
Whatsapp hinter pfsense direkt geht, hinter weiterer NAT (Router) nicht
Hallo zusammen, ich habe ein Problem mit pfSense und Android-Smartphones mit Whatsapp bei Double-NAT
Hallo zusammen,
ich habe folgendes Problem:
Ich habe einen PC mit pfSense, welcher an WAN über eine Fritzbox ins Internet geht. Wenn ich direkt an den LAN-Anschluss einen Access Point hänge, funktioniert Whatsapp an einem Android-Gerät wunderbar. Sobald ich allerdings einen weiteren Router dazwischenschalte (WAN-Anschluss an pfSense, IP wird über DHCP von pfSense gezogen, eigener DHCP-Server verteilt IP's in einem anderem Subnetz) funktioniert Whatsapp nicht mehr. Der sonstige Internetzugriff scheint zu funktionieren, wobei aber einige andere Apps, z.B. das PlayStore/Android Market-Update auch nicht funktioniert. In pfSense habe ich schon eine Regel am LAN-Interface erstellt, welche sämtlichen eingehenden Traffic vom internen Subnetz des Routers hinter dem pfSense-LAN erlaubt, trotzdem geht es nicht und im Firewall-Log tauchen weiterhin Pakete von IP's aus dem internen Subnetz auf, die geblockt werden.
In Kurzform:
Internet---Fritzbox--pfSense--LAN mit Access Point -> Geht
Internet---Fritzbox--pfSense--LAN--Router mit Wlan -> Geht nicht
Muss ich irgendwo in den NAT-Einstellungen etwas anpassen?
Vielleicht findet sich ja jemand, der sich damit auskennt...
Gruß und danke schonmal,
Eagle2
Hallo zusammen,
ich habe folgendes Problem:
Ich habe einen PC mit pfSense, welcher an WAN über eine Fritzbox ins Internet geht. Wenn ich direkt an den LAN-Anschluss einen Access Point hänge, funktioniert Whatsapp an einem Android-Gerät wunderbar. Sobald ich allerdings einen weiteren Router dazwischenschalte (WAN-Anschluss an pfSense, IP wird über DHCP von pfSense gezogen, eigener DHCP-Server verteilt IP's in einem anderem Subnetz) funktioniert Whatsapp nicht mehr. Der sonstige Internetzugriff scheint zu funktionieren, wobei aber einige andere Apps, z.B. das PlayStore/Android Market-Update auch nicht funktioniert. In pfSense habe ich schon eine Regel am LAN-Interface erstellt, welche sämtlichen eingehenden Traffic vom internen Subnetz des Routers hinter dem pfSense-LAN erlaubt, trotzdem geht es nicht und im Firewall-Log tauchen weiterhin Pakete von IP's aus dem internen Subnetz auf, die geblockt werden.
In Kurzform:
Internet---Fritzbox--pfSense--LAN mit Access Point -> Geht
Internet---Fritzbox--pfSense--LAN--Router mit Wlan -> Geht nicht
Muss ich irgendwo in den NAT-Einstellungen etwas anpassen?
Vielleicht findet sich ja jemand, der sich damit auskennt...
Gruß und danke schonmal,
Eagle2
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: 197685
Url: https://administrator.de/contentid/197685
Ausgedruckt am: 12.11.2024 um 22:11 Uhr
9 Kommentare
Neuester Kommentar
Die Regel auf der pfSense ist überflüssig und auch kontraproduktiv. Bringt also nix. Der Router macht ja NAT und damit tauchen alle Datenpakete aus dem lokalen LAN Netz des Routers mit seiner WAN IP am pfSense LAN auf, das ja eine gültige IP aus dem LAN Segment der pfSense hat. Die FW "sieht" also folglicherweise das IP Netz hinter dem Router gar nicht da die ursprüngliche Absender IP per NAT umgesetzt wird auf die WAN IP.
Folglich kann die Regel dann auch nix bringen...
Eigentlich ist das Verhalten ungewöhnlich, denn da am pfSense LAN Port alles erlaubt ist muss das gehen. Zeigt ja auch das Szenario wo der Client direkt am LAN Port angeschlossen ist per AP.
Ungewöhnlich..... ggf. solltest du es mal mit einer statischen IP versuchen. Anpassen muss man nix. Ggf. macht der AP im Router Zicken.
MTU Problem kann es auch nicht sein, denn du hast nur Ethernet dazwischen. MTU Probleme treten nur bei PPPoE auf.
Ansonsten Wireshark hernehmen oder die Trace Option in der pfSense und mal sehen was da abläuft bzw. Pakete mal genau vergleichen mit einem Whatsapp Zugriff ohne Router.
Ggf. auch mal die Firewall Logs querchecken..
Folglich kann die Regel dann auch nix bringen...
Eigentlich ist das Verhalten ungewöhnlich, denn da am pfSense LAN Port alles erlaubt ist muss das gehen. Zeigt ja auch das Szenario wo der Client direkt am LAN Port angeschlossen ist per AP.
Ungewöhnlich..... ggf. solltest du es mal mit einer statischen IP versuchen. Anpassen muss man nix. Ggf. macht der AP im Router Zicken.
MTU Problem kann es auch nicht sein, denn du hast nur Ethernet dazwischen. MTU Probleme treten nur bei PPPoE auf.
Ansonsten Wireshark hernehmen oder die Trace Option in der pfSense und mal sehen was da abläuft bzw. Pakete mal genau vergleichen mit einem Whatsapp Zugriff ohne Router.
Ggf. auch mal die Firewall Logs querchecken..
Ich hab gerade mal mit einem lokalem Testsystem geprüft: Auch hier kommt Whatsapp direkt hinter pfSense problemlos durch (Was ja auch zwei Router sind, also Fritzbox und dann pfSense), wenn aber zwischen Gerät und pfSense noch ein Router hängt geht es nicht mehr. Das mit der Regel dachte ich mir schon, das komische ist ja, dass in pfSense im System Log->Firewall Einträge mit der IP des internen Subnetzes des Routers auftauchen.
Wireshark ist eine gute Idee, das mach ich jetzt mal ;)
Wireshark ist eine gute Idee, das mach ich jetzt mal ;)
Hi,
Das funktioniert definitive so nicht. Vielleicht auf der pfSense mal mit statischen IP's versuchen.
Gruß orcape
Was ja auch zwei Router sind, also Fritzbox und dann pfSense
Also die Fritzbox dann als einfaches Modem betreiben.(WAN-Anschluss an pfSense, IP wird über DHCP von pfSense gezogen, eigener DHCP-Server verteilt IP's in einem anderem
Subnetz)
...und wieso auf der pfSense DHCP und am weiteren Router auch noch DHCP...Subnetz)
Das funktioniert definitive so nicht. Vielleicht auf der pfSense mal mit statischen IP's versuchen.
Gruß orcape
.@Eagle2
Denk dran wenn du die FB davor hast das du die default Filterregel mit den RFC 1918 IPs (Private Netze) entfernst (Haken davor entfernen !)
Das Transfernetz FB LAN zu pfSense WAN Port ist ja ein RFC 1918 Netz (FB Default 192.168.178.0 /24) und das darf natürlich nicht gefiltert werden.
Ist aber eigentlich nicht das Urproblem.
Checke auch nochmal ob der 3te Router einen korrekten DNS Eintrag hat und sofern er selber als DNS rennt ob die Proxyfunktion läuft (Client mit nslookup Kommando) Nur um DNS problematiken auszuschliessen.
Du solltest sonst wirklich einen Wireshark dazwischenschleifen und beide Kommunikatione mal mitsniffern und checken wo er hängenbleibt.
.@Orcape
Doch, das funktioniert so mit DHCP. Der WAN Port des 3ten Routers ist als DHCP Client ausgeführt und steckt im LAN der pfSense. Hier bekommt er vom pfSense DHCP Server am FW LAN Port eine gültige IP, Gateway und DNS Server (hoffentlich).
Der 3te Router selber ist dann in seinem eigenen LAN Segment wieder DHCP Server und vergibt dort IPs an Endgeräte.
Das sollte also sauber klappen sofern alle IP Netz IPs einzigartig sind.
Denk dran wenn du die FB davor hast das du die default Filterregel mit den RFC 1918 IPs (Private Netze) entfernst (Haken davor entfernen !)
Das Transfernetz FB LAN zu pfSense WAN Port ist ja ein RFC 1918 Netz (FB Default 192.168.178.0 /24) und das darf natürlich nicht gefiltert werden.
Ist aber eigentlich nicht das Urproblem.
Checke auch nochmal ob der 3te Router einen korrekten DNS Eintrag hat und sofern er selber als DNS rennt ob die Proxyfunktion läuft (Client mit nslookup Kommando) Nur um DNS problematiken auszuschliessen.
Du solltest sonst wirklich einen Wireshark dazwischenschleifen und beide Kommunikatione mal mitsniffern und checken wo er hängenbleibt.
.@Orcape
Doch, das funktioniert so mit DHCP. Der WAN Port des 3ten Routers ist als DHCP Client ausgeführt und steckt im LAN der pfSense. Hier bekommt er vom pfSense DHCP Server am FW LAN Port eine gültige IP, Gateway und DNS Server (hoffentlich).
Der 3te Router selber ist dann in seinem eigenen LAN Segment wieder DHCP Server und vergibt dort IPs an Endgeräte.
Das sollte also sauber klappen sofern alle IP Netz IPs einzigartig sind.
@orcape: Ich habe die Konstellation wie Aqui sie beschrieben hat, das funktioniert schon. Alle IP-Netze sind einzigartig.
@aqui: Möglicherweise hängt das tatsächlich mit DNS zusammen. Der Router ist WAN-seitig mit statischer IP konfiguriert und hat als DNS-Eintrag die pfSense-IP. Im Webinterface ist ein zusätzlicher Menüpunkt für DNS, der allerdings nur ein separater Menüpunkt für den DNS-Server, der für den WAN-Port eingestellt ist. Die Clients erhalten dementsprechend als DNS-Server direkt die IP von pfSense. Komischerweise läuft aber trotzdem ein DNS-Forwarder, denn wenn ich in nslookup den Router als Server angebe, funktioniert die Namensauflösung. Ich befürchte ja, dass mit dem Router einfach irgendwas nicht stimmt. Wenn es mit einem anderen Router geht, werde ich dann diesen einfach austauschen und dann hat sich die Sache.
An welcher Stelle/von wo aus würdest du denn mit Wireshark mitschneiden?
@aqui: Möglicherweise hängt das tatsächlich mit DNS zusammen. Der Router ist WAN-seitig mit statischer IP konfiguriert und hat als DNS-Eintrag die pfSense-IP. Im Webinterface ist ein zusätzlicher Menüpunkt für DNS, der allerdings nur ein separater Menüpunkt für den DNS-Server, der für den WAN-Port eingestellt ist. Die Clients erhalten dementsprechend als DNS-Server direkt die IP von pfSense. Komischerweise läuft aber trotzdem ein DNS-Forwarder, denn wenn ich in nslookup den Router als Server angebe, funktioniert die Namensauflösung. Ich befürchte ja, dass mit dem Router einfach irgendwas nicht stimmt. Wenn es mit einem anderen Router geht, werde ich dann diesen einfach austauschen und dann hat sich die Sache.
An welcher Stelle/von wo aus würdest du denn mit Wireshark mitschneiden?
Das ist vermutlich ein DNS Problem. Die Clients hinter dem 3ten Router können ja den 3ten Router als DNS haben genauso wie das pfSense LAN IP Interface. Beides sollte klappen, denn beide arbeiten als DNS Proxy.
Ggf. kannst du das am 3ten Router alles mal statisch nachtragen und testen ob das ein Unterschied macht.
Durch 3 DNS Proxies ist natürlch ne Herausforderung sollte aber klappen
Du solltest immer am Client sniffern. Also einmal zwischen Client und FW LAN Interface wo es klappt.
Dann mit dem 3ten Router dazwischen und wieder zw. Client und 3ten Router LAN Interface. Gleiche prozedur.
Idelaerweise nimmst du da einen Laptop mit Wireshark drauf, dann musst du nicht Frickeln mit Monitor Port usw.
Die FW hat unter Diagnostics auch einen Sniffer an Bord. Ggf. nutzt du den ist erstmal einfacher...
Ggf. kannst du das am 3ten Router alles mal statisch nachtragen und testen ob das ein Unterschied macht.
Durch 3 DNS Proxies ist natürlch ne Herausforderung sollte aber klappen
Du solltest immer am Client sniffern. Also einmal zwischen Client und FW LAN Interface wo es klappt.
Dann mit dem 3ten Router dazwischen und wieder zw. Client und 3ten Router LAN Interface. Gleiche prozedur.
Idelaerweise nimmst du da einen Laptop mit Wireshark drauf, dann musst du nicht Frickeln mit Monitor Port usw.
Die FW hat unter Diagnostics auch einen Sniffer an Bord. Ggf. nutzt du den ist erstmal einfacher...
Das Problem hat sich geklärt: Grundsätzlich ist meine Konstellation möglich, nur zeigt mein Router ein etwas merkwürdiges Verhalten, was zu obigem Problem führt.
Grundsätzlich ist meine Konstellation möglich,
welches "riesige" Netz hast Du, das 3 Router als Kaskade notwendig werden ???Testaufbau ?
Etwas kompliziert:
Fritzbox muss für T-DSL da sein, da hängen auch einige Rechner dran, weswegen direkt PPPoE nicht ginge, ohne an pfSense ein weiteres Interface hinzuzufügen, dann pfSense, das LAN-Netz von pfSense läuft über die gleiche physikalische Infrastruktur wie ein anderes Netz mit DHCP, weswegen im LAN-Netz die IP's nur statisch vergeben werden. Jetzt soll an einer Stelle ein Zugang über Wlan genutzt werden, wäre mit einem Access Point möglich, dann müssten die Nutzer aber alle statische IP-Adressen eintragen, was nicht sehr benutzerfreundlich ist. Daher der Router mit statischer IP im pfSense-LAN-Netz, der dahinter seinen eigenen DHCP macht, sodass die Nutzer nur das Wlanpasswort eingeben müssen und ins Netz kommen. Und ja, das ist glücklicherweise nur ein seeehr provisorischer und vorübergehender Aufbau...
Fritzbox muss für T-DSL da sein, da hängen auch einige Rechner dran, weswegen direkt PPPoE nicht ginge, ohne an pfSense ein weiteres Interface hinzuzufügen, dann pfSense, das LAN-Netz von pfSense läuft über die gleiche physikalische Infrastruktur wie ein anderes Netz mit DHCP, weswegen im LAN-Netz die IP's nur statisch vergeben werden. Jetzt soll an einer Stelle ein Zugang über Wlan genutzt werden, wäre mit einem Access Point möglich, dann müssten die Nutzer aber alle statische IP-Adressen eintragen, was nicht sehr benutzerfreundlich ist. Daher der Router mit statischer IP im pfSense-LAN-Netz, der dahinter seinen eigenen DHCP macht, sodass die Nutzer nur das Wlanpasswort eingeben müssen und ins Netz kommen. Und ja, das ist glücklicherweise nur ein seeehr provisorischer und vorübergehender Aufbau...
