Messages

Ja, nur, wie baust du deine Firewallregeln, wenn dein Präfix dynamisch ist?

Die Firewallregel(n) habe ich mit MAC-Aliasen gebaut. In den pfTables kann ich dann sehen, dass er damit die IPv4- und die IPv6-Adresse für die Freischaltung nutzt.

Das ist eine hypothetische Frage aber wofür brauche ich Regeln von genau einem Client? Durch Privacy Extensions haben die eh immer andere Adressen. Man kanns abschalten und den Client fix per DHCP6 zuweisen aber selbst dann ist die Frage, warum ich genau einen Client einfangen möchte? Ansonsten kann ich ja problemlos mit dem <Interface>_network Alias arbeiten was sich dann auch an dynamic prefixes anpasst

Ich möchte bestimmen, welcher Host welche ausgehende Verbindung aufbauen darf.

Sind in Unbound denn die Haken für DHCP Reservation drin? Sind in DHCPv6 die DNS Registrationen auch eingeschaltet? Mal das DynDNS ausklappen und Testweise Registration in DNS anhaken aber keines der anderen Felder (DynDNS) ausfüllen.

Haken in Unbound ist drin (2021-10-16 04_50_51-Services_Unbound_DNS_General.png). Lt. Doku gilt der aber nur für IPv4  :(. Ich habe den DynDNS-Haken im DHCPv6-Server jetzt mal reingesetzt (2021-10-16 04_57_33-Servcices_DHCPv6.png). Aus der Beschreibung verstehe ich das so, dass die Einträge mit Authentifizierung an einen DNS-Server gemeldet werden. Aber mal schauen.

Was mich nur wundert, dass die Leases noch nicht einmal beim DHCP-Server angezeigt werden (2021-10-16 05_24_58-Leases_DHCPv6_Services.png). Oder liegt hier der Fehler.

Ich bekomme jedenfalls auf meinen Debian-Servern IPv6-Adressen mit dem Provider-Präfix vergeben.

Danke
Ulf

Wahrscheinlich werde ich gleich gesteinigt, aber ich muss noch einmal nachfragen, weil ich noch nicht so weit bin mit IPv6 wie ihr.

Laut dem Threadthema geht es um die Konfiguration von DHCPv6 auf der OPNsense. Nach meinem Verständnis bedeutet das,

• Annahme des Präfixes vom Provider
• Verteilung von IPv6-Adressen in den lokalen Netzen mit Subnetzen aus dem Provider-Präfix
• Eintragen der lokal vergebenen IPv6-Adressen im DNS-Server OPNsense

Das was jetzt in den letzten Posts beschrieben wurde, dreht sich aber um (in meinen Augen) IPv6 Natting von internen IPv6-Adressen auf externe IPv6-Adressen, oder?

Laut der Release-Beschreibung auf https://opnsense.org/about/road-map/ sollte OPNsense die IPv6-Adressen jetzt in Unbound eintragen.

Ich kann mit den dynamischen IPv6-Adressen leben. Wenn ich sie extern bräuchte, würde ich diese über DynDNS veröffentlichen. Leider trägt der DHCPv6-Server aber die vergebenen Leases nicht in Unbound ein (bei mir), wie es in der Roadmap beschrieben wurde. Mein Setup ist einem der vorangegangenen Post beschrieben. Dadurch habe ich keine Möglichkeit interne DNS-Namen auf IPv6-Adressen aufzulösen. Als Übergangslösung nutze ich aktuell MAC-Adressen in den Firewall-Aliassen, um die Freigaben nicht nach jedem DSL-Neustart ändern zu müssen.

Habt ihr noch einen Tipp für mich, was ich in der OPNsense untersuchen/debuggen kann, warum die DHCPv6-Releases nicht in Unbound eingetragen werden? Oder habe ich die Ankündigung falsch verstanden?

Danke
Ulf

Hallo zusammen,

das würde mich auch interessieren.

Ich habe bei mir IPv6 aktiviert und bekomme auch das Standard-Prefix der Telekom. Das wird im Interface weitergegeben (01.png). Ich bekomme auch IPv6-Adressen im Netzwerk verteilt (02.png). Selbst wenn ich mich neu einwähle und einen neuen Provider-Teil bekomme, wird der ordentlich an die Server im Netzwerk vergeben.

In den DHCPv6-Leases steht allerdings nur ein Lease drin  :o (03.png).

Meine DHCPV6-Config sieht so aus: siehe 04.png

Oder läuft das bei mir fehlerhafterweise per SLAAC, weil keine Leases eingetragen sind?

Danke
Ulf

Ich weiß nicht was sich geändert hat, aber seit dem Update auf 21.7 funktionieren alle Zugriffe via VPN von meinen Android-Geräten.

Hi Felix,

ein endgültige Ursache konnte ich leider nie ausfindig machen. Aber es funktioniert aktuell bei mir mit fünf DHCP-Netzen. Schau mal, ob Du mit den Anmerkungen aus diesem Post weiterkommst: https://forum.opnsense.org/index.php?topic=23983.msg114329#msg114329

Viele Grüße
Ulf

Falls es hilft, hier meine Konfiguration von einem Netzwerk. Es ist ebenfalls ein eigenes VLAN.

Wie sieht denn bei Dir das Netzwerk-Interface aus, dass seine IP-Adresse vom DHCP bekommt?

ipconfig /all auf Windows
oder
ip a und resolv.conf unter Linux

Hast Du einen DHCP-Reservierung für den Host eingetragen? Zum Testen kannst Du mal versuchen

• die Domain in die Reservierung eintragen
• diese Reservierung löschen und danach aus den Leases neu vergeben

Viele Grüße
Ulf

Hallo kosta,

ich erinnere mich dunkel, dass ich bei den ersten Versuchen die gleichen Probleme hatte. Auf Grund eines Tutorials bin ich auf Route-based VPN umgestiegen. Damit wird der VPN-Tunnel aufgebaut, beide Seiten haben eine explizite Endpunkt-Tunnel-Adresse und über diese Adressen wird dann normal geroutet. Man muss sich nur manuell ein entferntes Gateway anlegen

Das funktioniert bei super (Testaufbau) und verbindet sich nach Ausfällen automtatisch wieder.

Viele Grüße
Ulf

Gerne. Sehr schön.
Stimmt, die überlappende Subnetzmaske war mir auch nicht aufgefallen.

Also vom Standard-Routing sieht das für mich in Ordnung aus.

Du hast vermutlich zwei VPN-Tunnel parallel mit unterschiedlicher Prio angebunden für die Ausfallsicherheit?

192.168.0.0/16 dev Tunnel1 scope link metric 1000
192.168.0.0/16 dev Tunnel2 scope link metric 2000

Oder warum ist bei beiden das gleiche Netz angegeben?

Allerdings sehe ich in den IP-Adressen nirgends VPN-Teilnehmer-IPs. Nur die zwei APIPA-IPs für die Tunnel:

113: Tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 10.8.0.10 peer 52.211.230.201
    inet 169.254.144.58 peer 169.254.144.57/30 scope global Tunnel1
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a08:a/64 scope link
       valid_lft forever preferred_lft forever
114: Tunnel2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 10.8.0.10 peer 52.212.108.147
    inet 169.254.127.82 peer 169.254.127.81/30 scope global Tunnel2
       valid_lft forever preferred_lft forever
    inet6 fe80::5efe:a08:a/64 scope link
       valid_lft forever preferred_lft forever

Wie sieht ein traceroute von der VM zu deinem LAN-Gerät bzw. umgekehrt aus, wenn der VPN verbunden ist? Auf beiden Seiten müssten die gleichen Hops auftauchen.

Wie sieht den ein

ip a

und ein

ip r

auf dem Linux mit dem VPN-Client aus?

Wohin zeigt das Default-Gateway der Linux-VM?
Setzt der VPN-Client nur statische Routen für die Remote-Netze hinter dem VPN oder wird der gesamte Traffic über das VPN-Interface geroutet?

Hi sense,

ich hatte am Anfang die selben Probleme. Siehe https://forum.opnsense.org/index.php?topic=19427.0

Mein Workaround ist, dass ich beide DNS-Domänen in die Domain Search List im DHCP-Server eingetragen habe. Etwas Besseres habe ich noch nicht gefunden. Damit bekomme ich zumindestens ohne DHCP-Reservierung die korrekte(n) DNS-Domainen zugewiesen.

Und im Notfall und falls noch nicht geschehen. Reboot tut gut. Manchmal muss man die einzelnen Dienste einfach mal neustarten, damit sie Konfiguration vollständig laden.

PS: Hast Du aktiviert, dass der DHCP-Server die vergebenen IP-Adressen im DNS-Server einträgt?

Also ich habe das Thema zwar noch auf der Agenda, aber bisher noch nichts aktiviert.

IPS auf der OPNsense? Ich wüßte nicht das ich das aktiviert habe.  ???

Oder gibt es sowas jetzt schon auf Android?

Hallo Thomas,

Leider gibt es das Image nicht mehr zum Download. Ich werden wohl ein ARCH Linux in einer VM aufsetzen (im DHCP eine "fest" IP zu ordnen) und dort den UniFi Controller betreiben.

Ob ARCH Linux unterstützt wird kann ich nicht einschätzen. Ich vermute aber mal, dass es zumindestens mehr Arbeit mit Installation und Update wird. Ich habe schon mal von einem Installations und Update-Script gelesen, aber es selber bisher noch nicht benutzt.

Ich lasse es bei mir in einem Debian Lxc Container laufen. Ein minimal installiertes Debian als VM funktioniert hatürlich auch. Dann kannst Du nämlich das APT-Repository von Ubiquiti nutzen, was das Updaten in meinem Augen wesentlich erleichtert. Siehe https://help.ui.com/hc/en-us/articles/220066768-UniFi-Network-How-to-Install-and-Update-via-APT-on-Debian-or-Ubuntu

Für die Einrichtung finde ich diesen Artikel von Ubiquiti https://help.ui.com/hc/en-us/articles/204909754-UniFi-Layer-3-Adoption-for-Remote-UniFi-Network-Applications sehr hilfreich. Dort wird auch erklärt, wie die automatische Integration vie DNS oder DHCP klappt. Bei mir hatte ich das teilweise so, dass im remote Vlan ein unifi DNS Alias existierte, der auf den Controller im loklaen, über VPN verbundenen, LAN gezeigt hat. Dadurch finden neue Geräte den Controller automatisch.

Viel Erfolg
Ulf

Zum Vergleich mal der Screenshot von Windows.