Messages

Ach, ich bin doof, hab ja eine VLAN Gruppe. Probiere es erstmal damit

Hallo,

das Kind muss nachts etwas eingeschränkt werden :-D
Ich habe hier daher eine Liste an relevanten MAC-Adresse, die ich gern zeitgesteuert blockieren will. Diese MACs hängen alle in unterschiedlichen VLANs. Gibt es einen einfachen Weg für eine globale Regel, um die zeitgesteuert per DENY zu blockieren oder muss ich in jedem VLAN separat eine Regel anlegen? Geht das vllt. auf dem übergeordneten physischen LAN über das die VLANs letztlich laufen?

VG

Argh. Du hast natürlich recht, daran habe ich nicht gedacht.

"Na klar". Wofür sonst gibt es Header wie X-Real-IP oder X-Forwarded-For...Adguard unterstützt das auch, siehe https://github.com/AdguardTeam/AdGuardHome/wiki/Encryption#nginx
Möglich, dass ich mir morgen nochmal die trusted_proxies Direktive in Adguard anschauen muss

:'(

1) Anpassungen am Nginx Plugin werden mit dem Reload-Button nicht übernommen, da ist immer ein De- und Aktivieren des Plugins notwendig (quasi für einen kompletten Neustart des Services) - das ist aber noch das kleinere Übel.

2) Ärgerlicher ist aber, dass ich den lokalen Unbound nicht als Backup-Server im Upstream definieren kann, der wird dann einfach nicht genutzt. Muss ihn also im Round Robin ständig aktiv halten mit einer niedrigeren Priorität.

3) Was aber gerade gar nicht funktioniert, aber essentiell ist: Die Client IP kommt nicht in Adguard an, sondern immer nur die IP der OPNsense. Hat dazu jemand eine Idee?

Achso, das SPoF stört mich hier nicht. Ich nutze Nginx für diverse Reverse Proxy Geschichten seit vielen Jahren, vertraue also darauf. Und da der Nginx auf der OPNsense laufen soll ist das auch weniger kritisch für mich. Die Clients bekommen bisher eh nur den Unbound auf der OPNsense als DNS Server mitgeteilt. Und wenn mir die ganze OPNsense-Kiste abrauscht, ist eh Feierabend. Und sollte der Nginx Proxy doch mal ausfallen, dann ist es so, damit kann ich leben. Mein NAS ist da deutlich ausfallgefährdeter als die dedizierte Appliance.

Ich sehe gerade, es gibt ja Nginx als offizielles Plugin. Damit müsste sich doch ein UDP Reverse Proxy für DNS aufsetzen lassen. Per Upstream könnte ich dann Adguard auf dem NAS ansprechen und im Fehlerfall auf Unbound zurückfallen. Das schaue ich mir mal genauer an...

Bevor ich mich an die Umsetzung mache, hier eine Frage, ob und wie das technisch lösbar ist. Ich nutze OPNsense 24.1.5 mit Unbound DNS, ganz normal. Ich möchte Adguard Home einsetzen aber ungern ein externes Repository auf der OPNsense integrieren, daher war die Überlegung, Adguard als Docker auf dem permanent aktiven NAS aufzusetzen. Ich benötige Adguard, weil ich bei der Blocklist Ausnahmen für bestimmte Clients machen muss.

Dazu hätte ich für DNS-Anfragen, die *nicht* vom NAS kommen im OPNsense eine Port Forwarding Regel für UDP Port 53 eingerichtet, die auf den Adguard Docker Container auf dem NAS verweist. Und Adguard wiederum soll als Upstream natürlich den Unbound von OPNsense verwenden.

Die Frage ist nun: Wie kann ich da nun die Verfügbarkeit erhöhen. Für den Fall, dass das NAS gerade nicht verfügbar ist, werden dann vermutlich keine DNS Anfragen mehr beantwortet. Gibt es eine Möglichkeit im OPNsense den integrierten Unbound *doch* zu nutzen, falls das Adguard auf dem NAS nicht antwortet oder erreichbar ist?

BREAKING: Ich glaube, ich hab es gerade am Laufen. Connect ist per IPv4 und IPv6 möglich, geroutet wird aber nur IPv4 aktuell. Was habe ich anders gemacht als in der Anleitung?

1) Ich habe die UDP encapsulation wieder *deaktiviert*
2) Für IPv4/6 auf dem WAN Interface eine Allow ESP Regel angelegt

Somit ist aktuell ein Connect mit den nativen Android und Windows-Clients möglich.

Da der öffentliche Transport somit scheinbar auch doch über IPv6 funktioniert, probiere ich vllt. mal noch das Routing von IPv6 über den Tunnel. Hab nur kein statisches Präfix...

Nicht dass wir aneinander vorbeireden: Ich habe IPv6 jetzt bewusst beim Verbindungsaufbau unterbunden, indem ich einen IPv4-only Hostname verwende und die Firewall nur IPv4-Verbindungen akzeptiert. Ich bekomme ja den Verbindungsaufbau bestätigt, nur Traffic läuft keiner drüber. Es wird schon irgendwas in Richtung Firewall sein, aber ich habe keine Ahnung was!? Oder bringe ich hier irgendwas komplett durcheinander?

[EDIT:]

Sorry hat eine Weile gedauert. Das VPN war bisher über IPv6 erreichbar, sollte ja eigentlich für den Aufbau den Tunnels unerheblich sein. Aber egal. Ich habe ihn aktuell gezwungen per IPv4 zu verbinden (indem ich eine nur per IPv4/A auflösbare Domain verwendet habe).

Die Einträge im Dashboard werden erzeugt (siehe Screenshot 1). Dennoch ist das Verhalten unverändert. Windows funktioniert einwandfrei, bei Android nach wie vor keine Namensauflösung, Ping etc. Ich kann mir daher auch keinen Reim drauf machen, warum das an der Firewall liegen soll (Windows Client läuft ja).

EDIT: Ein Unterschied fiel mir jetzt auf (siehe zweiter Screenshot). Dort ist als Protocol "esp" zu sehen, beim Connect von Android aus. Wenn ich mit dem Windows-Client verbinde, steht als Protocol "esp-udp". Also scheint Android das encapsuled UDP nicht zu können!?

See my post at https://forum.opnsense.org/index.php?topic=39995.msg196217#msg196217
Manually re-attaching the IP address via ifconfig command solves the issue for me. Sure, that doesn't explain the reason and can't be a permanent solution (i.e. I get a dynamic prefix from ISP, so I can't hardcode it on boot).

Hallo Maurice,

danke für die Rückmeldung. Ich experimentiere bereits seit Tagen und würde meine Erkenntnisse versuchen zusammenzufassen. Aber kurz vorweg: Nein, ich bekomme beim Neuverbinden ein neues IPv6-Präfix am Glasfaser-Anschluss, ist wohl nur bei Business-Anschlüssen möglich.

Ein Hauptproblem bei meinem Setup scheint wohl, dass die IPv6 vom Glasfaser als detached in OPNsense/FreeBSD markiert wird, sobald das LTE-Interface hochfährt (siehe auch https://forum.opnsense.org/index.php?topic=39995). Das kann ich lösen, indem ich manuell die Adresse per ifconfig wieder hinzufüge. Das ist aber kein sauberer Weg (da dynamisches Präfix) und macht auch Probleme beim Failover.

Genau das war meine Sorge, dass die VLANs nur vom Glasfaser (/56) per PD eine GUA erhalten, aber eben nicht vom LTE. Damit wäre das IPv6 Routing beim Failover hinüber. Meine Überlegung war daher, intern nur mit ULAs zu arbeiten, ähnlich einem IPv4 NAT-Setup. Ich habe keine Dienste, die von außen erreichbar sein müssen und ich habe in dem Fall auch kein Problem, dass Windows IPv4 gegenüber IPv6 bevorzugt. Wichtig ist mir, dass ich überhaupt eine IPv6-Verbindung für IPv6-only-Ziele habe.

Ich hatte daher gestern meine OPNsense wie folgt konfiguriert:

Glasfaser:
    IPv4 per PPPoE
    IPv6 als DHCPv6 mit zusätzlichem /56er Präfix
LTE
    IPv4 per PPPoE
    IPv6 als DHCPv6 ohne Präfix
Wie gesagt, die Glasfaser-IPv6 wird detached, aber per ifconfig konnte ich die manuell erstmal wieder binden.
Es werden dann vier Gateways in OPNsense angelegt, für jedes habe ich eine dedizierte Monitoring-IP hinterlegt und das "Allow default gateway switching" aktiviert.
Dann habe ich alle VLANs wie folgt konfiguriert:
    IPv4 als statisches Netz 192.168.x.1/24
    IPv6 als statisches Netz fd00:x::1/64
DHCPv6 habe ich in OPNsense nicht aktiviert, aber den RA-Modus auf Unmanaged gestellt. Zusätzlich habe ich unter NPTv6 jeweils für Glasfaser und LTE für jedes IPv6-ULA-Netz einen Eintrag erstellt.

Alles einmal gebootet (die detached IPv6 wieder gebunden). Endgeräte haben eine fd00-Adresse erhalten. IPv4 und IPv6 Traffic lief fein. Habe dann vom Glasfaser das Kabel gezogen. Oh wunder, der Traffic lief weiter. Ich habe mich schon tierisch gefreut.
Dann habe ich das LAN-Kabel wieder ins Glasfasermodem gesteckt und der Ärger ging weiter. IPv4 hat sich schnell gefangen und lief. Glasfaser hat zwar eine neue IPv6 bekommen, aber OPNsense schien damit nicht richtig umgehen zu können, es lief dann gar nichts mehr über IPv6. Entweder hängt es mit dem detached-Problem zusammen, oder NPTv6 konnte damit nicht umgehen, ggf. irgendwelche alten Cache-Einträge, oder OPNsense selbst hatte ne Macke, denn in der GUI war auch noch die alte IPv6 zu sehen. Nach einem manuellen delete und create über ifconfig hatte die GUI wenigstens die neue IP, aber dpinger hat sich immer noch an die alte IPv6 gebunden und ließ sich auch nicht beenden oder neustarten. Außerdem fing die OPNsense dann irgendwann an, den RAM komplett auszulasten und war nur noch schwer erreichbar, total spooky. Da war kein Prozess zu finden, der das in Anspruch hat, war einfach verbraucht:
mem_gap_vm:  +   6313377792 (   6020MB) [ 78%] Memory gap: UNKNOWN

Aktuell bin ich ziemlich genervt von allem. Habe LTE wieder deaktiviert und die funktionierende Config mit Glasfaser-Tracking für die VLANs wieder aktiv, so dass ich wenigstens mit den GUAs wieder arbeiten kann.
Ich verstehe von IPv6 auch einfach noch nicht genug und mir ist klar, dass ich hier die IPv4-Techniken nicht auf IPv6 übertragen darf und IPv6 anders konzipiert ist (danke für den Draft-Link, aber ich muss das hier erstmal verdauen), aber etwas enttäuscht bin ich schon, dass das alles so nicht funktioniert, auch wenn das Setup einfach scheint. Klar könnte man den Schuldigen bei der Telekom suchen: Warum kein statisches Präfix für Glasfaser? Warum kein /56er für LTE, zumal ich meine Karte als Datenkarte bestellt habe...

Oder ist OPNsense einfach noch nicht so weit für mein Szenario (Failover mit/ohne dynamischem IPv6 Präfix)? Ideen sind willkommen.

I did some more tests. Simply adding the IPv6 to the interface on CLI one more time manually did the trick:

Code Select Expand

ifconfig pppoe0 inet6 2003:a:b:d:2d0:b4ff:fe01:a913/64

Then it is not in detached state anymore and trace route does work too:

Code Select Expand

# traceroute6 -s 2003:a:b:d:2d0:b4ff:fe01:a913 2001:4860:4860::8888
bind: Can't assign requested address
# ifconfig pppoe0 inet6 2003:a:b:d:2d0:b4ff:fe01:a913/64
# traceroute6 -s 2003:a:b:d:2d0:b4ff:fe01:a913 2001:4860:4860::8888
traceroute6 to 2001:4860:4860::8888 (2001:4860:4860::8888) from 2003:a:b:d:2d0:b4ff:fe01:a913, 64 hops max, 28 byte packets
1  2003:0:8707:3800::1  1.209 ms  1.253 ms  4.544 ms
[...]

After some seconds, the monitoring status in OPNsense GUI changed to green status. Doing multiple tests, this doesn't seem to work very stable. The status is flappening sometimes.
Nevertheless, now we've to find out why this happens and how to prevent this (i.e. find a workaround). But the problem is, that this is a dynamic IPv6 address provided by ISP.

Just for testing, I've disabled request for /56 subnet on FIBER interface (so it gets the /64 from the ISP for itself only) and removed all IPv6 trackings on VLANs, but no change.