Messages

Vielen Dank für den Link.

Nach einigen fehlgeschlagenen Versuchen fielen mir einige Einstellungen in der Fritzbox unter

Heimnetz => Netzwerk => Netzwerkeinstellungen => IPv6-Einstellungen

auf.

Hier müssen 2 weitere Einstellungen gesetzt werden:

- "Auch IPv6-Präfixe zulassen, die andere IPv6-Router im Heimnetz bekanntgeben".
- "DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren" und "DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen"
- siehe AVM: https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/1239_IPv6-Subnetz-in-FRITZ-Box-einrichten/

Erst anschließend konnte der von der Opnsense angeforderte und empfangene Prefix an die Interfaces weitergegeben werden.
Entgegen der Darstellung von AVM empfängt die Opensense lediglich einen /64 Prefix statt einem /62er.
Die Fritzbox erhält jedoch einen /59er Prefix und scheint diesen trotz verschiedener Optionen in der Opnsense WAN Schnittstelle (/60-64er Prefix anforderung) nut als /64er Prefix weiterzureichen.
Einsehbar unter ssh-Zugriff und der opnsense-shell.

Daraus resultiert jedoch, das ich lediglich ein Prefix mit der ID 0 an eine Schnittstelle weiterreichen kann...
Umgehen lässt sich dies, in dem ich die Prefix-Anforerung auf /62 stelle.
Obwohl ein 64er Prefix empfangen wird, lassen sich jedoch die ID's von 0-3 vergeben.
Die Verteilung funktioniert. Jedoch ist das Thema IPv6 relativ neu für mich und ich erkenne hierbei noch nicht die Probleme die sich aus dieser Konfiguration eventuell ergeben können.
Anbei noch eine kleine Übersicht:






Eine Frage stellt sich mir aktuell jedoch noch:

Dass ein IPv6 Server durch seine globale IPv6 Adresse erreichbar ist und dahingehend das bekannte NAT aus der IPv4 Welt nicht mehr benötigt wird ist verständlich. Was ich jedoch aktuell nicht nachvollziehen kann ist, wieso es nicht auch im IPv6 Bereich möglich ist, die globale IPv6 Adresse der Fritzbox per DynDNS aufzurufen und durch Portweiterleitungen eine Verbindung mit dem dahinterliegenden auch über IPv6 angebundenen Server aufzunehmen?


Weiterhin sind mir noch kleine Besonderheiten im Bezug auf IPv6 aufgefallen:
- Fritzbox:
    * Eine explizite Anforderung einer bestimmten Prefix-Länge über die FB ist nur mit einer ungebrandeten FB möglich, siehe:
    https://forum.vodafone.de/t5/Ger%C3%A4te/IPv6-Pr%C3%A4fix-mit-Fritzbox-6660-nicht-62/td-p/2708605
    * Ist in der Fritzbox der DynDNS Dienst, unabhängig des Anbieters und myfritz ausgenommen, aktiviert und wird als verbunden angezeigt, muss dies nicht zwangsläufig auch der Fall sein.
        Gibt es bei der Weiterleitung einen Fehler, kann man diesen nicht direkt erkennen. Denn die Fritzbox leitet den Aufruf der DynDNS Adresse aus dem internen Netz direkt auf die Fritzbox-Oberfläche weiter.
        Siehe:
        https://www.ip-phone-forum.de/threads/fritzbox-portweiterleitung-funktioniert-nach-update-auf-fritzos-7-27-nicht-mehr.310499/
- bei einem Aufruf der DynDNS Adresse, ist zu beachten, dass logischerweise das Startnetz auch IPv6 unterstützt. Klingt trivial, aber entgegen meiner Annahme scheint das nicht bei allen Mobilfunknetzen der Fall zu sein.

Guten Morgen,

da ich aktuell über eine Fritzbox 6660 Cable an Vodafone DS-Lite angeschlossen bin, würde mich interessieren, ob die Möglichkeit besteht, ähnlich eines PPOE Anschlusses, den erhaltenen IPv6 Prefix direkt oder als "Sub-Prefix" an die Subnetze der Opnsense automatisch zu verteilen?

Ich habe unter der Opensense => WAN Schnittstelle folgendes angekreuzt:

* IPv4 + IPv6 DHCP
* IPv6 Präfix anfordern
* IPv6 Präfix Hint senden


Soweit scheint das auch zu funktionieren. Der von Vodafone vergebene x:x:x:x::x /59 Prefix wird als x.x.x.x.x /64 Präfix an die Opnsense WAN Schnittstelle weitergereicht.
Aber wie bekommen die Subnetzte der Opnsense nun automatisch Ihren zugehörigen Prefix bzw. Adressraum?

Vielen Dank für den Hinweis.

Um es den nächsten Fragenden etwas zu erleichtern,
habe ich einige Posts bzgl. Opnsense als WLAN AP angehängt:

https://forum.opnsense.org/index.php?topic=31393.msg151381#msg151381
https://forum.opnsense.org/index.php?topic=25981.msg125314#msg125314
https://forum.opnsense.org/index.php?topic=12755.0
https://forum.opnsense.org/index.php?topic=28266.msg137245#msg137245

Mit freundlichen Grüßen

Transmission

Guten Abend,

ich nutzte eine APU2D4 mit einer Atheros WLAN Karte (2,4GHz).

Ich habe diese als Schnittstelle mit folgenden Einstellungen eingerichtet:
https://docs.opnsense.org/manual/how-tos/interface_wireless_internal.html

Nach einem erfolgreichem Login und einer Nutzung von ca. 7-10 Minuten fliegt das Testhandy immer wieder aus dem WLAN. Bei erneutem Verbindungsversuchen erhält es keine oder nur kurz eine IPv4 Adresse und fliegt wieder heraus bzw. trennt die Verbindung.
Um wieder eine kurze stabile Verbindung zu erhalten, muss ich zwangsläufig ca. 10 oder mehr Minuten warten.
Nach jeder erneuten Verbindung wiederholt sich obiges.

Ich finde jedoch den Fehler nicht und habe vorerst das gleiches WLAN Netz ohne Radius eingerichtet und stoße auf das gleiche Problem ohne eine Lösung bzw. den Fehler zu finden.

Ich hoffe, es gibt dahingehende Erfahrungswerte mit evtl. Lösungsansätzen.

Hello lovely Opnsense forum,

I know this post is a little bit old, but I would like to post the actually configuration.


# install

Code Select Expand


pkg install getdns

# if you use DNSSEC aktually, there is no need for you to use the command down there for initial the trust anchor from unbound, ten there it is allready
# if you doesn't use it to day, use the folowing command:

Code Select Expand


su -m unbound -c /usr/local/sbin/unbound-anchor

# configure stubby to run - from NO to YES

Code Select Expand


nano /usr/local/etc/rc.d/stubby


Code Select Expand


: ${stubby_enable="YES"}


## write config
# i use the preconfigured config
# first, in there are functional comments for almost all commands.
# second, this commands comes with mostly useful preconfigured strings / variables

Code Select Expand


nano /usr/local/etc/stubby/stubby.yml

# add / rewrite the the following commands:

Code Select Expand


# dnssec_return_status: GETDNS_EXTENSION_TRUE
# the stuby doku don't know this command -> older versions also?
# actually the command is this:

dnssec: GETDNS_EXTENSION_TRUE # remove #

listen_addresses:
  - 127.0.0.1@8053 # add specific port
  #-  0::1 # important!: if you don't use ipv6 -> comment out;
  # if you use ipv6 the set the right port; for example: "- 0::1@8053"
# otherwise unbound can't srart, becouse without port, stubby uses the same port: 53, and stubby start faster then unbound after a reboot

# tls_ca_path: "/usr/local/share/certs/ca-root-nss.crt"
tls_ca_file: "/usr/local/share/certs/ca-root-nss.crt" # add this line

# for not sequentially using the listed upstreamserver,
# but for randomly using
round_robin_upstreams: 1 # add this line

dnssec_trust_anchors: "/usr/local/sbin/unbound-anchor" # add the right path

tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20" # remove #
tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" # remove # be aware: Use it only with OpenSSL; don't use it with LibreSSL -> see supplement
tls_min_version: GETDNS_TLS1_2 # remove #



You can use the test servers in the yml file, but i have add almost all servers from the post below.

# now two methods to  verify QNAME minimisation
drill txt qnamemintest.internet.nl
# or
dig txt qnamemintest.internet.nl +short
# The results in any of these scenarios will show either:
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
# or
"NO - QNAME minimisation is NOT enabled on your resolver :(."
# Reference from the post below:

https://discourse.pi-hole.net/t/unbound-and-qname-minimisation/10038/4
# You will and should get HOORAY ! - if you used the name servers listed in this guide for your Stubby configuration.
    # Note: Starting with Unbound 1.7.2 qname minimisation is enabled by default.
    # However, I still add these settings manually.
    # These settings are entered under Unbound " Custom Options":
    qname-minimisation: yes
    qname-minimisation-strict: yes
    harden-below-nxdomain: yes

I doesn't found these three variables in the standard config in /var/unbound/* and the unbound documentation is not really informative =) :
https://unbound.readthedocs.io/en/latest/topics/privacy/qname-minimisation.html
These are the facts why i add there to the unbound config also (GUI).
After upgrade to 21.1, unbound want start with these three commands (if unbound doesn't start, you can check the config with

Code Select Expand

unbound-checkconf /var/unbound/unbound.conf) also i removed it and test the command below again:

Code Select Expand


dig txt qnamemintest.internet.nl +short


..you should see the hoooray again =)

After you save the config in the GUI, you can find it in

Code Select Expand


nano /var/unbound/unbound.conf


# set a startscript to run the stubby script ( /usr/local/etc/rc.d/stubby) after boot

Code Select Expand


nano /etc/rc.conf.d/stubby


Code Select Expand


stubby_enable="YES"
stubby_bootup_run="/usr/local/etc/rc.d/stubby"


# Save and exit , then make the file executable

Code Select Expand


chmod 755 /etc/rc.conf.d/stubby

# I don't know why directnupe set permissions with chmod to 744 and then set the permissions with a+x to 755???
# Anyway, thanks to directnupe to the introduction!

# Now you must configure your Unbound DNS Server to use Stubby for DNS Over TLS

"UNBOUND" "GENERAL SETTINGS"
"Network Interfaces" =  Select ALL !

# Under Custom options enter the following below the three Qname variables:

Code Select Expand


server:
do-not-query-localhost: no
forward-zone:
name: "."    # Allow all DNS queries
forward-addr: 127.0.0.1@8053


# set

"Outgoing Network Interfaces" = Select ALL !

# Make sure the box for "DNS Query Forwarding" is unchecked
# Save and Apply Settings
# Next go to

"System" > "Settings"  > "General Settings"

# and set the first DNS Server to

127.0.0.1

# with

"no gateway"

# selected

# Make sure that DNS server option

"Allow DNS server list to be overridden by DHCP/PPP on WAN"

# is unchecked
# and DNS server option

"Do not use the DNS Forwarder/Resolver as a DNS server for the firewall"

# is unchecked also
# save all

# log in to ssh and check stubby works perfectly
# run:

Code Select Expand


stubby -l


# go to GUI under
"DNS check"
# and check out an ip from a website
# after this, go to ssh terminal and check the logs (stubby -l)
# is everything is fine (ip and logs), then restart opnsene and enjoy
# note: it is a good idea to check the DoT DNS servers in stubby.yml every half year

Afterwords, it is a good idea to check these boxes in Unbound :
hide-identity and hide-version.

So I hope this post trigger you to run DoT with verification and not only unbund to use Dot without verification.

kind regards

transmissionend


supplement / usecase LibreSSL:

1. At the moment, you can't use LibreSSL with the "tls_ciphersuites". This command isn't working.
If you use the command, stubby can't resolve any DNS query. You get the message:  "This LIbreSSL version does not support configurating cipher suites"

2. When you moved from OpenSSL to LibreSSL, you have to set stubby to enable again: "/usr/local/etc/rc.d/stubby"