App kommt nicht durch HAProxy
-
@viragomann Die App verlangt neben der Adresse auch den Port 443. Damit müsste sie ja HTTPS können, oder? Aus der Fehlermeldung der App würde ich nicht zwangsläufig auf ein Zertifikatsproblem schlussfolgern. Dort heisst es sehr "hilfreich":
'Es gab einen Fehler beim Verbinden. Dies könnte ein Problem des Servers oder der App-Einstellungen sein.'Wie leite Port 80 auf Backend? Im http-https die Action von rule:scheme https entfernen?
-
@alcamar said in App kommt nicht durch HAProxy:
Die App verlangt neben der Adresse auch den Port 443. Damit müsste sie ja HTTPS können, oder?
Wie? Der Port muss gesondert zusätzlich angegeben werden?
Zwingend ist es nicht, aber doch anzunehmen, wenn sie sich bei Schema HTTPS bzw. Port 443 nicht beklagt.
Aus der Fehlermeldung der App würde ich nicht zwangsläufig auf ein Zertifikatsproblem schlussfolgern. Dort heisst es sehr "hilfreich":
'Es gab einen Fehler beim Verbinden. Dies könnte ein Problem des Servers oder der App-Einstellungen sein.'
Je nach Qualität der App kann das alles mögliche bedeuten.
Wie leite Port 80 auf Backend? Im http-https die Action von rule:scheme https entfernen?
Ja, und eine Weiterleitung auf das Backend im Port 80 Frontend einrichten.
-
@viragomann Die App ist keine womit man zum Mond fliegen könnte, aber sie macht das wenige. :-) Die Einstellungen sind überschaubar:
Der interne Port ist optional. Den bestimme ich ohnehin im HAProxy abhängig von der Adresse.Da HAProxy grundsätzlich geht, muss ich schauen, wie ich die Einstellungen beibehalte und die Portweiterleitung testen kann. Die ersten Versuche in diese Richtung waren nicht von Erfolg gekrönt.
-
@alcamar
Nachdem die App einen SSL-Schalter hat, sollte das auch funktionieren.
Ob HTTPS aber das Zugriffsprotokoll ist, geht hier nicht hervor.
Allerdings hast du anfangs erwähnt, im Browser funktioniert genau diese Adresse?Der interne Port ist optional. Den bestimme ich ohnehin im HAProxy abhängig von der Adresse.
Damit ist also der Part gemeint, auf den der Server tatsächlich lauscht?
-
@alcamar und warum ist in der App dann überhaupt ein interner Port konfiguriert?
Das klingt eher wie die App von HomeAssistant, die unterscheiden will/kann ob der Zugriff von extern geht oder intern und je nachdem andere Verbindungseinstellungen nutzt. Und ggf. versucht er es dann via Domain+8084 und das klappt dann natürlich nicht.
Ich würde wenn es im Browser geht mal mit Port 443 als internem oder gar keinem probieren, damit er sauber Domain+443 nutzt.
-
@viragomann Der Hausautomationserver bietet je nach Client (Browser, Tablet, Handy) verschiedene Ports (8083-8085). Die App nutzt den Handy-Port, wenn er angegeben wird. Man kann diesen also optional in der App angeben. Ich habe das aber mit dem Namen gelöst. M.Name.de, T.Name.de und Name.de landen auf den richtigen Port, ohne diesen explizit anzugeben. In der App haber ich den eingetragen, aber der Proxy holt mit dem Namen den richtigen Backend und Port.
-
@jegr das ist so einen App. Mit Browser komme ich mit 443 problemlos an Server dran. In der App ist es ein Muss-Feld. Also muss ich diesen angeben. Das war bisher auch so im alten Reverse-Proxy.
Ich habe alle Portkombinationen erfolglos ausprobiert -
@alcamar said in App kommt nicht durch HAProxy:
Der Hausautomationserver bietet je nach Client (Browser, Tablet, Handy) verschiedene Ports (8083-8085). Die App nutzt den Handy-Port, wenn er angegeben wird. Man kann diesen also optional in der App angeben. Ich habe das aber mit dem Namen gelöst. M.Name.de, T.Name.de und Name.de landen auf den richtigen Port, ohne diesen explizit anzugeben.
Und das lief im Synology ebenso über die Namen?
Mir ist nicht klar,. warum das überhaupt über einen HTTP-Proxy laufen muss, wenn die App ohnehin auf einen eigenen Port geht, der in dieser nur einmal eingestellt werden muss. Mir wäre ziemlich gleichgültig, welcher das ist.
-
@viragomann das lief über die Namen. Ich habe auf der Fritz nur Port 443 und Port 80 offen und VPN. Das ist auch meine Motivation für einen Proxy. Vor Jahren hatte ich alle Ports für die Hausautomation offen. Mit dem Proxy habe ich alle geschlossen.
-
@alcamar Ja aber wenn du das über den Namen gelöst hast, warum dann nicht so:
- m.sub.domain.de (wird ja nur für Mobile benutzt?)
- extern auflösen auf IP der Fritte
- checken, dass 443 dann auf den Homeserver weitergereicht wird an den richtigen Port
- intern direkt auf den Homeserver auflösen lassen via DNS Override!
- dadurch intern kein Proxy nötig, weil er direkt mit m.sub.domain.de:8084 an den Server rangeht/rankommt, während er extern dann :443 nutzt und via Proxy umgesetzt wird.
Und die anderen Kisten nutzen dann ja eh eine andere Domain und werden entsprechend anders gehandelt?
Damit hast du extern immer noch nur 80/443 offen und intern verbindest du dich ohne Proxy direkt mit der Kiste was eh schneller sein dürfte. Und gut ist :) -
@jegr Hallo Jens, danke. Ich werde das alternativ prüfen. Im gleichen Augebenblick, wie Dein Post kam, aber ich eine "Lösung"., die ich zwar noch nicht kapiere, und eher zufällig gefunden habe. Wenn ich beim Default Backend den Hausautomationsserver eintrage, macht die App keine zicken. ob das wirklich eine Lösung ist, weiß ich nicht, weil vielleicht geht jetzt irgendetwas anderes nicht. Muss ich prüfen...
-
@alcamar
Das deutet darauf hin, dass sonst für die Zugriffe vom Handy keine Regel angewandt wurde. -
@jegr die m.sub.domain.de, die nur das Handy nutzt, lässt sich als Host im DNS HostOverride nicht eingeben. Der Hostname muss wohl ohne "." sein. Mein m.sub will er nicht.
Ich habe das Prinzip auf die Kamera-App angewandt, wo ich ein sehr ähnliches Problem habe. Exterene Auflösung klappt, 443 landet auf auf der pfsense, wo ich ein Host Override auf die Cam1 habe. Trotzdem meldet sich die App nicht an der Cam an. -
@alcamar said in App kommt nicht durch HAProxy:
@jegr die m.sub.domain.de, die nur das Handy nutzt, lässt sich als Host im DNS HostOverride nicht eingeben. Der Hostname muss wohl ohne "." sein. Mein m.sub will er nicht.
Ja und? Dann trage doch m als Hostname und sub.domain.de als Domain ein, ist ja auch korrekt so?
Dass es funktioniert kannst du dann mit Diagnostics/DNS Lookup testen - und dein Handy/App sollte es auch richtig auflösen bzw. die Sense als DNS haben, sonst macht der ganze Spaß natürlich keinen Sinn. -
@viragomann Du meinst im HAProxy nimmt von der Url gar keine Notiz. Nur wenn ich ich sie als Default eingebe, leitet er dorthin standardmäßig weiter?
Aber dann warum dieses Verhalten über die App und nicht auch über den Browser? -
@alcamar
Der Browser nutzt ja einen anderen Host, oder? -
@jegr Der Name m klappt natürlich und der Rest ist dann Domain. Peinlich.
Diagnostics/DNS Lookup wirft mir die interne IP-Adresse des Homeservers aus. Als Nameserver 127.0.0.1 (Hätte das die pfsense erwartet 192.168.1.1)
Bei der App wird es wieder problematisch, weil ein DNS kann ich dort nicht eintragen. Ich dachte, dass OpenVPN das DNS-Problem lösen würde, tut es aber auch nicht.
Die Ping-App auf dem Handy gibt auf m.sub.domain.de eine IP in Hexa-Code zurück. -
@viragomann Der Standardweg über den Browser ist name.domain.de Nur die App nutzt als Adresse m.name.domain.de. Im Browser geht diese natürlich auch. Der Unterschied zwischen den Adressen ist nur die Darstellung.
-
Die Standard-Adresse ist die nomale Web-Seite in Standardauflösung und
-
die m.-Adresse ist die Darstellung kleine Devices.
name.domain.de hat den Default-Port 8083. Nimmt man explizit den Port für die kleinere Auflösung geht das mit name.domain.de:8084.
Um mir den Port zu sparen habe ich m.name.domain.de = name.domain.de:8084 -
-
@alcamar
Und ist das alles auch so in HAproxy eingerichtet? -
@viragomann ja, aber ich komme immer mehr zu dem Schluss, dass da irgendwie ein Konzeptionsfehler ist.
Ich glaube, dass ich weg muss, von dem https-Shared, was zwar die Übersicht verbessert, aber nicht adäquat gruppiert. Vermutlich brauche ich ein https-Shared für die Cams und eins für die Hausautomation usw. Pro https-Shared hätte ich dann ein Default Backend. Für die App wäre es wohl die Lösung. -
@alcamar
Das sind alles Shared Frontends?Bei mir ist alles was an eine IP geht, in einem, auch beide Ports 80 und 443.
Aber Shared Frontends sollten an sich nicht das Problem sein. Du musst nur bedenken, dass sobald eine ACL in einem Frontend zutrifft, die entsprechende Action angewandt wird und weitere Frontends nicht mehr zum Zug kommen.
Aber interessanter als die vielen Frontends sind jedenfalls die ACL und Actions darin.
-
@alcamar said in App kommt nicht durch HAProxy:
Als Nameserver 127.0.0.1 (Hätte das die pfsense erwartet 192.168.1.1)
Bei der App wird es wieder problematisch, weil ein DNS kann ich dort nicht eintragen. Ich dachte, dass OpenVPN das DNS-Problem lösen würde, tut es aber auch nicht.
Die Ping-App auf dem Handy gibt auf m.sub.domain.de eine IP in Hexa-Code zurück.Sorry ich verstehe kein Wort. Was ist kaputt? Bitte vielleicht auch einfach mal mehr deiner Aussagen mit Screenshots untermalen damit man weiß was du wo woher wie siehst, ich verstehs nämlich einfach nicht mehr.
Es kann doch jetzt nicht schwer sein, die m.blah.domain.de mal im DNS der pfSense als Host Override direkt auf den FHEM Server zu konfigurieren, das dann in die App einzutragen und von intern dann zu testen ob der Server aufgeht. Wenn ja - profit. Super - da die App innen wahrscheinlich dann einfach den internen Port automatisch anhängt und nutzt.
Und von extern zeigt der m Name dann auf die Public IP4 (via DynDNS oder wie auch immer) und landet dann mit 443 am Proxy und sollte via shared frontend dann auch auf dem FHEM landen.
Das war die Idee dahinter. Ich kenne eben die App nicht, die HomeAssistant Kiste macht aber eben was ähnliches was ich genauso nutze und weiß dass es deshalb funktioniert. Daher steckt wahrscheinlich entweder noch nen DNS Problem oder nen Proxy Knacks irgendwo. :)
-
@jegr sorry, wenn ich mich nicht verständlich ausgedrückt habe.
@jegr said in App kommt nicht durch HAProxy:
Ja und? Dann trage doch m als Hostname und sub.domain.de als Domain ein, ist ja auch korrekt so?
Dass es funktioniert kannst du dann mit Diagnostics/DNS Lookup testen - und dein Handy/App sollte es auch richtig auflösen bzw. die Sense als DNS haben, sonst macht der ganze Spaß natürlich keinen Sinn.das habe ich mit der m.blabla.de als input in Diagnostics DNS gemacht:
Die 10.10.1.74 die IP-Adresse des Fhem-Servers und sollte damit ok sein.
Die Adresse wird richtig aufgelöst, wenn man aus dem Internet kommt. Ist also auch ok.
@jegr said in App kommt nicht durch HAProxy:
Und von extern zeigt der m Name dann auf die Public IP4 (via DynDNS oder wie auch immer) und landet dann mit 443 am Proxy und sollte via shared frontend dann auch auf dem FHEM landen.
Leider Nein. Die App geht trotzdem nicht. Der Proxy funktioniert nur dann, wenn ich den Default Server in http-shared auf fhem umstelle, was aktuell meine "Lösung" ist. Weshalb ich denke, dass mein http-shared nicht ok ist. @viragomann hat einen für mich plausiblen Ansatz pro IP-Adresse einen http-shared zu machen.
Deinen Ansatz ohne Proxy auf diesen Server zu kommen, würde ich präferieren, aber ich bekomme das nicht hin, oder ich habe noch irgendwo einen Knoten drin. -
@jegr said in App kommt nicht durch HAProxy:
Es kann doch jetzt nicht schwer sein, die m.blah.domain.de mal im DNS der pfSense als Host Override direkt auf den FHEM Server zu konfigurieren, das dann in die App einzutragen und von intern dann zu testen ob der Server aufgeht. Wenn ja - profit. Super - da die App innen wahrscheinlich dann einfach den internen Port automatisch anhängt und nutzt.
Eine OpenVPN-Verbindung mit dem Handy zur pfsense sollte den internen Zugriff simulieren. Aber wie beschrieben, geht das auch nicht. Intern simulieren hätte ich mit WLAN-Zugriff einfacher haben können, aber mein WLAN (Fritte) läuft derzeit noch an der pfsense vorbei, bis ich für die Integration des WLANs in pfsense eine Lösung finde.
-
@alcamar said in App kommt nicht durch HAProxy:
Der Proxy funktioniert nur dann, wenn ich den Default Server in http-shared auf fhem umstelle, was aktuell meine "Lösung" ist. Weshalb ich denke, dass mein http-shared nicht ok ist.
Welche Regeln sind da drinnen?
Eine OpenVPN-Verbindung mit dem Handy zur pfsense sollte den internen Zugriff simulieren. Aber wie beschrieben, geht das auch nicht
Hast du den internen DNS im OpenVPN Server bereitgestellt?
Wenn es der DNS Resolver ist, muss der VPN Tunnel Pool eventuell noch in den ACLs hinzugefügt werden.Andriod Geräte dürften noch zusätzliche Kicks benötigen, um den über VPN bereitgestellten DNS zu verwenden.
Welcher OpenVPN Client ist das? -
@viragomann im https-shared steht fast nichts:
Dort habe ich den Default Backend eingetragen, was aktuell die einzige Lösung ist. Auch die Zertifikate aller Server habe ich hier aufgelistet.In den einzelen Frontends ist dann die Adresse, auf die reagiert wird und der Verweis auf das dazugehörige Backend.
(Die URL im Screeshot ist ein Platzhalter)
Den DNS habe ich im OpenVPN eingetragen:
@viragomann said in App kommt nicht durch HAProxy:
Wenn es der DNS Resolver ist, muss der VPN Tunnel Pool eventuell noch in den ACLs hinzugefügt werden.
das habe ich nicht gemacht. Wo trage ich den ein?
Ich nutze die App OpenVPN unter IOS.
-
@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.