DSLite / Firewall -> Aliases -> IP & Services -> DNS Resolver -> General Settings -> Host Overrides
-
@Bob.Dig Ich bin glaub ich gerade Betriebsblind.
Wo außer Firewall -> Aliases kann ich denn noch einen Aliasnamen eintragen?
-
-
Das geht nicht.
The following input errors were detected: An alias with this name already exists. Alias value cannot be the same as the alias name: `DebianServerVM2 and DebianServerVM2` There may be additional errors. Fix the noted problems and try again.Da muss entweder ein FQDN stehen oder eine IP-Adresse
-
@eagle61 said in DSLite / Firewall -> Aliases -> IP & Services -> DNS Resolver -> General Settings -> Host Overrides:
Da muss entweder ein FQDN stehen oder eine IP-Adresse
"Nope", aber anscheinend darf der Name des Aliases nicht identisch zu dessen Inhalt sein. Ich setze immer einen Buchstaben H davor, deswegen war mir das nicht bekannt. Also als Name z.B. HDebianServerVM2 und als Inhalt dann DebianServerVM2.
-
@Bob.Dig
Nur dass ich nun, ohne den FQDN des DynDNS dort unter Alias nicht mehr vom WAN (Mobilfunknetz) auf meine Nextcloud komme ... -
@eagle61 Ich kann nicht folgen. Dieser Alias (also die Table) soll beide IP-Adressen enthalten (private IPv4 und öffentlicher IPv6), tut er das? Diesen Alias sollst Du in deiner Firewall Regel auf dem WAN verwenden. Den kannst Du auch in beiden Regeln verwenden (v4&v6).
Von außen verwendest Du weiterhin deinen FQDN.
-
Dieser Alias (also die Table) soll beide IP-Adressen enthalten (private IPv4 und öffentlicher IPv6), tut er das?
Nein. Da wird nix eingetragen in Diagnostics -> Tables ohne FQDN. Bleibt dann leer.
Den Eintrag mit dem FQDN des DynDNS hatte ich gelöscht nu aber wieder hergesttelkt, weil auch keine zwei namengleichen Einträge zulässig sind.
Also hatte Properties -> Name = HDebianServerVM2 und Host(s) -> IP or FQDN = DebianServerVM2 kein Eintrag unter Diagnostics -> Tables
Zweimal Properties -> Name = DebianServerVM2 geht aber auch wieder nicht. Also einmal mit Host(s) -> IP or FQDN = HDebianServerVM2 und das andere Mal mit dem FQDN
-
@eagle61 said in DSLite / Firewall -> Aliases -> IP & Services -> DNS Resolver -> General Settings -> Host Overrides:
Also hatte Properties -> Name = HDebianServerVM2 und Host(s) -> IP or FQDN = DebianServerVM2 kein Eintrag unter Diagnostics -> Tables
Die kommen aber noch. Wenn nicht, mit den DHCP Servern rumspielen. Der Hostname muss aber jeweils DebianServerVM2 lauten. Und die Firewall muss weiterhin den Resolver nutzen, sonst geht es nicht. Kannst ja auch mal die Sense neustarten. So oder so, so hat es funktioniert und ich bin jetzt erst mal raus. Hoffe, dass es noch klappt. GL!
-
@Bob.Dig
ich hätte dir gestern noch geantwortet. Aber konnte dann hier im Forum nichts mehr schreiben -> Forum war im Maintenance ModeAktuell gibt es gerade bei meinem DynDNS-Anbieter ein Problem. Der hat zwar nach der Zwnagstrennung ein Update der IPv6-Adressen angenommen, aber diese werden derzeit nicht weitergegeben an die übergeordneten DNS-Server. Daher verweisen alle noch auf die alten IPv6-Adressen.
Somit werde ich mit weiteren Änderungen warten bis das wieder läuft.
Danke aber soweit für Deine Hilfe.
-
@eagle61 Eine andere Idee hätte ich auch noch.
Du könntest deinem Server einen zweiten DNS-Namen geben via DDNS. Dann benutzt Du den zweiten nur für die Firewall-Regel.
Denn ich kann dir auch nicht sagen, ob meine Lösung mit KEA noch heute funktioniert, da ich mein IPv6-Engagement doch merklich zurückgefahren habe. -
Moin @Bob.Dig,
Also das grundproblem liegt m.E. an anderer Stelle, jedenfalls für IPv6. Einträge unter Services -> DHCP Serve0 -> DHCP Static Mappings (egal ob v6 oder v4) führen ja noch nicht dazu, dass ubound davon weiß und die IP-Adresse dem intern verwendeten Hostnamen und der Domain zuweisen kann.
Im KEA (v6) kann ich dort einen EIntrag erstellen, wie
::aaa.bbbb.cccc.ddddUnd der KEA ergänzt dann den Ipv6-Präfix zu einer vollständigen /128 IP-Adresse. Nur davon weiß eben unbound nix.
Damit unbound davon weiß, also Hostnamen, Domain zur IP-Adresse auflösen kann, braucht es ja noch einen Eintrag unter Services -> DNS Resolver -> General Settings -> Host Overrides und dort sind Einträge wie
::aaa.bbbb.cccc.ddddzwar möglich führen aber zu einer falschen Auflösung des Hostnames. nämlich per nslookup dann auch nur zur IPv6 ::aaa.bbbb.cccc.dddd weil der IPv6-Präfix eben fehlt.
Somit kann man so nur mit IPv4-Adressen arbeiten, wenn man einen täglich wechselnden Präfix hat, wie ich.
Deswegen braucht es ja den Alias, der den vollständigen FQDN IMMER über einen übergeordneten DHCP-Server auflöst. Unbound kann das offenbar nicht und fragt dann immer an bei 8.8.8.8 / 9.9.9.9 oder was auch immer man da als übergeordnete Server verwendet.
Trägt man in den Host Overrides aber auch den DynDNS FQDN für dessen IPv4-Adresse ein, wird nur der intern aufgelöst (IPv6 geht ja nicht) und gar keine externe Anfrage (an 8.8.8.8 oder 9.9.9.9)mehr gestellt. Denn jeder EIntrag in Host Overrides fürht auch zu einem analogen Eintrag in der /etc/hosts.
-
@eagle61 said in DSLite / Firewall -> Aliases -> IP & Services -> DNS Resolver -> General Settings -> Host Overrides:
Und der KEA ergänzt dann den Ipv6-Präfix zu einer vollständigen /128 IP-Adresse. Nur davon weiß eben unbound nix.
Das war halt mit ISC DHCP noch anders, da wurde die komplette IP dort registriert. Und mit IPv4 funktioniert das auch mit KEA, nur für IPv6 kann ich es dir nicht sagen, da ich es nicht mache.
Daher mein Vorschlag von eben. Wenn Du einen zweiten FQDN hast/machst, für den Du eben keinen Host Override nutzt, dann manipuliert Unbound den auch nicht und die Firewall-Regel wird für diese IPv6 problemlos funktionieren.
-
Ja, daran, dass es mit
ISC DHCP
noch anders war kann ich mich auch erinnern. Bin ja noch nicht so lange bei pfsense (so ca. 18 Monate) und nutzte davor IPFire mit ISC DHCP. Die IPFire kann aber kein IPv6 (gar nicht) und da absehbar war, dass ich (wegen Glasfaser) bei DS-Lite / CGNAT landen würde, bin ich zur pfsense gewechselt und hab gleich von Anfang an alles auf IPv6 konfiguriert und auch gleich KEA genommen, da ISP ja nicht mehr weiterentwickelt wird.
Das mit dem
zweiten FQDN
werde ich versuchen, sobald die Probleme beim DynDNS-Anbieter vollständig behoben sind. Das Webportal ist schon wieder erreichbar, doch offenbar noch nicht alle Services und daher ist es mir derzeit zu heikel dort Veränderungen vorzunehmen.
Kann also sein, dass ich das heute nicht mehr probieren werde, werde aber die Ergebnisse hier teilen.
-
@eagle61 Du bist beim schroederdennis...
Der dynamische IPv6-Support in pfSense ist jedenfalls absolut unbefriedigend und soll in der anderen Sense besser sein. Die haben z.B. einen Alias vom Typ Dynamic IPv6 Host. -
@Bob.Dig eine wirklich praktikable Lösung dafür, die Nextcloud im LAN auch per IPv4 unter dem FQDN zu erreichen habe ich nicht gefunden.
Dafür nun aber eine Lösung für das eigentliche Problem, weswegen ich die Erreichbarkeit per IPv4 unter dem FQDN überhaupt herstellen wollte. Und das hat nichts mit der pfsense zu tun, sondern mit Android.
Android-Geräte verlieren im WLAN regelmäßig nach einiger Zeit die öffentlichen, per SLAAC erhaltenen IPv6-Adressen und handeln dann auch keine neuen aus. Diese dummen Androiden, die ja bekanntlich auch kein DCHPv6 können, haben dann nur noch eine IPv4- und fe80-IPv6-Adresse.
Über beide erreichen die aber eben nicht die Nextcloud um nachts per FolderSync zur NC zu sychonisieren.
Bei Reddit: Android verliert ipv6 im WLAN habe ich nun den hoffetntich entscheidenden Lösungsansatz gefunden, nämlich fürs WLAN in den Router Advertisements die Router Lifetime deutlich zu verlängern, von default 1800 auf 9000 Sekunden.
