Messages

Understand. It will kill the process hard.

Well, this will obviously help.

But I guess the better way would be to fix the reason instead of the symptoms.

However, some AI suggested to switch for ddclient the backend to "native" instead of "DynDNS-Client" (at DynDNS --> Settings --> Global Settings). I did and will monitor if it helps.

Hi,

I noticed the following behaviour now twice:
Update is set to "automatically" including reboot

• At some stage I realize my Nginx is not working any more
• Checking logs shows, Nginx has been stopped by update but never started again because OPNSense itself wants to reboot (The web-GUI tells me "System is rebooting" on the firmware tab)
• Trying to reboot manually through any way (GUI, SSH) does not work. System stays online
• Checking on console shows pkill is waiting for the ddclient to end. Which does not happen. So reboot stops and waits for ddclient.
• Killing ddclient with kill -9 PIDOF immediately reboots the system properly

Code Select Expand

root@router:~ # ps ax| grep 43968
43968  -  Is       0:02.34 ddclient - sleeping for 10 seconds (perl)
51212  -  I        0:00.00 pwait -op 43968
53945  -  I        0:00.00 pwait -op 43968
17700  0  I+       0:00.00 pwait -op 43968
 6279  1  S+       0:00.00 grep 43968
root@router:~ # kill -9 43968
root@router:~ #                                                                               
*** FINAL System shutdown message from root@router.knebb.de ***             

System going down IMMEDIATELY                                                 

Anyone having an idea how to prevent this or to fix ddclient?

Thanks!

/KNEBB

Moin,

Du hast recht, ich bin in manchen Bereichen über's Ziel hinausgeschossen. Und ja, es war `traceroute`gemeint, nicht `tcpdump`. Mein Fehler.

Und ja, der OT ghostet uns wohl- aber deshalb hatte ich das ja auch noch ergänzt. Um die (ziemlich sichere) Lösung für das Problem zu posten.

/KNEBB

Moin,

an dem Setup ist nichts falsch- fast keiner der bisherigen Antwortenden hat das erkannt.

1. Die Regel erlaubt nur TCP. `tcpdump` ist aber UDP. Und `ping` ist ICMP. Kann nicht gehen, werden beide auf dem Hinweg blockiert.
2. Der erste `tcpdump` auf das LANGw der OpnSense ist erfolgreich, weil die Sense das Paket zuerst einmal als "eingehend" erkennt (und nicht als weiteleiten an LAN) und bereits antwortet, bevor die Regeln angewendet werden. Das liegt daran, dass sie selbst ja das LLAN-Gateway ist und damit ist ihr auch egal, in welchem Netz das LAN-Gw hängt. DEshalb antwortet sie auch mit ihrer LAN-IP. ISt also auch richtig soweit.
 3. Die IP-Ranges (/24er Maske angenommen) passen, auch wenn das LAN das normalerweise verwendete LAN der Fritz! ist. Sofern das sauber durchkonfiguriert ist, gibt es keinen Grund, das nicht zu werwenden.


Also: Regel um TCP&ICMP ergänzen, dan nerneut testen. Sollte eigentlich danach schon funktionieren.

[mDNS:]

Moin,

ganz ehrlich? Aus Deinem Text entnehme ich, dass Du zumindest teilweise von dem Thema überfordert bist und/oder Dich noch nicht damit beschäftigt hast.

Von der Wortwahl her sind viele Sachen sehr laienhaft ausgedrückt ("VLANs die an einem Transfernetz (via HP-1810 Switch) angeschlossen sind" - VLANs brauchen einen Router, nur mit einem Switch können sie nicht miteinander kommunizieren, aber das Bild zeigt ja, dass es richtig ist...).

So ganz ist mir auch nicht klar, wo Dein Problem liegt (Wortwahl...).

Dennoch ein paar Sachen:
mDNS:
Drucker via Netzwerkgrenzen über mDNS anzusprechen ist ...ähmmm.... Mist! mDNS ist per Konzept nur für das lokale Netz (VLAN) konzipiert, wenn Du Dich über diese Grenzen hinwegsetzen willst, brauchst Du auf JEDEM Router so etwas wie einen mDNS Reflector / Repeater. Sonst wirst Du nie von #264 aus einen Drucker in irgendeinem anderen Netz sehen.
Mal abgesehen davon- wofür baut man eine Failover-Firewall, um dann mDNS durchzuschmuggeln???? Ja, als Konzeptarbeit akzeptabel, Sinn dieser Konstruktion sucht man besser woanders...
IPv6:
Hier wirst Du um intensives Einlesen nicht drumherum kommen. Grundsätzlich bewerte ich Deine Aussage "spezielle Firewall Einstellungen" auch eher als grenzwertig. Nein, braucht man nicht. IPv6 KANN so eingerichtet werden, dass die Systeme "von außen" direkt erreichbar sind. Das geht auch mit IPv4 (sofern man öffentliche Adressen besitzt). In beiden Fällen braucht man eine saubere Firewallkonfiguration, um unerwünschten Gästen den Zugriff entsprechend zu verwehren....

Du brauchst kein Tutorial, das mDNS, VLANs und IPv6 behandelt. Du brauchst ein Verständnis, was ist:
-VLAN (Broadcast-Domain, abgeschlossen, Anbindung via Router; egal ob IPv4 oder IPv6)
-mDNS (innerhalb einer Broadcast Domain, nicht ideal darüber hinaus)
-IPv6 ("nur" eine andere Variante von IPv4, Grundzüge bleiben bestehen)

Die VLANs scheinen grundsätzlich brauchbar konfiguriert zu sein (wenn ich auch nicht weiß, wo und wie Du den DHCP-Server eingerichtet hast....). Router trennen diese VLANs ab. mDNS (ich hwiederhole mich...) macht über VLANs hinweg nicht wirklich Sinn, zumal Du ja das Ganze sogar über zwei Router und ein Transfernetz (10.128.0.0/24) hinweg machen willst. Und IPv6 ist einfach ein wenig Fleißarbeit: lesen, lernen, verstehen. Wenn IPv4 wirklich (!) verstanden ist, ist IPv6 auch machbar.

Bei KONKRETEN Problemen gerne noch mal nachfragen.

/KNEBB

Hi,

I guess I have the same issue here. My Wireguard clients connect fine to my OPNSense VPN. They can easily do everything with the hosts on the remote LAN. So Wireguard --> LAN is fine.

But as soon as those clients (happens on a Mac as well as on an iPad) have established the VPN connection they do not have access to the Internet.

I guess there is a rule missing but I do not know which rule I have to add. I have allowed all traffic in the Wireguard interface to everywhere. But no good.

So which rule on which interface do I have to add? Might this be related to outgoing NAT? I set it to fully automated...

Anyone a hint for me (and the OP I assume)?

Thanks!

/KNEBB

Mea culpa!

In der OPNSense Gegenstelle war der Pub-Key der OPNSense eingetragen, nicht der PubKey des iPads...


Ok, ich komme jetzt auf die Geräte im LAN (zB ping).

Trotzdem danke an alle, die sich das durchgelesen haben

Moin,

wahrscheinlich bin ich zu verkopft. Aber irgendwie kriege ich es nicht hin, mein iPad mit meiner WireGuard-Instanz zu verbinden. Helft mir bitte auf die Sprünge...

Was habe ich getan:

• In OPNSense Wireguard VPN aktiviert. Funktioniert auch grundsätzlich (z.B. mit einem MacBook)
• Über Gegenstellen-Generator einen Gegenstelle generiert
• Den QR Code. dort mit der WireGuard App auf dem iPad gescannt - gültige Konfig!
• Eine neue Gegenstelle unter Gegenstellen mit dem Priv/Pub Keys aus dem vorherigen Schritt erstellt
• Auf dem iPad mit dem Hotspot des Handys verbunden
• VPN WireGuard App - Tunnel aktiviert
• Unter OPNSense- VPN- Wireguard - Status ist der Status der Gegenstalle iPad GRÜN
• Kein ping, kein Traffic, kein garnix vom iPad möglich....
• Keine Einträge in der Protokolldatei

Ich muss doch irgendwie rausbekommen, was da falsch ist.... irgendjemand eine Idee?

/KNEBB

Das (alte) Menü wird ja dann bestimmt auch irgendwann wegfallen. Migration hat wunderbar geklappt, aber jetzt habe ich natürlich zwei Einträge im Menü: "Rules [new]" und "Regeln".

Ja, ist absolut nicht wichtig aber weiß jemand die Roadmap, wann das wieder "ordentlich" aussieht, also richtige Sprache und keine zwei Einträge, wenn das eine überflüssig ist?

/KNEBB

Jo, haste recht. Die Fritzbox 6660 ist aber normalerweise eine "Cable". Da ist es nicht ganz so trivial, die OPNSense mit Ethernet an das Koax-KAbel zu kriegen...

Aber letzendlich wird das hier jetzt akademisch- ich denke, die ThomasKrenn Kiste tut es für den Zweck wunderbar und liegt noch unter 50% des Budgets.

Sie macht kein PPPoE- da hängt ihrer Beschreibung nach eine Fritzbox davor. Also: passt!

Also für eine OPNSense Firewall scheint mir das Teil genial zu sein!
4x Intel NIC.

4GB RAM reichen für normale Anwendungen locker aus!

Und auch die CPU macht es an einem Glasfaseranschluß problemlos- solange man da kein intensives VPN macht! Aber zum rumspielen mit VPN reicht auch das!

Also, das scheint mir eine ideale Preis/ LEistungskombi zu sein.

120€ sind fast unschlagbar. (Aufpassen, TK schreibt nur Nettopreise hin, ist halt für Geschäftskunden)

Ich selbst nutzt den LES 2x- ein geniales Teil. Allgemein sind die TK Kisten von sehr guter Qualität. Haben meist aber auch ihren PReis.

Moin,

also grundsätzlich geht es? Es ist nur lahm? Nur messbar oder tatsächlich fühlbar langsamer?

MAch' nochmal einen Bandbreitentest und schau Dir die OPNSense Auslastung währenddessen an (GUI oder Konsole "top"). Ist da etwas auffälliges?

Du hast noch einen anderen Router? Dann versuche doch mal das Folgende:
Anderer Router anklemmen, OPNSense kommt an dessen lokales Interface. Alle anderen Systeme weiterhin in das LAN der OPNSense. Dann nimmst du einen Rechner und testest mal wieder die Bandbreite via OPNSense-Router-Internet und einmal direkt im LAN des Routers: Router-Internet.
Gibt es da massive Unterschiede?
Warum so testen? Durch die notwendige Umkonfiguration des WAN Interfaces der OPNSense schließen wir evtl. Mißkonfigurationaus, ebenso wie Probleme mit dem Provider.
Wenn beides gleich schnell ist, müssen wir uns die WAN-Konfiguration der OPNSense anschauen.
HAben wir einen deutlichen Speed-Unterschied, liegt es tatsächlich an einer Misskonfioguration deR OPNSesnse.

Also? Wie ist das Ergebnis des Testes?

/KNEBB

Schließe mich den Vorrednern an,

allerdings wissen wir zu wenig über Eure Struktur, um konkrete Fehleranalysen machen zu können.

Eine weitere Möglichkeit ist es, dasss Du die beiden Interfaces vertauscht hast...sei es physikalisch oder über die Schnittstellenzuordnung.

Habt ihr denn überhaupt ein getrenntes LAN? Oder ist das alles ein flaches Netz, auch über die externe Anbindung hinaus? Wer stellt denn aktuell den DHCP-Server?

Fragen über Fragen, ohne DEtails läßt sich da nicht viel helfen.

/KNEBB

[Aaaaber:]

Moin!

Du kannst natürlich vieles machen. Und auf den erstetn BLick habe ich jetzt keinen Punkt gesehen, der sofort ein "geht nicht" ausgelöst hätte.

Aaaaber:

Mache eines nach dem Anderen. Wenn ein es sicher, stabil und zuverlässig läuf, nimm das nächste in Angriff. Nicht alles auf einmal. So wie ich Dich aufgrund des Postes einschätze solltes Du ca. ein Jahr einplanen, bis Du alles aus der Liste umgesetzt hast!

Ein paar Tipps zur Reihenfolge:

• Tatsächlich zuerst die VLANs einrichten. Mit Firewall-Regeln etc. hast Du genug zu tun, bis die Netze auch untereinander wirklich so getrennt sind, wie Du das willst. Server, NAS etc. kommen ins gleiche VLAN wie die Clients. Üblicherweise da auch Tablets, Handys etc. Alles, was IoT ist und "nach Hause telefoniert" geht ins VLAN IOT. GästeVLAN ist eine gute Idee, macht aber nur Sinn, wenn Du da kein Passwort hast (oder das ganz einfach via QR-Code o.ä. den Gästen mitteilen kannst. Wenn man eh' ein Passwort fragen muss, kann man auch gleich das vom "richtigen" Netz geben --> wird sind alle menschlich. Ich habe mein Gäste-(V|W)LAN hier wieder abgeschafft.
• Dann gerne Unbound als WErbefilter- und sehen, ob der die gewnschte Unterscheidung nach VLAN macht (glaube nicht!)

Das würde ich tatsächlich so umsetzen. Die folgenden Sachen würde ich ganz sein lassen, das ist oft mit Kanonen auf Spatzen geschossen:

• IDS und IPS. Die Einrichtung UND Überwachung frißt wahnsinnig viel Zeit und lohnt sich in den seltensten Fällen (99% fake alarms)
• Radiusserver. Dafür brauchst Du ein zentrales Benutzerverzeichnis (LDAP, AD,...). Auch hier das Gleiche: Riesenaufwand, auch mit der Pflege, lohnt sich für Heimanwender nicht

Und dann kommen noch die VPN-Sachen:

• Net2NEt-VPN zu den Eltern. Nicht ganz trivial aufzusetzen, da Du beide Geräte konfigurieren musst (Fritz! und OPNSense) und jede ein wenig einen anderen UI-Dialekt hat... musst Du hier nachlesen, klappen sollte das. Und: einmal eingerichtet, läuft das stabil
• RoadWarrior-VPN: Am besten mit Wireguard umsetzen, das funktioniert echt gut und für viele Geräte (Tablets, etc. gibt es auch eigene WireguardApps). Ist aber grundsätzlich ein wenig "Fummelei" und erfordert wirkliches beschäftigen mit der Materie.

Bei den wenigen VPN-Nutzern sollte die CPU das gut schaffen, zu den anderen Server/LAN-Fragen sage ich mal nichs, ist hier etwas off-Topic.

Also, Fahrplan:
-OPNSense installieren (sofern noch nicht gemacht), im bestehenden LAN schauen wie sie so funktioniert und nur absolute Basiskonfiguration machen.
-VLANs trennen, Geräte entsprechend dorthin verschieben
-RoadWarrior VPN einrichten
-NEt2NEt VPN einrichten
Mit ausgibigem Testen und dem Erleben in der Praxis rechne mal pro Punkt 2-3 Monate. Nicht das erstmalige Einrichten, aber das Testen in der Praxis...

/KNEBB