App kommt nicht durch HAProxy
-
@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. -
@viragomann Ich habe wohl gerade die Lösung gefunden. Wenn der Server im Host Overrides steht, dann liefert das Handy bei bestehender WLAN-Verbindung die erwähnte Fehlermeldung unable to obtain answer records of ... Entferne ich den Server von den Host Oderrides geht es. Entfernen heißt wirklich komplett entfernen. In einem der Versuche davor, hatte ich einfach den Namen des Hosts in der Override Tabelle in einen nicht existenten Namen geändert. Das brachte keinen Erfolgt. Erst mit der Löschung hat es funktioniert.
Ich kann nun mit jedem WLAN die Hausautomations-App aufrufen und sie kommt über HAProxy auf den Server. Jetzt muss ich schauen, ob irgendwelche Seiteneffekte damit verbunden sind, die mir den Spass verderben.Mir war der Lösungsansatz von @JeGr eigentlich sympatisch, den Server im Host Oderrides einzutragen und damit schneller ohne HAProxy die App mit dem Server zu verbinden. Ich habe es nicht hinbekommen. Bei der ganzen Tüftlerei habe ich auch den Überblick verloren, warum bzw. unter welcher Konstellation es ursprünglich nicht ging.
Am Ende haben mich methodisch mal wieder die Anregungen von @viragomann weitergebracht. Aber auch die Bestätigung, dass bestimmte Einstellungen ok sind, bringt sehr viel, weil man dort einfach nicht unnötigt weiter forscht. Zudem habe ich die Option den AP direkt an die pfsense zu verbinden als Option in mein Repertoire aufgenommen.
Deshalb Danke! -
@alcamar
Den Host Override zu entfernen bedeutet, dass der Hostname entsprechend dem öffentlichen DNS aufgelöst wird. D.h. die Clients bekommen die WAN IP auf Anfrage und diese kontaktieren sie dann.
Und die Verbindung geht damit auch über den Proxy.Klar funktioniert das, wenn es auch von außen geht. Die Empfehlung mit den Host Overrides hatte ich auch von Anfang an in Frage gestellt, die kam auch nicht von mir.
Dennoch müsste es auch damit gehen. Aber dazu wäre Troubleshooting nötig, man müsste den Indizien, die man hat, eben nachgehen. Lohnt sich vielleicht aber nicht, wenn auf andere Weise alles funktioniert. Das musst du für dich entscheiden. -
@viragomann Ich hätte die Host Override bevorzugt, und wie Du sagst, muss die auch funktionieren. Dir Frage ist, wie viel Zeit mich das dann kostet, um am Ende funktional das gleiche Ergebnis zu haben. Es wurmt mich zwar ein wenig, aber mit dem jetzigen Ergebnis bin ich erstmal zufrieden.
-
@alcamar Hat jemand HAProxy als Reverse-Proxy auf der pfsense im Einsatz und nutzt dabei shared Frontends?
Ich bekomme leider keine stabile Konfiguration hin. Im wesentlichen nutze ich zwei Apps (IOS), die nicht mit einer HAProxy-Konfiguration laufen wollen. Enweder läuft die Hausautomations-App oder die Kamera-App.
Ein (Teil)Problem kurz umschrieben:
Im Frontend ist unter einem shared Frontend u.a. cam1 konfiguriert, die nur dann geht, wenn cam1 aus dem shared Frontend herausgenomen wird. Ich füge mal die Screenshots ein, wobei beim ersten geht es nicht und beim zweiten greift die App auf Cam1 zu.
so geht es nicht:
so geht es:
In der Konstellation wo die Kamera-App geht, verweigert die Hausautomations-App den Dienst, es sei denn ich deaktiviere Cam1. Ein sehr unschöne XOR-Beziehung zwischen den Apps.
Wenn die Kamera-App geht, wird der Zugriff auf die Hausautomation auch über Browser verweigert.Kennt jemand ein ähnliches Verhalten und weiss, was noch wie eingestellt werden muss? Oder hat jemand eine ähnliche Nutzung und skizziert kurz, was bei ihm anders ist und geht?
Aus meiner Sicht ist das Problem im HAProxy verortet und da wohl im Frontend.Die Apps gehen grundsätzlich und werden im HAProxy auch angezeigt, wenn wie mal aktiv sind.
-
@alcamar Das sind die Kombinationen, bei denen etwas geht, oder nichts.
Mit der folgenden Einstellung, geht die Hausautomations-App (fhem), aber nur, wenn ich bei Cam1 den default herausnehme. Die Kamera-App geht nicht.
So geht die Kamera-App, aber nicht die Hausautomations-App.
Im https-shared steht nur das drin:
mit Certificate von der pfsense und bei additional certificates die Zertifikate pro Server (Kameras, Hausautomation).
Bei jedem einzelnen Frontend steht nur, worauf es hört und welches Backend als Actions aufgerufen werden muss.Einen Versuch ohne das ganze shared Zeug hatte ich auch gemacht. Ist derzeit deaktiviert (siehe oben cam1-copy). Da ging noch weniger, als mit der beschriebenen Situation.
-
@alcamar Die Pakete, die ich beobachte beim Aufruf der Kamera-App kann ich nicht vollständig deuten. Es spricht für mich als Laien etwas dafür, dass die Anfrage von der pfsense zum Handy nicht ok ist, weil da etwas von nicht korrekter Checksumme steht:
13:46:37.326125 IP (tos 0x0, ttl 54, id 31060, offset 0, flags [DF], proto TCP (6), length 64) 80.xxx.xx.xxx.12008 > 192.168.178.254.443: Flags [S], cksum 0x040b (correct), seq 1102934232, win 65535, options [mss 1390,nop,wscale 6,nop,nop,TS val 4117574554 ecr 0,sackOK,eol], length 0 13:46:37.326215 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.178.254.443 > 80.xxx.xx.xxx.12008: Flags [S.], cksum 0x2725 (incorrect -> 0xaa4b), seq 1124675381, ack 1102934233, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 3986951100 ecr 4117574554], length 0Die Kamera-App antwortet vielsagend: "Die Netzverbidnung wurde unterbrochen". Die gleiche URL für den Zugriff auf die Kamera über einen Browser funktioniert problemlos und wird über den HAProxy angezeigt.
Das ist die aktuelle Testkonstellation beim HAProxy:
Die Hausautomations-App geht auch hier nur, wenn der Default der Hausautomationsserver ist.