Messages

Ich betreibe OPNsense 26.1.8 als VM auf einem Proxmox-Cluster. Ich nutze Proxmox SDN zur VXLAN-Separierung, aber jedes VXLAN nutzt zum Routing die OPNsense als Gateway. Die VXLANs sind als separate NIC der VM zugewiesen. Dahinter hängt u.a. ein Reverse Proxy und entsprechende Backend-Webserver. Auf dem Cluster ist aktuell noch sehr wenig los (vllt. 10-20 Web-Requests pro Minute). Mein Monitoring zeigt absolut keine Engpässe im Netz, I/O, RAM oder CPU.

Dennoch habe ich das Phänomen, dass sporadisch mal ein Request ins Leere läuft und der NGINX Reverse Proxy ein "Upstream timed out" liefert. Ich suche seit 2 Tagen, finde aber nichts. Ich habe hier ein paar TCP-Dumps:

Auszug vom Reverse Proxy (VXLAN 100) an den Backend-Webserver:

Code Select Expand

18:50:17.421126 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421142 ens18 Out IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421156 ens18 Out IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.422313 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.422313 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443384 ens18 Out IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1310,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443661 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1250,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467279 ens18 Out IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467319 ens18 Out IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467991 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.468006 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:18.445100 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156709672 ecr 0,nop,wscale 7], length 0
18:50:19.469188 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156710696 ecr 0,nop,wscale 7], length 0
18:50:20.493198 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156711720 ecr 0,nop,wscale 7], length 0
18:50:21.517175 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156712744 ecr 0,nop,wscale 7], length 0
18:50:22.541211 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156713768 ecr 0,nop,wscale 7], length 0
18:50:24.557198 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156715784 ecr 0,nop,wscale 7], length 0
18:50:28.589203 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156719816 ecr 0,nop,wscale 7], length 0
18:50:29.280604 ens18 Out IP 10.100.100.11.53162 > 10.130.130.22.80: Flags [S], seq 1555195113, win 65500, options [mss 1310,sackOK,TS val 2156720507 ecr 0,nop,wscale 7], length 0
18:50:29.282278 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.53162: Flags [S.], seq 1424688371, ack 1555195114, win 64900, options [mss 1250,sackOK,TS val 517547205 ecr 2156720507,nop,wscale 7], length 0
18:50:36.781185 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156728008 ecr 0,nop,wscale 7], length 0
Auszug vom Backend-Webserver (VXLAN 130):

Code Select Expand

18:50:17.421666 ens18 In  IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421667 ens18 In  IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421686 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.421698 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443620 ens18 In  IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1250,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443627 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1310,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467778 ens18 In  IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467778 ens18 In  IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467783 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.467789 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
Auszug der OPNsense auf dem eingehenden Interface (VTNET3) vom Proxy:

Code Select Expand

18:50:17.421192 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421195 IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421221 IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421614 IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.421732 IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443290 IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1310,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443518 IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1250,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467166 IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467203 IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467844 IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.467853 IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:18.445247 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156709672 ecr 0,nop,wscale 7], length 0
18:50:19.469327 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156710696 ecr 0,nop,wscale 7], length 0
18:50:20.493431 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156711720 ecr 0,nop,wscale 7], length 0
18:50:21.517424 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156712744 ecr 0,nop,wscale 7], length 0
18:50:22.541471 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156713768 ecr 0,nop,wscale 7], length 0
18:50:24.557380 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156715784 ecr 0,nop,wscale 7], length 0
18:50:28.589278 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156719816 ecr 0,nop,wscale 7], length 0
18:50:36.781171 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156728008 ecr 0,nop,wscale 7], length 0
Sowie auf dem ausgehenden Interface (VTNET6) der OPNsense Richtung Backend-Server:

Code Select Expand

18:50:17.421218 IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421225 IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421599 IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.421729 IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443307 IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1250,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443514 IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1310,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467177 IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467207 IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467842 IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.467851 IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
Es ist "wunderschön" zu sehen, dass der Request vom Proxy mit dem Ephemeral Port 40758 zwar den Proxy verlässt, auch an der OPNsense ankommt, diese aber nicht mehr verlässt. Auch das Retry/Retransmission wird nicht von der OPNsense beantwortet bzw. geroutet.

In dem Fall handelte es sich bei dem gescheiterten Request um ein klitzekleines SVG-Bild, dass beim Abruf einer Webseite mit ausgeliefert wird. Das Problem tritt auch nachts auf, wo noch weniger los ist. Keepalive im Reverse Proxy ist im Einsatz. Wer kann helfen und erklären, warum hier intern Pakete verloren gehen!?

Ich schau gleich mal in deine Doku, aber es handelt sich um ein aufgebuchtes Subnetz auf dem vSwitch. Das ist explizit dafür gedacht, dass es *kein* MAC-Binding hat und das Subnetz im Bridged Mode unter Proxmox verwendet wird. Die MAC vergibt hier ja auch Proxmox, erklärt also in meinen Augen nicht, warum es Unterschiede zwischen Debian und OPNsense gibt. Ich hoffe ja noch, da ich das Setup brauche und habe daher zwei weitere VMs aufgesetzt. Eine aktuelle OPNsense mit anderem Netzwerk-Treiber und eine ältere OPNsense 24.1. Mal schauen...

Und BTW würde ich da eine deutlich zeitigere Reaktion von Hetzner erwarten, als 2h40m. I.d.R reagieren die ja dann auch mit Abuse-Meldungen. Ist ja hier auch nicht der Fall.

[Was macht OPNsense/FreeBSD also bei der Verwaltung einer einfachen IP anders als Debian?]

Ich betreibe einen Proxmox-Cluster (PVE 9.1) an einem Hetzner vSwitch. Der vSwitch stellt im VLAN 4000 ein IPv4 Subnetz bereit. Darauf soll eigentlich ein OPNsense HA Setup laufen. Ich habe das ganze mehrfach aufgesetzt, Firewall kontrolliert (und teilweise deaktiviert zum Test). Die MTU wird von Hetzner mit 1400 vorgegeben, die habe ich auch an allen Interfaces (Host und OPNsense) kontrolliert und gesetzt.

Eine vollständig eingerichtete OPNsense (mit Regeln, mit Outbound NAT, mit Wireguard und mit CARP IPs) funktioniert prinzipiell. Selbst das Failover funktioniert grundsätzlich. Aber es gibt ein Problem. Ich habe jetzt tatsächlich als allerletzten Test eine weitere OPNsense als VM nur installiert und überhaupt nicht konfiguriert (also wirklich überhaupt nicht konfiguriert, außer der WAN IP) und trotzdem hat sie das folgende Problem.

In einem festen Zeitabstand, ca. alle 160 Minuten, verliert die IP (egal ob CARP IP oder die IP der OPNsense selbst) die Verbindung für 1-5 Minuten. Sie ist dann weder von außen anzupingen, noch kommen die dahinterliegenden VMs ins Internet. Ich lasse von extern mehrere Monitorings (PING) darauf laufen und sehe regelmäßig die Unterbrechungen. Ich finde das Problem einfach nicht. Jetzt kommt das Kuriose: Wenn ich in Proxmox bspw. eine Debian VM aufsetze und auch diese nicht weiter konfiguriere außer ihr eine IP aus dem Subnetz zu geben, dann hat diese *kein* Problem. Wir haben jetzt also eine Debian VM und ein OPNsense, beide in Ausgangskonfiguration nur mit einer Subnetz-IP und nur eine von beiden Maschinen - die Debian-VM - funktioniert.

Hetzner hat dahingehend kein Problem und der Support findet auch nichts. Es stellt sich jetzt die Frage: Was macht OPNsense/FreeBSD also bei der Verwaltung einer einfachen IP anders als Debian? Und wie kann ich das Verhalten abstellen? Ich bin kurz davor, das ganze Setup komplett aufzulösen, weil es seit Wochen instabil läuft.

Hier mal die interfaces eines PVE-Hosts:

Code Select Expand

auto lo
iface lo inet loopback

auto enp1s0f0np0
iface enp1s0f0np0 inet static
        # public server address
        address <IPv4>/32
        # route to default gateway
        post-up ip route add 88.190.120.1 dev enp1s0f0np0 scope link
        post-up ip route add default via 88.190.120.1
        pre-down ip route del default via 88.190.120.1
        pre-down ip route del 88.190.120.1 dev enp1s0f0np0
iface enp1s0f0np0 inet6 static
        address <IPv6>/64
        gateway fe80::1

auto enp1s0f1np1
iface enp1s0f1np1 inet static
        # ceph cluster interface
        mtu 9000
        address 192.168.1.11/24

auto vlan4000
iface vlan4000 inet manual
        # public subnets on vswitch
        vlan-raw-device enp1s0f0np0
        vlan-id 4000
        mtu 1400
iface vlan4000 inet6 manual

auto vmbr4000
iface vmbr4000 inet manual
        # bridge for routing subnets
        bridge-ports vlan4000
        bridge-stp off
        bridge-fd 0
        mtu 1400
iface vmbr4000 inet6 manual

auto vlan4010
iface vlan4010 inet static
        # proxmox cluster traffic
        vlan-raw-device enp1s0f0np0
        vlan-id 4010
        mtu 1400
        address 10.0.0.11/24

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).