Messages

1

20.1 Production Series / Error entries from lighttpd in the Web GUI Log File

« on: February 02, 2020, 09:18:17 am »

Hello all

In the Web GUI Log File i found a lot of the following entries from lighttpd:

lighttpd[64344]: (mod_openssl.c.1975) SSL: 1 -1 error:1409F07F:SSL routines:ssl3_write_pending:bad write retry

There is nearly each minute one such entry.

For me it's not clear what is wrong, and what I have to correct in the configuration.

Installed is OPNsense 20.1

Thanks for helping
Dieter

2

German - Deutsch / Re: Mails auf viren scannen

« on: March 23, 2019, 09:11:12 am »

Alternativ wäre folgendes:
Im LAN ein Mailserver installieren, der mir meine Mails holt bzw. versendet. Und mein Client ruft die Mails nur noch im LAN ab, von außen dann per VPN. Dann sollte das doch wieder funktionieren?
Gibt es dazu Vorschläge welchen Mailserver ich da nehmen kann/solte, und entsprechende Anleitungen?

https://www.hmailserver.com/
Der lässt sich recht einfach konfigurieren und läuft stabil. Bracht einfach einen dauernd laufend Rechner im Netz.
Läuft bei mir schon Jahre und hat sich bewährt. Dann kannst Du den Virenscann auch auf dem Server selber machen lassen. Was ich so mitbekommen habe braucht der von dir oben verlinkte Mailgateway auf OPNsense relativ viel Performance. Selber ausprobiert habe ich es bisher nicht.

Muss aber auch sagen, ich selber verwalte mehrere Domains selbständig, habe also nicht einfach eine Mailbox auf dem hmailserver laufen.

3

German - Deutsch / Re: Error nach Aktualisierung auf 19.1.2

« on: March 03, 2019, 05:24:41 pm »

Okay, habe jetzt mal beide Dateien runter geladen und in einem Editor geöffnet.
Der Unterschied ist, auf der Box mit dem Fehler ist am Ende eine zusätzliche Zeile angehängt:

Code: [Select]

gps0:dv=/dev/cuaU0:br#4800:pa=none:Es ist tatsächlich so, dass an dieser Box, welche meine Main-Firewall im HA-Verbund ist, ein USB-GPS angehängt ist, was auf der Backup-Box nicht der Fall ist.

Es scheint also so, dass nach dem Installieren das GPS gefunden und dort eingetragen wurde. Damit ist der Digest natürlich nicht mehr korrekt.
Nur, ist dieses Verhalten so korrekt? Bisher trat dieser Fehler beim Gesundheits Audit nicht auf?

Ich wäre sehr dankbar, wenn mir das jemand näher erläutern könnte. Irgendwie bleibt bei einem solchen Resultat des Gesundheits Audits ein flaues Gefühl im Magen zurück. Eine Firewall sollte schon ohne Fehler laufen....

Einen schönen Abend noch.

4

German - Deutsch / Re: Error nach Aktualisierung auf 19.1.2

« on: March 03, 2019, 05:04:16 pm »

Da ich OPNsense im HA-Mode betreibe habe ich eine zweite identische Firewall. Diese weist nach der Aktualisierung keinen Fehler aus.

Ich bin jetzt mit SSH auf die beiden apu4C4 drauf und habe mir die Datei /etc/remote angesehen. Auf der Box mit dem Fehler hat die Datei eine Grösse von 2674 Byte und auf der Box ohne den Fehler von 2639 Byte. Das würde die Fehlermeldung bestätigen, zumindest soweit ich sie verstanden habe. Logisch auch, dass der sh256digest dann nicht stimmt.

Was mir auffällt sind die Timestamps der beiden Dateien:

• 2674 Mar  3 14:49 remote
• 2639 Feb 27 01:50 remote

Will heissen, die mit der korrekten Grösse ist deutlich älter? Scheint also von der Aktualisierung nicht betroffen worden zu sein.
Die mit der falschen Grösse scheint hingegen mit der Aktualisierung verändert worden zu sein, denn der Timestamp entspricht etwa dem Zeitpunkt der Aktualisierung.

Nur wie kommt so etwas?
Was soll/kann ich jetzt machen?

Einen schönen Nachmittag noch.

5

German - Deutsch / Error nach Aktualisierung auf 19.1.2

« on: March 03, 2019, 03:11:43 pm »

Nach der Aktualisierung auf OPNsense 19.1.2 habe ich ein Gesundheits-Audit mit folgendem Resultat gemacht:

Code: [Select]

***GOT REQUEST TO AUDIT HEALTH***
>>> Check installed kernel version
Version 19.1.2 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 19.1.2 is correct.
>>> Check for missing or altered base files
Error 2 ocurred.
etc/remote:
size (2639, 2674)
sha256digest (0x1178a28b9fc19375024ab33a88f2ecaacf08aefda45e38680cb6bf3deb956369, 0x82aac34d2572df5494e728fc9879965e563e64110b55a9978dde3a59cbc4a00c)
>>> Check for and install missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
***DONE***
Unter der Zeile

>>> Check for missing or altered base files

Wird ein Error ausgegeben. Ich steige da nicht hinter, was da falsch ist und was ich da machen könnte.

6

German - Deutsch / Re: Anfänger Frage: WAN Netzwerk für Gerät sperren

« on: February 20, 2019, 07:25:37 am »

Auch dein Dash Botten benötigt eine IP. Sorge dafür, dass er per DHCP immer die selbe IP erhält, und sperre für diese die Verbindung ins Internet.
Ich kenne das Teil nicht. So wie ich Deinen Aufbau verstehe, wäre dies aber der Weg

7

German - Deutsch / Probleme mit OpenVPN im HA-Betrieb

« on: February 19, 2019, 06:49:52 pm »

Hallo zusammen

Ich habe hier zwei baugleiche (apu4c4) OPNsense mit 19.1.1 im HA-Betrieb im Einsatz. WAN, LAN und Opt1 als CARP und Opt2 für pfsync. Das funktioniert bisher gut.

Bevor ich auf HA-Betrieb umstellte, lief auch OpenVPN auf der OPNsense und zwar im Brückenmode (TAP) über UDP. Das funktionierte wunderbar.

Nachdem ich auf HA-Betrieb umstellte, wollte ich OpenVPN jetzt auch wieder in Betrieb nehmen, was mir aber bis dato nicht gelungen ist. Grösstenteils endeten meine Versuch mit fatalen Crashs der OPNsense - will heissen keinen Zugriff mehr per Web GUI, SSH und serieller Konsole.
Lösung jeweils nur noch hartes Trennen der Speisung, entfernen aller LAN-Kabel und dann booten mit der seriellen Konsole. Wenn OPNsense dann oben war, als root anmelden und die Interface neu Zuordnen, damit die neuen Interfaces Opt3 (TAP) und Opt4 (Brücke) deaktiviert wurden. Danach konnten die LAN-Kabel wieder eingestecktm, und über Web GUI oder SSH angemeldet werden.

Etwas strange finde ich solche Crashs schon...

Beim Konfigurieren des OpenVPN-Servers gehe ich folgendermassen vor:
- TAP-Device
- Protokoll UDP
- Schnittstelle früher ANY, jetzt explizit CARP auf WAN-Seite
- Brücken-Schnittstelle früher LAN jetzt explizit CARP auf LAN-Seite
- DHCP-Range des VPN's schön am DHCP-Range der LAN-Seite vorbei. Da entsteht kein Konflikt.

Interfaces:
- Opt3 -> ovpns1
- Opt4 -> bridge0

Bridge:
- früher zwischen ovpns1 und LAN, jetzt explizit zwischen ovpns1 und CARP auf LAN-Seite

Dazu kamen dann noch Client-spezifische Konfigurationen. Nach meine Gefühl, dürften die Probleme eher nicht davon kommen.

Nachdem mir beim ersten Versuch gleich beide OPNsense gecrashd sind, da ich natürlich die Synchronisation auch auf OpenVPN eingeschaltet hatte, habe ich diese vorerst aus den HA-Einstellungen heraus genommen, so hat mir bei den weiteren Versuchen wenigstens das Backup-System sauber übernommen.

Ich habe auch versucht den OpenVPN-Server erst mal deaktiviert zu lassen, ebenso die Client-spezifischen Konfigurationen. Brachte letztendlich aber keine Änderung am Verhalten. Ich tippe auf ein Problem mit den Interfaces, kann aber nichts finden.
Benötige ich ein weiteres CARP auf das TAP Interface?
Was muss ich im HA-Betrieb bei der Konfiguration von OpenVPN speziell beachten?

Kennt sich damit jemand aus und kann mir weiter helfen.

Herzlichen Dank und einen schönen Abend noch
Dieter

8

German - Deutsch / Re: Problem OPNsense 19.1 und APU.4B4

« on: February 11, 2019, 05:34:14 pm »

Ich hatte letzten Freitagabend das Update auf OPENsense 19.1.1 gemacht und danach die selben Probleme, dass die apu4c4 immer wieder nach kurzer Zeit abstürzte. Es war keinerlei Zugriff mehr auf das Web-GUI, per SSH oder serieller Konsole mehr möglich. Verbindungen über die Firewall waren jeweils noch für kurze Zeit vorhanden, dann war irgendwann komplett Schluss (max. nach 2 Std.).  Blieb nur Strom unterbrechen und neu starten.

Die Bios-Version weis ich nicht mehr, auf jeden Fall ziemlich viel neuer als v4.0.23. Der Bios-Downgrade brachte die Lösung. Seit ich Bios v4.0.23 drauf habe läuft sie wieder wie zuvor, komplett störungsfrei.

Das Bios konnte ich ohne jegliche Probleme während dem normalen Betrieb (direkt nach einem Neustart) aufspielen. Danach Reboot und seither habe ich Ruhe. Läuft seit knapp 1 1/2 Tagen. Konnte dabei OPENsense 19.1.1 drauf lassen.