Messages

[Was sollte ich als nächstes machen, um das Problem in den Griff zu bekommen?]

Hallo zusammen,

keine Ahnung warum, aber ich kämpfe aktuell mit dem Problem, dass der OpenVPN-Server meiner OPNsense nach kurzer Zeit immer wieder folgendes Problem bekommt:

Code Select Expand

Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)

Klar kann ich notfalls per SSH auf die Kiste gehen und dann per:

Code Select Expand

ps auxwww | grep openvpn

den OpenVPN-Prozess suchen und dann 'killen' – und danach lässt sich der OpenVPN-Server auch wieder problemlos per GUI neu starten – aber das ist ja nicht normal und nützt mir vor allem nichts, wenn ich unterwegs bin...

Das Problem hatte ich schon beim frisch installierten 23.7 und nun leider auch weiterhin mit der aktuellen 24.1.

Ich hatte den OpenVPN-Server heute 1x entfernt und per "Wizard" noch einmal neu angelegt, aber auch das brachte keine Abhilfe.

Was sollte ich als nächstes machen, um das Problem in den Griff zu bekommen?

Ok, das mit OpenVPN und DCO klingt sehr spannend, aber da gibt es wahrscheinlich noch kein passendes tutorial speziell für OPNsense, weil es leider noch nicht soweit ist (sondern erst ab 24.7 und FreeBSD 14)?

Welche Geschwindigkeit?

100, 100 und 50 Mbps synchron

Wie sind die die Standorte bei Euch Internetmäßig verbunden?

Zwei sind per Glasfaser angebunden, beim dritten Standort muss ich erst mal nachfragen.

PS: Auch der dritte Standort ist per Glasfaser angebunden. Insoweit also optimale Ausgangsbedingungen.

Mit AES-256 und AES-NI CPU Unterstützung beschleunigt die Verschlüsselung und Entschlüsselung ungemein.

Ok, das ist natürlich auch ein Punkt, der neben deinen anderen aufgeführten Punkten dann doch eher für IPsec spricht.

Weiß zufällig jemand, ab wann mit nativer CPU-seitiger ChaCha20-Poly1305 Unterstützung zu rechnen ist?

Gibt es schon CPUs, die das können? Oder sind zumindest Generationen angekündigt, die das dann unterstützen werden?

Danke, na das klingt doch schon mal nicht schlecht.

Im Hardware-Shop von Deciso https://shop.opnsense.com/product-categorie/hardware-appliances/ wird der maximale VPN-Durchsatz leider immer nur für IPsec angegeben.

Mit Wireguard sollte man da dann aber sicher ähnliche (wenn nicht sogar bessere) Werte erreichen, oder?

Zum Beispiel: IPsec VPN Throughput (AES256GCM16) mit 1.2 Gbps

Speziell zum Wireguard-Durchsatz konnte ich leider bisher keinerlei Infos finden...

Hallo zusammen,

über viele Jahre sind hier drei Standorte eines Kollegen per LANCOM IPsec miteinander verbunden – das lief wirklich immer zu 100% stabil und zuverlässig.

Er möchte diese in die Jahre gekommenen LANCOM-Geräte nun gern durch etwas neues ersetzen und mein Vorschlag wäre, dafür dann drei OPNsense-fähige Geräte von Deciso zum Einsatz zu bringen.

Dazu würde ich sehr gern auch Wireguard statt IPsec für die Standortvernetzung nutzen – jetzt wo ab OPNsense release 24.1 ein FreeBSD 13.2 inkl. "wireguard kernel module" zum Einsatz kommt, sollte das doch stabil und zuverlässig seinen Dienst tun?

Oder wäre eine Standortvernetzung per klassischen IPsec-VPN doch noch die zuverlässigere Wahl?

Ich persönlich nutze seit Jahren immer nur OpenVPN (allerdings auch immer nur 'road warrior' da ich Site-2-Site bisher nie benötigte).

Zu Wireguard höre ich sehr viele unterschiedliche Meinungen, manche schwören darauf, aber auch nicht wenige haben bzw. hatten damit so ihre Probleme... deshalb meine Bitte um Eure Einschätzung.

[Noch ein paar Ergänzungen:]

Ok, ich glaube ich kann hier "Entwarnung" geben.

Es lag wohl eine Störung beim Kabelanschluss (PYUR, ehemals Tele Columbus) vor.

Das Modem hat jetzt vom Support neue Daten geschickt bekommen und wurde 1x neu gestartet und bisher gibt es erst einmal keine Aussetzer mehr.

Noch ein paar Ergänzungen: Nach knapp 40 Minuten gab es dann leider doch wieder Aussetzer. Ein erneuter Anruf beim PYUR-Support brachte dann das Ergebnis, dass ich die FRITZ!Box 6660 Cable 1x vom Strom trennen und kurz warten und dann wieder anschließen sollte.

Gleichzeitig startete der Support-Mitarbeiter dann wohl eine erneute Provisionierung. Es dauerte dann nach dem Neustart der FRITZ!Box auch gute 10 Minuten, bis wirklich wieder ein stabiles Signal anlag. Aber seitdem nun seit über einer Stunde kein einziger Aussetzer mehr.

Der Techniker wies mich außerdem noch darauf hin, dass es im Gegensatz zur Telekom oder Vodafone bei PYUR wohl Probleme gibt mit dem 'automatisierten einspielen' von Updates (nicht der Firmware, sondern anderer Anpassungen). Deshalb war seine Empfehlung, so eine FRITZ!Box von PYUR alle 11 Tage für mind. 10 Sekunden komplett vom Strom zu nehmen, denn nur dann werden diese Updates wohl 'forciert'...

Erinnert mich ein wenig an "TAE-Stecker aus der DSL-Dose ziehen und mind. 30 Minuten warten", da nur dann "im Kasten auf der Straße eine Art 'Reset' des Anschlusses ausgeführt wird".

[Hoffe mit Eurer Hilfe herausfinden zu können, was genau da das Problem sein könnte. Vielen Dank also im Voraus für Vorschläge und Ideen!]

Hallo zusammen,

habe mir am Wochenende OPNsense auf neuer Hardware installiert (aktuelle Version 23.7.12).

Die OPNsense steht hinter einer Kabel-Fritzbox und ist dort als 'exposed host' eingetragen.

Grundsätzlich läuft alles so wie es soll (OpenVPN-Server, LE-certs dank ACME, DynDSN, ein paar wenige IP-Table Aliase wie z.B. FireHOL Level 3 als 'blocklist' in den Firewall-Regeln), aber:

Es gibt immer wieder eigenartige 'Aussetzer' im Netzwerk (beginnt meist nach ca. 10-20 Minuten), die ich mir leider überhaupt nicht erklären kann.

Anbei ein Beispiel mit Ping auf die 1.1.1.1:

Code Select Expand

64 bytes from 1.1.1.1: icmp_seq=1141 ttl=58 time=10.472 ms
64 bytes from 1.1.1.1: icmp_seq=1142 ttl=58 time=14.014 ms
64 bytes from 1.1.1.1: icmp_seq=1143 ttl=58 time=9.114 ms
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 21d1   0 0000  3f  01 480c 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1145
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 9307   0 0000  3f  01 d6d5 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1146
64 bytes from 1.1.1.1: icmp_seq=1147 ttl=58 time=15.897 ms
64 bytes from 1.1.1.1: icmp_seq=1148 ttl=58 time=8.566 ms
64 bytes from 1.1.1.1: icmp_seq=1149 ttl=58 time=13.981 ms
64 bytes from 1.1.1.1: icmp_seq=1150 ttl=58 time=11.666 ms
64 bytes from 1.1.1.1: icmp_seq=1151 ttl=58 time=12.790 ms
64 bytes from 1.1.1.1: icmp_seq=1152 ttl=58 time=10.358 ms
Request timeout for icmp_seq 1153
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 8d63   0 0000  3f  01 dc79 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1154
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 143b   0 0000  3f  01 55a2 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1155
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 dde7   0 0000  3f  01 8bf5 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1156
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 b015   0 0000  3f  01 b9c7 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1157
64 bytes from 1.1.1.1: icmp_seq=1158 ttl=58 time=10.620 ms
64 bytes from 1.1.1.1: icmp_seq=1159 ttl=58 time=7.852 ms
64 bytes from 1.1.1.1: icmp_seq=1160 ttl=58 time=13.867 ms
64 bytes from 1.1.1.1: icmp_seq=1161 ttl=58 time=10.446 ms
64 bytes from 1.1.1.1: icmp_seq=1162 ttl=58 time=7.988 ms
64 bytes from 1.1.1.1: icmp_seq=1163 ttl=58 time=9.279 ms
64 bytes from 1.1.1.1: icmp_seq=1164 ttl=58 time=8.096 ms
64 bytes from 1.1.1.1: icmp_seq=1165 ttl=58 time=9.095 ms
Request timeout for icmp_seq 1166
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 34db   0 0000  3f  01 3502 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1167
92 bytes from opnsense (10.5.5.1): Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 5400 d76f   0 0000  3f  01 926d 10.5.5.198  1.1.1.1

Request timeout for icmp_seq 1168
64 bytes from 1.1.1.1: icmp_seq=1169 ttl=58 time=15.543 ms
64 bytes from 1.1.1.1: icmp_seq=1170 ttl=58 time=12.610 ms
64 bytes from 1.1.1.1: icmp_seq=1171 ttl=58 time=7.752 ms
64 bytes from 1.1.1.1: icmp_seq=1172 ttl=58 time=9.180 ms
64 bytes from 1.1.1.1: icmp_seq=1173 ttl=58 time=8.407 ms
64 bytes from 1.1.1.1: icmp_seq=1174 ttl=58 time=8.553 ms
64 bytes from 1.1.1.1: icmp_seq=1175 ttl=58 time=11.877 ms

Und irgendwie schwingen sich diese Aussetzer dann so hoch, dass es mit der Zeit immer schlimmer wird...

Hoffe mit Eurer Hilfe herausfinden zu können, was genau da das Problem sein könnte. Vielen Dank also im Voraus für Vorschläge und Ideen!

PS: Mit der alten Hardware (beide von Deciso) hatte ich diese Probleme überhaupt nicht. Und ich hatte das neue Gerät extra "frisch betankt" damit da auch wirklich nichts "verbastelt" ist an der OPNsense.

[Zenarmor]

I know this was already marked as solved, but the "PR_END_OF_FILE_ERROR" gave me also some nuts today, so I've found this thread and also got 'an idea' what's going wrong.

On my setup it wasn't a proxy server but Zenarmor.

It's very important to know – also if you 'whitelist' a domain in Services / BIND / Configuration / DNSBL / Whitelist Domains or Services / Unbound DNS / Blocklist / Whitelist Domains (or also in Adguard Home), Zenarmor could still block domains!

If you go to Zenarmor / Live Sessions / Blocks you will see all blocked domains -> here you can 'allow' the wrongly blocked hostname globally and also 'send this re-categorization as a feedback to Zenarmor Team to improve web categorization' if you want.

That's it. :)

# pkg remove php81-pecl-mongodb

Cheers,
Franco

Thank you Franco. :)

So it would be also safe to delete the content of:

Code Select Expand

/usr/local/lib/php/

which is:

Code Select Expand

20210902/ 20220829/ build/

?

Don't know why this php81-pecl-mongodb was installed at all...

The upgrade worked fine so far, but Zen Armor was not working and I've uninstalled all it's packages but still get this error from the Crash Reporter Status:

Code Select Expand

PHP Warning:  PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/local/lib/php/20220829/mongodb.so (Cannot open "/usr/local/lib/php/20220829/mongodb.so"), /usr/local/lib/php/20220829/mongodb.so.so (Cannot open "/usr/local/lib/php/20220829/mongodb.so.so")) in Unknown on line 0

Already did a:

Code Select Expand

opnsense-update -pf

but still get this message at the end:

Code Select Expand

Beep! Beep!
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: 100%
php81-pecl-mongodb has a missing dependency: php81

>>> Missing package dependencies were detected.
>>> Found 1 issue(s) in the package database.

pkg-static: No packages available to install matching 'php81' have been found in the repositories
>>> Summary of actions performed:

php81 dependency failed to be fixed

>>> There are still missing dependencies.
>>> Try fixing them manually.

Any ideas what to do?

Ok, war mir nicht bewusst, dass dies dann etwas Linux-spezifisches ist und so unter BSD nicht zur Anwendung kommt.

Hätte gedacht die "Basis" von AdGuardHome ist identisch bzw. dessen Bedienung/Einrichtung.

Das ist jetzt nur ein Schuss ins Blaue, aber ich berichte trotzdem mal, vllt. hilft es ja:

Ich betreibe AdGuardHome auf einem RPi 4 Model B mit Diet-Pi und hatte jetzt einige Zeit das Problem, dass AdGuardHome mit 100% CPU-Last lief, was letztlich natürlich auch zu Instabilitäten bzw. sehr trägen Reaktionen führte.

Nach einigem hin und her kam raus, dass direkt nach einem Neustart das 'service file' nicht korrekt angelegt wurde.

Du kannst ja per

Code Select Expand

systemctl is-active AdGuardHome

bzw. wenn Du im adguardhome-Verzeichnis bist per

Code Select Expand

./AdGuardHome -s status

prüfen, ob alles i.O. ist.

Bei mir gab es da dann eine Fehlermeldung (den genauen Wortlaut habe ich leider nicht mehr im Kopf).

Es half dann ein:

Code Select Expand

./AdGuardHome -s install

womit erfolgreich ein neues 'service file' angelegt wurde, und danach funktionierte dann auf Anhieb sowohl die Statusabfrage als auch die CPU-Last ging auf 0,xx runter.

PS: Einen Neustart habe ich bisher noch nicht gemacht, kann also durchaus sein, dass sich die Kiste nach einem Neustart wieder so verhält (100% CPU-Last), aber dann hilft wie gesagt AdGuardHome -s install

[System: Settings: General: DNS servers]

Hallo zusammen,

ich habe irgendwie einen "Knoten im Kopf" bezüglich meiner Netzwerk-Infrastruktur bzw. -Konfiguration.

Gleich vorweg: Das ganze ist als 'double nat' konfiguriert – "vorne" läuft eine Kabel FRITZ!Box mit der 10.89.89.1 und ein Pi mit AdGuard HOME mit der 10.89.89.11.

Dahinter existiert dann mein 'richtiges' Netz. Die OPNsense hat die 10.5.5.1 und mein iMac z.B. die 10.5.5.199.

Auf der OPNsense ist sowohl unter System: Settings: General: DNS servers als auch in BIND unter Services: BIND: Configuration: DNS Forwarders ausschließlich die 10.89.89.11 als DNS-Server definiert (also AdGuard HOME).

Unter Services: DHCPv4: [LAN]: DNS servers habe ich die 10.89.89.11 (AdGuard HOME) und die 10.5.5.1 (OPNsense) eingetragen, als Domain name und Domain search list außerdem meine DynDNS-Domain (für die mir der ACME Client der OPNsense im übrigen auch erfolgreich Let's Encrypt Zertifikate ausstellt).

Da ich mir bisher nicht anders zu helfen wusste, habe ich im AdGuard HOME bei den sogenannten "DNS rewrites" den einzelnen Gerätename IPs zugeordnet, also z.B. der Domain adguard.meine.dyndns.domain die 10.89.89.11, so dass ich AdGuard Home mit LE-cert unter https://adguard.meine.dyndns.domain erreichen kann.

Das klappt soweit auch alles gut, also z.B. auch mit meinem NAS unter nas.meine.dyndns.domain (was dann z.B. dank dieses AdGuard DNS rewrites auf die 10.5.5.11 zeigt).

Was leider aber nicht funktioniert in meiner Konstellation sind die "Private reverse DNS servers" bei AdGuard HOME.

Deshalb würde ich das gern BIND machen lassen – wie oben bereits erwähnt übergebe ich ja per DHCP nicht nur den AdGuard HOME als DNS-Server sondern eben auch die OPNsense.

Wenn ich es richtig verstanden habe, muss ich dass unter Services: BIND: Configuration: Master Zones definieren?

Da die interne DNS-Auflösung dank dieser speziellen "DNS rewrites" von AdGuard HOME auch schon "in die eine Richtung" korrekt arbeitet (also zu jeder definierten Domain die dazu passende interne IP kennt) brauche ich jetzt theoretisch nur noch eine 'reverse zone', damit ich ein schönes:

Code Select Expand

host imac.meine.dyndns.domain
imac.meine.dyndns.domain has address 10.5.5.199
host 10.5.5.199
199.5.5.10.in-addr.arpa domain name pointer imac.meine.dyndns.domain.

erhalte und nicht wie jetzt aktuell

Code Select Expand

host imac.meine.dyndns.domain
imac.meine.dyndns.domain has address 10.5.5.199
host 10.5.5.199
Host 199.5.5.10.in-addr.arpa. not found: 3(NXDOMAIN)

Meine Frage lautet also: Wie genau muss ich diese "Master Zones" von BIND definieren, damit auch die Auflösung der internen IPs zu Ihren Domainnamen funktioniert?

Vielen Dank im Voraus für Eure Unterstützung.

PS: Sicher macht es außerdem Sinn, das dann gleich korrekt "in beide Richtungen" beim BIND zu definieren, so dass es auch funktioniert, falls die "DNS rewrites" des AdGuard HOME mal nicht korrekt funktionieren sollten?