App kommt nicht durch HAProxy
-
@alcamar
Bei dem fhem Frontend sollte wirklich nichts schief gehen. Wenn das damit nicht auf das fhem Backend weitergeleitet wird, doch aber mit demselben als Default-Backend im https-shared, würde ich vermuten, dass ein anderes Shared Frontend die Requests abfängt, weil auf die Regel zutreffend, und auf das eigene Backend weiterleitet, oder der Hostname einfach nicht zutrifft.
Letzteres hieße, dass der Client diesen Hostnamen nicht liefert. Eher glaube ich aber, das die Regel eines anderen Frontend zuvor schon greift.Du kannst ja einfach versuchen, das fhem Frontend ganz noch oben zu setzen, vor die Cams.
(Ich glaube, nun bekomme ich eine Ahnung, wofür Shared-Frontends gut sind. Danke.
)Den DNS habe ich im OpenVPN eingetragen:
Mit "DNS Default Domain" ist eine Domain gemeint, nicht eine IP. Das kann bspw. deine lokale Domain sein (meinedomain.local).
Die IP ist vermutlich dein interner DNS Server. Dann gehört die bei "DNS Server 1" rein.
Ob du da wirklich noch Public DNS Server bereitstellen solltest, würde ich in Frage stellen, jedenfalls, wenn das einer auf der pfSense selbst ist, der ja vermutlich läuft, wenn die VPN zustande kommt. Also wozu?
Du möchtest, dass die Clients über deinen lokalen DNS die Namensauflösung machen, damit sie die internen Host Overrides sehen. Die öffentlichen kennen diese nicht.Die lokalen Subnetze sollten im Resolver automatisch erlaubt werden, allerdings funktioniert das nicht immer nach meiner Erfahrung.
In den Resolver Settings gibt es einen "Access Lists" Tab. Da das OpenVPN Tunnel Netz hinzufügen.
War bei mir wohl auch nötig:
Du kannst die Funktion aber auch einfach von einem Client aus mit einem NS Lookup testen.
-
@viragomann said in App kommt nicht durch HAProxy:
Du kannst ja einfach versuchen, das fhem Frontend ganz noch oben zu setzen, vor die Cams.
Das leider auch nichts gebracht.
Danke für die Hinweise zu den Publich DNS Server, die nach genauer Überlegung wirklich überflüssig sind. Habe ich entfernt.
@viragomann said in App kommt nicht durch HAProxy:
In den Resolver Settings gibt es einen "Access Lists" Tab. Da das OpenVPN Tunnel Netz hinzufügen.
In der Liste hatte ich einen Eintrag für Wireguard, jedoch noch keins für OpenVPN. Auch das habe ich nun eingetragen.
@viragomann said in App kommt nicht durch HAProxy:
Du kannst die Funktion aber auch einfach von einem Client aus mit einem NS Lookup testen.
Ich habe mir dazu die App NS Lookup auf das Handy geladen. Egal was ich aus der Liste der eingetragen Host Overrides eingebe, lautet die Antwort "Unable to obtain answer records of <eingegebene domain> from name server 192.168.1.1", der mein lokaler DNS Server ist und neuerdings als DNS Server 1 im OpenVPN-Server eingetragen ist.
Das heisst doch, dass der lokale DNS gar nicht antwortet, oder? -
@alcamar
Ja, und es zeigt auch, dass der VPN Client den gepushten DNS Server schon mal zu verwenden versucht.Dass es nicht klappt könnte an einer fehlenden Route, an fehlenden Firewall Regeln oder an fehlenden ACL im DNS Resolver liegen.
Letzteres hast du ja erledigt, schreibst du.Die Route muss in auch an den Client gepusht werden mit einem Eintrag in "Lokal Networks". Der Eintrag als DNS Server macht das nicht.
Und eine Firewall Regel, die den Zugriff erlaubt, braucht es auch. -
@viragomann
Das sollte passen und damit bleiben die fehlende Route oder Regel.
Ich habe nun das in NAT/Port Forward eingetragen:
Und die NSLookup App zeigt jetzt mehr Leben:
"Server 192.168.178.1 returned a nonautorative response in 49 msec."-
Ist das gemachte Forwarding ok?
-
Warum meldet sich nonautorative die IP der FritzBox?
@viragomann said in App kommt nicht durch HAProxy:
Die Route muss in auch an den Client gepusht werden mit einem Eintrag in "Lokal Networks".
Das konnte ich nicht prüfen, weil ich es nicht gefunden habe. Aber möglicherweise ist es gar nicht mehr notwendig.
-
-
@alcamar leider zu früh gefreut. Nachdem ich die OpenVPN-Verbindung geschlossen und neu geöffnet habe, kommt wieder die alte Meldung:
Unable to obtain answer...
Muss für heute aufgeben :-( -
@alcamar said in App kommt nicht durch HAProxy:
Ich habe nun das in NAT/Port Forward eingetragen:
Warum? Läuft der OpenVPN Server auf der LAN IP?
Die internen Netzwerke, also auch jenes mit dem DNS Server, wenn es mehrere gibt, müssen in "IPv4 Local Network/s" in den OpenVPN Server Einstellungen eingetragen werden, um die Route auf den Client zu pushen.
Ist das gemacht?Im DNS Resolver muss bei den Interfaces auch OpenVPN ausgewählt werden, falls die Einstellung einmal verändert wurde. Standardmäßig müsste die Auswahl auf "all" stehen.
-
@viragomann
@viragomann said in App kommt nicht durch HAProxy:Warum? Läuft der OpenVPN Server auf der LAN IP?
Nein, WAN. Die Zeile hatte ich da mal stehen und war auskommentiert. Ich habe sie aktiviert, ohne den Sinn verstanden zu haben.
@viragomann said in App kommt nicht durch HAProxy:
Die internen Netzwerke, also auch jenes mit dem DNS Server, wenn es mehrere gibt, müssen in "IPv4 Local Network/s" in den OpenVPN Server Einstellungen eingetragen werden, um die Route auf den Client zu pushen.
Ich habe nur ein LAN. Dann auch ein DMZ-Netzwerk und WAN.
Ein IPv4 Local Network/s" finde ich in den OpenVPN Einstellungen nicht.
-
@alcamar
"Redirect gateway" pusht die Default Route für Upstreamtraffic auf den VPN Client. Es wird also am Client alles, was nicht im lokalen Netzwerk liegt, auf den VPN Server geroutet.
Damit sind zusätzliche Routen hinfällig.Wie sieht es mit den Regeln aus?
Die IP des DNS ist ja vermutlich die LAN IP der pfSense, oder?
Wenn ja, kannst du diese anders erreichen? Bspw. Ping oder die WebGUI.
Du solltest dieselben Dienste übrigens auch über die VPN Server IP erreichen können, 10.2.1.1. -
@viragomann said in App kommt nicht durch HAProxy:
Die IP des DNS ist ja vermutlich die LAN IP der pfSense, oder?
ja. das ist die 192.168.1.1.
Ich habe gerade in einem Thread einen Hinweis zu dem Problem gefunden, dass OpenVPN den DNS nicht findet. Bei den Advanced Client Setting von OpenVPN gibt es eine Stelle wo es heißt: Provide a DNS server list to clients. Addresses may be IPv4 or IPv6. Dort folgen dann die DNS-Server. Du hattest mir den Hinweis gegeben, dass dort die public DNS überflüssig sind. Gemäß Deinem Hinweis habe ich sie entfernt und dort nur den DNS Server 192.168.1.1 eingetragen. NS Lookup antwortet aber immer mit der DNS IP 192.168.178.1 (Fritzbox) und scheitert bei den Host Overrides Einträgen, während alle andere Adressen Antworten liefern. Also habe ich die IP 192.168.178.1 als DNS Server 2 in die OpenVPN Advances Settings eingetragen. Jetzt findet NS Lookup auch mit einer OpenVPN-Verbindung die Einträge.
Damit ist das Teilproblem gelöst, dass bei bestehender OpenVPN-Verbindung NS Lookup keine Antwort bei den eingetragegen Servern im Host Override zurückgibt.
Ich kann also nun an meinem ursprünglichen Problem arbeiten. -
@alcamar Es ist zum Verzweifeln:
- Rufe ich die HandyApp (Hausautomation) aus dem Internet auf, funktioniert der Zugriff auf die App über den HAProxy.
- Über das hauseigene WLAN geht der gleiche Zugriff.
Mit WLAN liefert mir die nslookup-App auf dem Handy:
unable to obtain answer records of ... von name server 192.168.1.1, womit mir klar ist, warum es über WLAN scheitert, aber ich verstehe nicht warum. Der Hausautomationsserver ist im DNS Resolver in Host Overrides eingetragen. Damit sollte es doch eigentlich am HAProxy sogar vorbei laufen, oder?Der oben erwähnte WLAN zugang geht über ein Access Point von unifi, der auch sauber sein IP-Adresse von der pfsense bekommt.
Nutze ich das WLAN der Fritzbox, die nicht über die pfsense geht und technisch nach meinem Verständnis zum WAN gehört, geht der Zugriff auch hier.Kurzfassung:
Handy mit Adresse aus WAN-Adressraum kann die App aufrufen. Hat das Handy eine IP-Adresse auf dem LAN geht es nicht. Hat es mit den IANA zu tun und damit mit den Firewall-Regeln?
WAN
LAN
-
@alcamar said in App kommt nicht durch HAProxy:
Stelle wo es heißt: Provide a DNS server list to clients. Addresses may be IPv4 or IPv6. Dort folgen dann die DNS-Server. Du hattest mir den Hinweis gegeben, dass dort die public DNS überflüssig sind. Gemäß Deinem Hinweis habe ich sie entfernt und dort nur den DNS Server 192.168.1.1 eingetragen. NS Lookup antwortet aber immer mit der DNS IP 192.168.178.1 (Fritzbox) und scheitert bei den Host Overrides Einträgen, während alle andere Adressen Antworten liefern. Also habe ich die IP 192.168.178.1 als DNS Server 2 in die OpenVPN Advances Settings eingetragen. Jetzt findet NS Lookup auch mit einer OpenVPN-Verbindung die Einträge.
Damit ist das Teilproblem gelöst, dass bei bestehender OpenVPN-Verbindung NS Lookup keine Antwort bei den eingetragegen Servern im Host Override zurückgibt.Das ist keine Lösung, wenn die Fritzbox nicht die gewünschte Override IP kennt, oder hast du die da auch eingetragen?
Der DNS1 antwortet nicht, also nimmt die App den nächsten und das ist die FB.
Mit WLAN liefert mir die nslookup-App auf dem Handy:
unable to obtain answer records of ... von name server 192.168.1.1, womit mir klar ist, warum es über WLAN scheitert, aber ich verstehe nicht warum. Der Hausautomationsserver ist im DNS Resolver in Host Overrides eingetragen. Damit sollte es doch eigentlich am HAProxy sogar vorbei laufen, oder?Ich nehme an, du erhältst dasselbe Ergebnis, wenn die eine beliebige existente Öffentliche Domain aus dem LAN abfragst?
Wenn, schau mal, ob das Interface, an dem der WLAN AP hängt, in den "Network Interfaces" im Resolver ausgewählt ist.
BTW: Die Regel am LAN mit "WAN net" als Source ist sinnlos. Am LAN dürfte kein Paket mit dieser Quelle-IP reinkommen.
Du kannst sie aufs WAN verschieben, macht aber nur Sinn, wenn der Client da eine Route für die LAN IP hat.Und die Reject-Regel für DNS wird hinter der Pass-Regel auch nie eine Paket erhalten. Aber ich vermute, die Pass möchtest du noch einschränken.
-
@viragomann said in App kommt nicht durch HAProxy:
Das ist keine Lösung, wenn die Fritzbox nicht die gewünschte Override IP kennt, oder hast du die da auch eingetragen?
In der Fritzbox habe ich kein Override eingetragen.
@viragomann said in App kommt nicht durch HAProxy:
Ich nehme an, du erhältst dasselbe Ergebnis, wenn die eine beliebige existente Öffentliche Domain aus dem LAN abfragst?
stimmt, wenn sie in den Overrides aufgeführt ist gleicher Fehler. Sonst nicht.
@viragomann said in App kommt nicht durch HAProxy:
Wenn, schau mal, ob das Interface, an dem der WLAN AP hängt, in den "Network Interfaces" im Resolver ausgewählt ist.
Der AP hängt am LAN-Interface und im Resolver habe ich mittlerweile sowohl bei Network Interfaces als auch bei den Outgoing Network Interfaces "All" ausgewählt.
-
@alcamar
Ist der AP auch tatsächlich einer, oder ist es ein Router?
Oder anders gefragt, am Handy im WLAN bekommst du eine IP aus dem LAN?Dann schau mal mit Packet Capture, ob die Anfrage am LAN der pfSense auch ankommt. Also UDP /TCP am Port 53 sniffen, während du ein nslookup machst.
-
@viragomann said in App kommt nicht durch HAProxy:
Ich nehme an, du erhältst dasselbe Ergebnis, wenn die eine beliebige existente Öffentliche Domain aus dem LAN abfragst?
das will ich präzisieren:
Wenn ich auf einem Rechner im LAN "nslookup betreffende Domain" eingebe, antwortet der 192.168.1.1 mit der ip-Adresse des betroffenen Servers. Nehme ich das Host Override des Servers raus, geht die Anfrage auch ins Internet und liefert mir die öffentliche IP-Adresse meines Anschlusses. Also für meine Begriffe funktioniert es da.Wenn ich auf dem Handy das gleiche mache (WLAN natürlich), funktioniert der Host Override nicht.
-
@viragomann said in App kommt nicht durch HAProxy:
Ist der AP auch tatsächlich einer, oder ist es ein Router?
Oder anders gefragt, am Handy im WLAN bekommst du eine IP aus dem LAN?der AP hat insgesamt 4 WLANs Netzwerke und liefert sauber pro genutzer SSID eine ip-Adresse aus dem Netzwerk in dem ich mich einwähle.
@viragomann said in App kommt nicht durch HAProxy:
Dann schau mal mit Packet Capture, ob die Anfrage am LAN der pfSense auch ankommt. Also UDP /TCP am Port 53 sniffen, während du ein nslookup machst.
Es kommt was an
-
@alcamar said in App kommt nicht durch HAProxy:
der AP hat insgesamt 4 WLANs Netzwerke und liefert sauber pro genutzer SSID eine ip-Adresse aus dem Netzwerk in dem ich mich einwähle.
Aber die sind doch nicht alle ins LAN gebrückt, oder??
Es kommt was an
Der DNS antwortet auch. Nun wäre interessant, was er antwortet. Das könntest du sehen, indem du den Detailpegel im Capture erhöhst auf high oder full.
-
@viragomann said in App kommt nicht durch HAProxy:
Aber die sind doch nicht alle ins LAN gebrückt, oder??
weiss nicht genau was Du meinst. LAN hat 192.168.1.1 und die 4 Netze die WLAN am LAN-Interface anbieten sind mit VLANs realisiert 192.168.2.1, 192.168.3.1, 192.168.4.1 und das LAN-Netz selbst hat kein separates VLAN.
@viragomann said in App kommt nicht durch HAProxy:
Der DNS antwortet auch. Nun wäre interessant, was er antwortet. Das könntest du sehen, indem du den Detailpegel im Capture erhöhst auf high oder full.
das ist in Blindenschrift geschrieben. :-)
16:57:19.832998 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64) 192.168.1.106.55048 > 192.168.1.1.53: Flags [S], cksum 0x71ff (correct), seq 2477448579, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1184870965 ecr 0,sackOK,eol], length 0 16:57:19.833078 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.1.53 > 192.168.1.106.55048: Flags [S.], cksum 0x83ea (incorrect -> 0xdd59), seq 279092199, ack 2477448580, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2474534595 ecr 1184870965], length 0 16:57:19.842884 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.106.55048 > 192.168.1.1.53: Flags [.], cksum 0x02de (correct), seq 1, ack 1, win 2058, options [nop,nop,TS val 1184870976 ecr 2474534595], length 0 16:57:19.842948 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 90) 192.168.1.106.55048 > 192.168.1.1.53: Flags [P.], cksum 0xbe81 (correct), seq 1:39, ack 1, win 2058, options [nop,nop,TS val 1184870976 ecr 2474534595], length 38 24259+ ANY? x.xxxx.xxxxxxxx.de. (36) 16:57:19.842955 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.1.53 > 192.168.1.106.55048: Flags [.], cksum 0x83e2 (incorrect -> 0x08b7), seq 1, ack 39, win 513, options [nop,nop,TS val 2474534605 ecr 1184870976], length 0 16:57:19.843015 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 90) 192.168.1.1.53 > 192.168.1.106.55048: Flags [P.], cksum 0x8408 (incorrect -> 0x3fd9), seq 1:39, ack 39, win 514, options [nop,nop,TS val 2474534605 ecr 1184870976], length 38 24259* q: ANY? x.xxxx.xxxxxxxx.de. 0/0/0 (36) 16:57:19.847471 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.106.55048 > 192.168.1.1.53: Flags [.], cksum 0x0284 (correct), seq 39, ack 39, win 2058, options [nop,nop,TS val 1184870980 ecr 2474534605], length 0 16:57:19.857987 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.106.55048 > 192.168.1.1.53: Flags [F.], cksum 0x0277 (correct), seq 39, ack 39, win 2058, options [nop,nop,TS val 1184870992 ecr 2474534605], length 0 16:57:19.858006 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.1.53 > 192.168.1.106.55048: Flags [.], cksum 0x83e2 (incorrect -> 0x0870), seq 39, ack 40, win 514, options [nop,nop,TS val 2474534620 ecr 1184870992], length 0 16:57:19.858050 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.1.53 > 192.168.1.106.55048: Flags [F.], cksum 0x83e2 (incorrect -> 0x086f), seq 39, ack 40, win 514, options [nop,nop,TS val 2474534620 ecr 1184870992], length 0 16:57:19.862280 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.106.55048 > 192.168.1.1.53: Flags [.], cksum 0x0263 (correct), seq 40, ack 40, win 2058, options [nop,nop,TS val 1184870996 ecr 2474534620], length 0Die Adresse habe ich geixt
-
@alcamar said in App kommt nicht durch HAProxy:
weiss nicht genau was Du meinst. LAN hat 192.168.1.1 und die 4 Netze die WLAN am LAN-Interface anbieten sind mit VLANs realisiert 192.168.2.1, 192.168.3.1, 192.168.4.1 und das LAN-Netz selbst hat kein separates VLAN.
Dann ist es ein WLAN-Router und hat vermutlich auch seine eigenen DNS-Server Einträge in den DHCP-Einstellungen, die er ausliefert und möglicherweise auch seine eigenen Regeln.
Die pfSense selbst sieht ja dann gar nicht die tatsächlich IP des Endgerätes. Welche IPs da dann anfragen mit .101 u. 106, musst du wissen. Mglw. ist eine davon der AP.Läuft die pfSense virtualisiert? Wenn ja, auf welcher Basis?
-
Das VPN Netz mal in die DNS Resolver Access List eintragen und schauen ob er dann antwortet.
-
@viragomann Die pfsense ist nicht virtualisiert.
Der AP bekommt eine IP von der pfsense und DHCP läuft für die VLANs auch über die pfsense. Auf dem AP habe ich DHCP ausgeschaltet. Die Firewall-Regeln funktionieren, was aber nicht heißen muss, dass der AP trotzdem ungefragt Router spielt. Dort kann ich mal nach anderen Einträgen gucken, die Routing-Funktionalitäten unterbinden. -
@nocling Ist in der Access List eingetragen. VPN ist auch nicht einmal mehr das Problem, denke ich. Vielmehr ist das Verhalten des DNS-Server komisch. Der Aufruf per WLAN-Verbindung geht nicht aus dem eigenen Netz. Damit kann ich die App (über HAProxy) nicht aufrufen. Sonst geht es aber aus dem Internet über HAProxy. Ich suche das Problem derzeit nicht mehr im HAProxy.
-
@alcamar
Verdammt, bin auf der Leitung gestanden.
Ich sehe da nur TCP Pakete in den pcaps. Damit funktioniert es meist nicht.
Normalerweise versucht der Client ein Abfrage via UDP. Grund dafür, via TCP abzufragen, kann sein, dass TCP nicht erlaubt ist.Wo das eingeschränkt wird, solltest du überprüfen. Die oben gezeigte Regel erlaubt es ja.
Also vielleicht doch ein Problem mit dem WLAN Router.Warum du den als Router betreibst, ist mir übrigens immer noch nicht klar. Vielleicht könntest du uns auch das mal erklären.
-
@viragomann said in App kommt nicht durch HAProxy:
Warum du den als Router betreibst, ist mir übrigens immer noch nicht klar. Vielleicht könntest du uns auch das mal erklären.
Nach meiner Zielvorstellung soll der AP nicht Router sein.
Ich will einen AP der mir 4 SSIDs bereitstellt: Privat, Gast, IOT, WorkDer AP ist über ein managed Switch (Zyxel1900-24E) mit dem LAN der pfsense verbunden. In der pfsense sind 3 VLANs definiert, die mit DHCP-Server eigenständige Netze bereitstellen. Im AP ist ein Netzwerk definiert. Adressbereich deckt sich mit der LAN-Adressbereich. Der AP selbst bekommt per DHCP auch eine eigene IP-Adresse (192.168.1.10). Das LAN ist aber segmentiert in die genannten VLANs, die auch so auf dem AP getagged sind. Damit sollten nach meiner Vorstellung auf dem LAN Netzwerk drei VLANs aktiv sein und so komme ich auf meine o.g. SSIDs. Die Vergabe der IPs durch die pfsense funktioniert. Die mobilen Devices kommen auch von jedem WLAN, wo sie sich einwählen, ins Internet. Also scheint alles so zu laufen wie es gedacht ist. Bis auf das geschilderte Problem. Ob der AP Router-"Ambitionen" hat, prüfe ich gerade. Der AP bekommt seine IP-Adressen für die VLANs und den DNS-Server. Die Einträge sehe ich auch auf Handys und Tablets. Der DNS läßt sich auch vom Handy anpingen. Trotzdem fehlt da noch etwas oder Deine Vermutung ist richtig, dass der AP auch Router sein will.
-
@alcamar
Naja, das kam von dir:LAN hat 192.168.1.1 und die 4 Netze die WLAN am LAN-Interface anbieten sind mit VLANs realisiert 192.168.2.1, 192.168.3.1, 192.168.4.1 und das LAN-Netz selbst hat kein separates VLAN.
Ich nehme eben an, dass das alles /24er Subnetze sind.
In den Captures sehe ich aber nur Quell-IPs aus 192.168.1.0/24, also aus dem LAN. Das lässt mich annehmen, dass der "AP" die Pakete natted, nachdem du sagst, dass sie von den Wifi Geräten initiiert wurden.
Zu den Quell-IPs, die die Captures zeigen, habe ich schon eine Frage gestellt. Blieb unbeantwortet und daher die Vermutung aufrecht.
-
@viragomann said in App kommt nicht durch HAProxy:
Ich nehme eben an, dass das alles /24er Subnetze sind.
korrekt.
@viragomann said in App kommt nicht durch HAProxy:
In den Captures sehe ich aber nur Quell-IPs aus 192.168.1.0/24, also aus dem LAN. Das lässt mich annehmen, dass der "AP" die Pakete natted, nachdem du sagst, dass sie von den Wifi Geräten initiiert wurden.
ich habe den nslookup von dem Handy in dem Netz gemacht. Die anderen WLANs sind nicht ständig in Nutzung. Kann es daran liegen?
@viragomann said in App kommt nicht durch HAProxy:
Zu den Quell-IPs, die die Captures zeigen, habe ich schon eine Frage gestellt. Blieb unbeantwortet und daher die Vermutung aufrecht.
Sorry, die 192.168.1.106 hat das Handy per DHCP bekommen. Die 192.168.1.1 ist das LAN-Netz un die IP-Adresse der pfsense
-
@alcamar said in App kommt nicht durch HAProxy:
ch habe den nslookup von dem Handy in dem Netz gemacht.
In welchem Netz?
Die anderen WLANs sind nicht ständig in Nutzung. Kann es daran liegen?
Nein.
Sorry, die 192.168.1.106 hat das Handy per DHCP bekommen
Die IP ist aus dem LAN, wie gesagt.
Möglicherweise vermischt der Switch da was.
Hast du die VLANs auch am Switch eingerichtet?
Ist normalerweise nicht erforderlich, wäre aber sauberer. Wenn dann müssen beide Ports, der zur pfSense und der zum AP, als Trunk konfiguriert sein. Also alle VLANs getaggt, keine PVID. -
@viragomann said in App kommt nicht durch HAProxy:
Hast du die VLANs auch am Switch eingerichtet?
ja, die ID ist auf pfsense, Switch und AP pro VLAN gesetzt.
@viragomann said in App kommt nicht durch HAProxy:
st normalerweise nicht erforderlich, wäre aber sauberer. Wenn dann müssen beide Ports, der zur pfSense und der zum AP, als Trunk konfiguriert sein. Also alle VLANs getaggt, keine PVID.
ist auch so. Die 3 VLANs sind tagged auf Port 1 und 6. PVID untagged.
-
@viragomann Ich habe "nur" 3 VLANs aber 4 WLAN, weil das Default-Netz praktisch das private WLAN (standard) ist. Habe einige Zeit darüber nachgedacht und kam zum Schluss, dass es so ok ist. Sonst hätte ich ein VLAN mehr und das wäre innerhalb meines 192.168.1.1 Netzes, was mir etwas mißfiel. Ist da vielleicht ein Design-Fehler?
-
@alcamar
Ich kann dem nicht ganz folgen und mir fehlen die Details dazu.
Du hast also ein WLAN ungetaggt angebunden? Das sollte kein Problem sein, kommt aber auf die Hardware an, manche haben da Eigenheiten, und ich kenne die nicht, jedenfalls nicht die Unify.Ich würde es nicht so machen. Mein AP hat auch 4 WLAN SSIDs, die liegen alle auf einem VLAN, und das Managementnetz ebenso.
-
@viragomann said in App kommt nicht durch HAProxy:
Du hast also ein WLAN ungetaggt angebunden?
ja, Ich kann das Default WLAN gar nicht taggen. Nur die verbleibenden 3 VLANs.
@viragomann said in App kommt nicht durch HAProxy:
Mein AP hat auch 4 WLAN SSIDs, die liegen alle auf einem VLAN, und das Managementnetz ebenso.
Dann ist aber der gesamte Netzverkehr auf einem VLAN und damit sichtbar unter den SSIDs sichtbar, oder? Das war mehr der Treiber für meinen Ansatz. Was aber nicht heißt, dass ich alles über Bord werfe, wenn es nicht funktioniert
-
@alcamar said in App kommt nicht durch HAProxy:
Dann ist aber der gesamte Netzverkehr auf einem VLAN und damit sichtbar unter den SSIDs sichtbar, oder?
Verstehe die Bedenken nicht. Die VLANs sind völlig voneinander getrennt. Jeder SSID ist ein VLAN zugewiesen und dem Managementnetz ebenso. Von einem VLAN ins andere geht der Weg nur über die pfSense.
Was soll da sichtbar sein?Bei mir hängt da keine Switch dazwischen. Aber wenn dieser korrekt konfiguriert ist, ändert das auch nichts.
Es macht nur keinen Sinn, die VLANs über den Switch zu führen, wenn dieser nicht noch irgendein anderes Gerät in ein VLAN mit einbinden soll. -
@viragomann said in App kommt nicht durch HAProxy:
Jeder SSID ist ein VLAN zugewiesen und dem Managementnetz ebenso.
hatte es so verstanden, dass die alle auf einem VLAN sind und nicht alle jeweils auf einen.
@viragomann said in App kommt nicht durch HAProxy:
Bei mir hängt da keine Switch dazwischen.
Du gehst mit dem AP direkt in die pfsense und segmentiert nur auf pfsense und AP? Was ist das für ein AP?
-
@alcamar said in App kommt nicht durch HAProxy:
Du gehst mit dem AP direkt in die pfsense und segmentiert nur auf pfsense und AP? Was ist das für ein AP?
Ja, natürlich. Das geht aber mit jedem AP, wie gesagt, wenn du nicht noch ein wired Gerät in ein Subnetz einbinden möchtest.
Meiner ist ein OpenWrt seit einem halben Jahr, original ein Engenius. Die Netzwerkkonfiguration war aber auch zuvor schon so.
-
@viragomann Daran hatte ich gar nicht gedacht.
Mit dem Unifi habe ich den ersten AP überhaupt. Für meine Nutzung könnte ich auch direkt in die pfsense gehen.
Am übrigen Setup ändert sich vermutlich dann wenig. Der AP erlaubt max 4 SSIDs und nur 3 kann man taggen. Damit hätte ich mein aktuelles Problem vermutlich auch dort. Trotzdem ist es vielleicht unter anderes Gesichtspunkten vorteilhaft. Spart mir zwei Ports am Switch. -
@alcamar
In der Konfiguration müsste sich gar nichts ändern. Du müsstest ja auch jetzt schon auf der pfSense die VLANs auf einem Interface definiert haben und das Parent-Interface zudem auch direkt aktiviert haben.
Wenn der Switch raus ist, ist eine Fehlerquelle weg. -
Welcher ist denn das?
Meine 3 UI APs sind untagged im Management Netz und jede der 5 SSIDs ist einem VLAN zugewiesen und geht tagged am AP raus.
Nach meinem Wissen ist die Grenze hier 8 SSIDs, was du meinst ist mit Gateway Monitoring, da kannst du in der tat nur 4 anlegen, das brauche und will ich aber nicht. -
@nocling stimmt habe ich nun auch gelesen, dass bis zu 8 möglich sind. Die bestehenden 4 empfinde ich nicht als Einschränkung. Das ist auch nicht mein Problem, fürchte ich. Vielmehr der Zugriff, der per WLAN nicht geht, sondern per Umweg über das Internet. @viragoman vermutet, dass der AP „ungefragt“ als Router fungiert. Mittlerweile deute ich allerdings die Infos zum AP so, dass er gar keine Routerfunktion hat. Dafür benötigt UniFi zusätzliche Komponenten. Also bin ich weiterhin ratlos.
-
@alcamar
Mein letzter Ansatz war, der Tatsache nachzugehen, dass in den DNS Captures nur TCP Pakete zu sehen sind. Das könnte grundsätzlich auch andere Ursachen haben.
Wenn ich eine DNS Abfrage mache und den Traffic sniffe, sehe ausschließlich UDP Paket, unabhängig davon, ob die Domain lokal oder öffentlich oder nicht existent ist. Obwohl TCP auch erlaubt wäre.Ich würde mal am Switch einen Port zu einem der VLANs untaggt hinzufügen und einen PC dranhängen und das damit testen.
-
@viragomann da mein Netzwerk vor nicht all zu langer aus einem einzigen Netz bestand, muss ich vielleicht eine doofe Frage stellen.
Ich habe auf der pfsense 3 VLANs:- Gast 192.168.2.1/24
- IOT 192.168.3.1/24
- Work 192.168.4.1/24
Der DHCP-Server ist entsprechend konfiguriert und so bekommen im jeweiligen azugehörigen WLANs die Handys und Tablets die richtigen IP-Adressen. Z.B wähle ich die SSID Gast, dann erhalte ich die IP-Adresse 192.168.2.100
Auf dem Handy erhalte ich aber automatisch weitere IP-Adressen für Router und DNS. In dem Beispiel wäre das für beides 192.168.2.1. Ist das so richtig?
Die anderen Netz verhalten sich analog. Dort sind automatisch Router und DNS im Handy 192.168.3.x oder 192.168.4.x
-
@alcamar
Ja, das scheint in Ordnung zu sein. Der DHCP verteilt die jeweilige Interface IP der pfSense als Gateway und DNS, sofern keine anderen Adressen in den Einstellungen angegeben wurden.