Messages

Hallo,

bei dem "FreeBSD by Zabbix agent" Template gibt es leider nicht die Möglichkeit, Dienste zu konfigurieren oder zu hinterlegen. Grundsätzlich mag das möglich sein, denn beim Überwachen von Windows-Systemen gibt es dieses Feature in den Templates.

Um sich dem Thema zu nähern würde ich vorschlagen, die Dienste über ihren Port anzusprechen. Es gibt ja verschiedene Templates für TCP/UDP/DNS/SSH/Web/SSL usw. Wenn man solch ein Template konfiguiert und ins OPNsense Template aufnimmt, hat man nicht nur den entsprechenden Dienst geprüft, sondern auch die Verfügbarkeit/Erreichbarkeit.

Gruß
Robert

Hallo Shoux,
wir haben bei uns in der Firma rund 50 OPNsense Installationen unserer Kunden in aktiver Überwachung mit Zabbix. Bei uns geht es in erster Linie um Zuverlässigkeit und Konnektivität. Wir nutzen, wie du auch, den Zabbix-Client.

Auf dem Zabbix-Server haben wir dazu ein Template angelegt, welches andere Templates kombiniert:
- "FreeBSD by Zabbix agent" - Dieses Template bietet die meisten Informationen, u.a. auch Traffic pro Interface etc. Es ist in Zabbix integriert.
- "ICMP Ping" - Wir prüfen die externe Erreichbarkeit um einen Internetausfall, z.B. Telekom o.ä. zu dokumentieren. Es sollte auch in Zabbix integriert sein.

Ich hoffe, das hat dir zunächst geholfen?

Gruß
Robert

Hallo,
für die, die sich mit IPv6 auseinandersetzen möchten, empfehle ich zum Start folgende Podcastfolge:
https://requestforcomments.de/archives/412

Ich kann es nur empfehlen, sich damit zu beschäftigen. Wer als ITler heute ohne IPv6 ankommt, wird an so vielen Dingen scheitern.

Gruß
Robert

Guten Morgen,
meines Wissens nach bietet Vodafone DSL derzeit immer noch kein IPv6 an. Bei Vodafone-Kabel und im Mobilfunk ist es verfügbar. Wenn du also über DSL online bist, müsstest du evtl. über einen Providerwechsel nachdenken.

Vodafone selbst hat auf verschiedenen Anfragen von uns und unserer Kunden bisher nicht reagiert oder konnte kein Datum nennen.

Viele Grüße
Robert

Hallo,

unter diesem Link habe ich die Konfiguration erklärt:
https://forum.opnsense.org/index.php?topic=21839.msg103084#msg103084

Gruß
Robert

Hallo,

schalte mal unter "Firewall" -> "Advanced" das Häkchen bei "Disable reply-to on WAN rules" ein.
Es muss ohne eine IPv6 Portweiterleitung gehen.

Gruß
Robert

Hallo inDane,

schön, dass du es lösen konntest. Es wäre schade, deswegen wieder zur pfSense zu wechseln.
Ich nutze die Floating Rules nur, wenn ich mehreren LAN Interfaces die gleichen Regeln zuweisen möchte, sonst halte ich die Regeln lieber beim entsprechenden Interface.

Gruß
Robert

Hallo inDane,

es stimmt, natürlich werden Pakete an 192.168.178.xxx verworfen. Hierfür ist eigentlich STUN da, damit die GO-Box die eigene öffentliche IP-Adresse herausbekommen kann und diese ins Paket schreibt.
Welcher STUN-Server ist denn in der GO-Box eingestellt? Bei 1und1 sollte es wohl stun.1und1.de sein?

Nur noch eine Rückfrage: Aufgrund von 192.168.178.xxx vermute ich eine FRITZ!Box? Was hast du denn da für ein Modem?

Gruß
Robert

Hallo inDane,

schau doch mal, ob du die Ports von der Go-Box auf zufällig stellst. Die NAT Regel dann so konfigurieren, dass alle Pakete von der IP-Adresse der Go-Box auf "STATIC Port" gesetzt sind. Zum Debuggen bitte auch mal alle Ports an die Go-Box weiterleiten. Das muss später aber unbedingt raus.

Und noch etwas: Bitte benutze kein STUN. Bitte STUN in der GO-Box mal komplett abschalten.

Gruß
Robert

Hallo inDane,

ich möchte dir noch zwei Möglichkeiten vorschlagen:

1. Mach doch mal eine Portweiterleitung auf die Go-Box. Die entsprechenden Ports kannst du der Go-Box Oberfläche entnehmen. Wir nutzen bei einigen Kunden ebenfalls die GO-Box. Es gibt eigentlich keine Probleme. Ich würde mir die Optionen auf der Go-Box Config aber auch nochmals ansehen. Evtl. ist da etwas schief.

2. Nimm dir ein Wireshark. Mach mit den OPNsense (oder per SSH-Tunnel) ein dump des traffics. Anschließend schaust du es dir mir Wireshark an. Du kannst bei SIP/RTP sehr gut sehen, wie die Kommunikation läuft. Kleiner Tipp: Mach ein Dump auf der WAN-Seite und auf der LAN-Seite. So kannst du ggf. sehen, welche Pakete nicht durchkommen.

Falls du Linux benutzt, ich mache ein Dump wie folgt:

Code Select Expand

ssh root@OPNsense -p22 "tcpdump -i igb1 -U -w - port not 22" | wireshark -i - -k

Dieser Befehl baut eine SSH-Verbindung zur OPNsense auf und leitet den gesamten Traffic von igb1 direkt an das Wireshark. Ausgenommen ist die SSH-Verbindung selbst.

Gruß
Robert

Guten Morgen,
neulich bin ich auch darüber "gestolpert" und hatte das Problem auch. Ich musste die MTU in den Tunneleinstellungen auf 1412 setzen, dann ging es wieder. Was sich in der OPNsense konkret geändert hat, ist nicht klar. Jetzt läuft es aber wieder stabil.

Hier der Thread: https://forum.opnsense.org/index.php?topic=36941.0

Gruß
Robert

Hi schmuessla,

thank you for your hint. You are right!
I changed the MTU from (empty) to 1412 and the connection works fine. Thank you very much!

Nevertheless, there must have been a change recently, because other installations work without manual adjustment.

Best regards
Robert

Hello everyone,

I am aware of some problems with the current stable version of OPNsense. I had a well working Firewall on 23.7.7 but one of our team has some problems with openvpn. So I decided to install Wireguard. The plugin installation forced me to upgrade to 23.7.8 first. (This is not a nice thing. I think it should be possible to install a plugin with a version that is one or two minor releases behind.)

After installation I lost IPv6 connectivity, which could be solved with a command @franco posted here. (Thanks!)

Now the problem: After configuring and connecting via Wireguard, I am able to ping all machines through the tunnel behind the OPNsense. But when I try to connect via SSH or RDP to a machine, this does not work. It makes no difference between IPv4 or IPv6.

You can find a wireguard screenshot at this post:
- Lines 1-8 showing the working ping from the client (192.168.98.2) to a machine behind the firewall (192.168.100.250)
- Lines 9-34 showing the packets when I try to connect via SSH. The connection failed (timeout).

Any ideas what may be the problem here?

Thanks!
Robert

[Update]

Hallo Micneu,

vielen Dank für die Idee. Ich hatte das schon überlegt und ich werde es ausprobieren. Vielleicht kann man ja Windows so zu IPv6 "zwingen".

Update: Es scheint so zu funktionieren. Unter Windows nimmt der WG Client immer IPv4. Bei einem Hostnamen, der nur IPv6 auflöst, funktioniert es auch unter Windows. Der Grund ist mir weiterhin nicht klar.

Gruß
Robert

Guten Morgen,

mein Problem bezieht sich nicht direkt auf die OPNsense, jedoch tritt es in Verbindung mit der OPNsense auf und vielleicht hat jemand trotzdem eine Idee.

Ich habe einen Wireguard-Server für externe Arbeitsplätze konfiguriert. Dieser läuft auf der OPNsense 23.7.4 (Dualstack) absolut einwandfrei. Routing, Firewall, Handshake alles perfekt und die externen Arbeitsplätze haben den Zugriff, der benötigt wird.

Als Endpoint steht in der Config ein Domainname, der IPv4 und IPv6 auflöst. Das Problem ist, dass alle Windows-Clients (Wireguard unter Windows von der offiziellen Website) immer die Verbindung per IPv4 aufbauen. Ich hätte jedoch lieber eine IPv6 Verbindung. Alle Linux-Clients verbinden sich über IPv6.

Der Hintergrund: Vor der OPNsense steht ein LANCOM-Router der Telekom (ISDN Wandler), über den ich keine Kontrolle habe. Dieser scheint bei der Menge an NAT/UDP-Verbindungen regelmäßig Probleme zu haben. Auf jeden Fall werden alle paar Tage alle UDP-Pakete blockiert und nur ein Reboot des LANCOMs löst das Problem. Das gleiche Problem hatte ich früher auch bei OpenVPN, allerdings hat sich der OpenVPN Client i.d.R. per IPv6 verbunden und damit die LANCOM-Probleme umgangen.

Hat jemand eine Idee, weswegen sich der Windows-Client von Wireguard bei der Angabe eines FQDN immer mit IPv4 verbindet und ob es hier irgendwie/irgendwo eine Option gibt, das zu steuern?

Gruß
Robert