1
22.7 Legacy Series / Re: CRON Not Starting due to phpmailer error. (SOLVED)
« on: July 31, 2022, 02:18:33 pm »
Thank you very much, that worked great! 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
22.7 Legacy Series / Re: CRON Not Starting due to phpmailer error. (SOLVED)
« on: July 31, 2022, 01:20:58 pm »EDIT SOLVED:I have the same problem with os-mail-backup.
I simply uninstalled PHPmailer from the command line and it also uninstalled os-mail-backup. Now the Cron starts with no errors.
Could you please post the command to uninstall PHPmailer via command line?
3
German - Deutsch / Re: VnStat startet nicht
« on: June 26, 2020, 10:37:40 am »
Problem gelöst!
/var lief in der RAM-Disk, somit wurde die vnstat.db beim Neustart stets gelöscht und musste manuell über den Reset-Button neu angelegt werden.
Daher System : Settings : Miscellaneous : Disk / Memory Setting -> /var RAM disk Haken raus nehmen und System neustarten
/var lief in der RAM-Disk, somit wurde die vnstat.db beim Neustart stets gelöscht und musste manuell über den Reset-Button neu angelegt werden.
Daher System : Settings : Miscellaneous : Disk / Memory Setting -> /var RAM disk Haken raus nehmen und System neustarten
4
German - Deutsch / Re: VnStat startet nicht
« on: April 30, 2020, 08:14:20 pm »
Leider muss ich den Beitrag noch einmal hervorholen.
Ich habe festgestellt, dass nach einem Neustart von OPNsense VnStat wieder nicht startet bzw. auch nicht auf der Kommandozeile starten lässt:
Erst nach erneuten Dücken des Reset-Buttons läuft der Service wieder. Dann sind aber leider auch alle gesammelten Daten weg.
Könnt ihr mir sagen, ob dies ein nomales Verhalten darstellt? Oder kann es daran liegen, dass ich das nano-Image einsetze?
Ich habe festgestellt, dass nach einem Neustart von OPNsense VnStat wieder nicht startet bzw. auch nicht auf der Kommandozeile starten lässt:
Code: [Select]
# /usr/local/etc/rc.d/vnstat restart
vnstat not running? (check /var/run/vnstat/vnstat.pid).
Starting vnstat.
Error: Failed to open database "/var/lib/vnstat/vnstat.db" in read/write mode.
Exiting...
/usr/local/etc/rc.d/vnstat: WARNING: failed to start vnstat
Erst nach erneuten Dücken des Reset-Buttons läuft der Service wieder. Dann sind aber leider auch alle gesammelten Daten weg.
Könnt ihr mir sagen, ob dies ein nomales Verhalten darstellt? Oder kann es daran liegen, dass ich das nano-Image einsetze?
5
German - Deutsch / Re: VnStat startet nicht
« on: April 27, 2020, 09:00:58 am »
...den Button habe ich total übersehen! 
Nach Drücken funktioniert es nun sofort und der Dienst läuft und gibt auch Werte aus!
Vielen Dank!
6
German - Deutsch / Re: VnStat startet nicht
« on: April 27, 2020, 08:08:08 am »
Was meinst du mit Reset? Einen Neustart von OPNsense?
Diesen habe ich mehrfach durchgeführt, allerdings startet auch dann VnStat nicht.
Diesen habe ich mehrfach durchgeführt, allerdings startet auch dann VnStat nicht.
7
German - Deutsch / [Gelöst] VnStat startet nicht
« on: April 26, 2020, 08:06:30 pm »
Hallo,
leider bekomme ich die Erweiterung VnStat nicht zum Laufen. Die Installlation verlief zunächst fehlerfrei:
Allerdingst startet der Dienst nicht und der Versuch, den Dienst per Shell zu starten, bringt folgende Fehlermeldung:
Das Verzeichnis /var/lib/vnstat ist übrigens komplett leer.
Wie kann ich den Dienst zum Laufen bringen? Neustart von OPNsense und Deinstallation/Neuinstallation von VnStat brachten keinen Erfolg.
Meine OPNsense Version:
leider bekomme ich die Erweiterung VnStat nicht zum Laufen. Die Installlation verlief zunächst fehlerfrei:
Code: [Select]
***GOT REQUEST TO INSTALL: os-vnstat***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 2 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
os-vnstat: 1.2
vnstat: 2.6
Number of packages to be installed: 2
[1/2] Installing vnstat-2.6...
===> Creating groups.
Using existing group 'vnstat'.
===> Creating users
Using existing user 'vnstat'.
[1/2] Extracting vnstat-2.6: .......... done
[2/2] Installing os-vnstat-1.2...
[2/2] Extracting os-vnstat-1.2: .......... done
Stopping configd...done
Starting configd.
Keep version OPNsense\Vnstat\General (0.0.1)
Reloading plugin configuration
Configuring system logging...done.
Reloading template OPNsense/Vnstat: OK
=====
Message from vnstat-2.6:
--
vnstat has been installed.
A sample configuration file has been installed in /usr/local/etc/
Please add your default network interface in the 'Interface' line there
before starting vnstat service.
For more information about vnStat use "man vnstat" or visit:
http://humdi.net/vnstat/
Checking integrity... done (0 conflicting)
Nothing to do.
***DONE***Allerdingst startet der Dienst nicht und der Versuch, den Dienst per Shell zu starten, bringt folgende Fehlermeldung:
Code: [Select]
# /usr/local/etc/rc.d/vnstat restart
vnstat not running? (check /var/run/vnstat/vnstat.pid).
Starting vnstat.
Error: Failed to open database "/var/lib/vnstat/vnstat.db" in read/write mode.
Exiting...
/usr/local/etc/rc.d/vnstat: WARNING: failed to start vnstatDas Verzeichnis /var/lib/vnstat ist übrigens komplett leer.
Wie kann ich den Dienst zum Laufen bringen? Neustart von OPNsense und Deinstallation/Neuinstallation von VnStat brachten keinen Erfolg.
Meine OPNsense Version:
Code: [Select]
OPNsense 20.1.5-i386
FreeBSD 11.2-RELEASE-p18-HBSD
OpenSSL 1.1.1f 31 Mar 2020
8
German - Deutsch / Re: Deaktivieren einer Firewallregel wird verzögert umgesetzt
« on: March 20, 2020, 08:51:01 pm »
Vielen Dank für die Tipps. Ich konnte das Verhalten jetzt noch einmal nachvollziehen. Nach Deaktivieren der Regel läuft der Ping von dem einen Client weiter (da Verbindung bekannt), starte ich jedoch auf einem anderen Client den Ping, wird dieser korrekt geblockt.
Also Danke noch einmal, ich war durch das Verhalten etwas verwirrt
Also Danke noch einmal, ich war durch das Verhalten etwas verwirrt
9
German - Deutsch / Re: Deaktivieren einer Firewallregel wird verzögert umgesetzt
« on: March 19, 2020, 01:47:22 pm »
Hallo Franco,
danke für die schnelle Antwort.
Ich habe mir jetzt die Regel einfach geklont und bei Action statt "Pass" auf "Block" gestellt und aktiviert (die Pass-Regel natürlich vorher deaktiviert). Trotzdem geht der Ping noch durch.
Müsste hier die Block-Regel nicht sofort greifen? Oder habe ich hier einen Denkfehler?
danke für die schnelle Antwort.
Ich habe mir jetzt die Regel einfach geklont und bei Action statt "Pass" auf "Block" gestellt und aktiviert (die Pass-Regel natürlich vorher deaktiviert). Trotzdem geht der Ping noch durch.
Müsste hier die Block-Regel nicht sofort greifen? Oder habe ich hier einen Denkfehler?
10
German - Deutsch / [Gelöst] Deaktivieren einer Firewallregel wird verzögert umgesetzt
« on: March 19, 2020, 12:38:00 pm »
Ich bin OPNsense-Einsteiger und arbeite mich gerade etwas ein und bin auf ein komisches Verhalten bei der Firewall gestoßen.
Zunächst kurz mein Test-Aufbau: Ich nutze ein ALIX-Board, welches hinter einer FRITZ!Box ein separates Netzwerk aufspannen soll:
Ich möchte nun Pings vom Netzwerk der FRITZ!Box 192.168.1.0/24 auf die WAN-Schnittstelle der OPNsense zulassen und habe dafür unter Firewall->Rules->WAN folgende Regel erstellt:
Action: Pass
Interface: WAN
Direction: in
TCP/IP Version: IPv4
Protocol: ICMP
ICMP type: any
Source: WAN net
Destination: This Firewall
Destination port range: any
(Ganz am Ende der Liste habe ich übrigens noch eine Block all-Regel für IPv4+6, Protocol any, Source & Destination any angelegt).
Wenn ich die Ping-Regel aktiviere und mit "Apply changes" übernehme, funktioniert der Ping auch wie gewünscht - soweit ist alles okay und nachvollziehbar.
Deaktiviere ich jedoch die Regel wieder und klicke auf "Apply changes", so werden die Änderungen von der Firewall übernommen, jedoch läuft der Ping trotzdem weiter, bis irgendwann nach unterschiedlicher Zeitspanne (mal 15 Minuten, mal nach ca. 2 Stunden) der Ping dann wie gewünscht nicht mehr durch geht. Nach einem Neustart wird der Ping übrigens sofort abgewiesen.
Wie kann ich mir dieses seltsame Verhalten der Firewall erklären? Ist das so normal? Oder habe ich etwas falsch konfiguriert?
Zunächst kurz mein Test-Aufbau: Ich nutze ein ALIX-Board, welches hinter einer FRITZ!Box ein separates Netzwerk aufspannen soll:
Code: [Select]
WAN / Internet
:
: PPPoE-Telekom
:
.-----+------.
| FRITZ!Box | 192.168.1.0/24
'-----+------'
|
WAN | 192.168.1.200/32
|
.-----+----------------.
| OPNsense (alix2d2) |
'-----+----------------'
|
LAN | 192.168.10.254/32
|
.-----+------.
| LAN-Switch | 192.168.10.0/24
'-----+------'
|
...-----+------... (Clients/Servers)Ich möchte nun Pings vom Netzwerk der FRITZ!Box 192.168.1.0/24 auf die WAN-Schnittstelle der OPNsense zulassen und habe dafür unter Firewall->Rules->WAN folgende Regel erstellt:
Action: Pass
Interface: WAN
Direction: in
TCP/IP Version: IPv4
Protocol: ICMP
ICMP type: any
Source: WAN net
Destination: This Firewall
Destination port range: any
(Ganz am Ende der Liste habe ich übrigens noch eine Block all-Regel für IPv4+6, Protocol any, Source & Destination any angelegt).
Wenn ich die Ping-Regel aktiviere und mit "Apply changes" übernehme, funktioniert der Ping auch wie gewünscht - soweit ist alles okay und nachvollziehbar.
Deaktiviere ich jedoch die Regel wieder und klicke auf "Apply changes", so werden die Änderungen von der Firewall übernommen, jedoch läuft der Ping trotzdem weiter, bis irgendwann nach unterschiedlicher Zeitspanne (mal 15 Minuten, mal nach ca. 2 Stunden) der Ping dann wie gewünscht nicht mehr durch geht. Nach einem Neustart wird der Ping übrigens sofort abgewiesen.
Wie kann ich mir dieses seltsame Verhalten der Firewall erklären? Ist das so normal? Oder habe ich etwas falsch konfiguriert?
Pages: [1]