Messages

Falls das hier noch mal jemand liest - mit Version 2.2.3 des Plugins funktioniert es jetzt

Ich weiß nicht, wie Wazuh funktioniert, aber die Access Logs von Caddy landen in /var/log/caddy/access/*, nicht in /var/ossec/logs/opnsense_syslog.log.

Mittlerweile bin ich da aufgeklärt (aka hab' den Mittag mit Code Durchwühlen verbracht). Das Wazuh Agent Plugin klinkt sich in syslog-ng ein und muss dann aber alles, was zu Wazuh soll, noch mal in ein lokales File schreiben, damit der Wazuh Agent sie auslesen kann. Das ist die /var/ossec/logs/opnsense_syslog.log. Eine Pipe geht wohl derzeit seitens Wazuh nicht.


Dass die Caddy Logs nicht mit kommen ist ein Bug, der sich wiederum aus der Caddy Syslog Integration ergibt. Lösungsansätze gibt's mehrere, ich hoffe mir antwortet einer der Maintainer was bevorzugt wäre :) https://github.com/opnsense/plugins/issues/5859

[caddy]

Auf meiner OPNsense läuft Caddy als Reverse Proxy für diverse Dienste, die teilweise auch aus dem Internet erreichbar sind. Ich spiele gerade mit Wazuh rum und es wäre ja naheliegend, die Caddy Access Logs mit dem Agent einzusammeln. Allein es scheint nicht zu funktionieren. Was ich bisher gemacht habe:

• Wazuh Server aufgesetzt
• Wazuh Agent auf OPNsense installiert und bei Applications entsprechend meiner Nutzung folgendes mitgenommen:
  
  • audit
  • caddy
  • configd.py
  • dhcpd
  • filterlog
  • firewall
  • kernel
  • lighttpd
  • miniupnpd
  • ntpd
  • unbound
  • bgpd
  • zebra
  • wireguard
• Am Wazuh Server geprüft, dass Daten prinzipiell ankommen
• Auf OPNsense /var/ossec/logs/opnsense_syslog.log geprüft - hier sind keine Caddy Access Logs
• In den Caddy Settings Log HTTP Access in JSON Format aktiviert und deaktiviert - kein Unterschied

Ich sehe kein einziges Event aus dem Caddy Log in Wazuh. Hat das schon mal jemand gemacht? Mach' ich was falsch oder interpretiere ich die Application caddy in den Wazuh Agent Settings falsch, und die überträgt gar keine Access Logs?

One particular issue i've had with default gateway switching was that VPN tunnels would fail over to the secondary gateway when the primary went down, but they would stay on there even when the primary gateway came back.

There are some other quirks around default gateway switching and for me the question is whether or not i care about the firewall itself losing internet connectivity while the primary line is down. If the answer is no, then using gateway groups and policy routing works better in my experience

Moin zusammen,

ich sitze seit einiger Zeit vor einem seltsamen Problem. Mein Setup sieht wie folgt aus:
OPNsense virtuell auf einem Debian Unterbau (openmediavault um genau zu sein). Host hat 2 NICs, eine davon Intel, diese ist durchgereicht. Interface in OPNsense ist em0.
Auf diesem Interface habe ich nun alle VLANs getagged vorliegen, d.h. untagged wird gar nicht verwendet. Tagged VLAN 5 ist das Glasfasermodem vom ISP, und darauf wird wiederum PPPoE gesprochen. Soweit so gut, PPPoE funktioniert, IPv4 funktioniert, IPv6 funktioniert - ich erhalte eine IP auf dem Interface sowie ein /56 Präfix. Meine LAN Clients bekommen eines der Netze aus dem delegierten Präfix.

Wenn da nicht das eine "kleine" Problem wäre: OPNsense hat manchmal schlicht und ergreifend keine IPv6 Default Route. Ich verstehe nicht wie es dazu kommt. Früher lief das und ich meine, dass die Probleme mit 24.1 begonnen haben. Ist aber schwierig zu sagen, da im gleichen Zeitraum mein ISP an den Settings geschraubt hat - ursprünglich bekam ich nur ein IPv6 Präfix ohne IP auf dem Interface, dann zweitweise nur ein /64 Präfix und mittlerweile eine Adresse fürs Interface sowie ein /56 Präfix, wie es ja an und für sich auch schön ist.

Was mir noch auffällt ist, dass beim Boot "Configuring LAN Interface" sehr lange hängt, die anderen Interfaces flutschen durch. Nehme ich die IPv6 Config als Track Interface vom LAN Interface runter, geht es auch da schnell. Das WAN Interface wird nach dem LAN Interface konfiguriert - da erscheint mir die Verzögerung logisch. Kann es hier möglicherweise ein Problem mit der Reihenfolge der Initialisierung der Interfaces geben, das auch gleichzeitig die fehlende IPv6 Route erklärt?
Ansonsten bin ich für jeden Hinweis dankbar was ich noch probieren könnte

/e: wichtig zu erwähnen ist, dass die Route manchmal fehlt, und manchmal geht es. Gerade hatte ich sie nicht, habe OPNsense rebooted, jetzt ist sie da. Das schreit doch auch irgendwie Race Condition, oder?

/e2: Es scheint als würde das Problem speziell bei PPPoE auf VLAN auftreten. Ich habe auf eine Proxmox VM migriert und für jedes VLAN ein eigenes vtnet Interface an die OPNsense VM angehängt, anstatt ein Device durchzureichen und die VLANs in OPNsense direkt anzulegen. Damit sind die Probleme scheinbar weg - Boot geht gewohnt flott und Default Route ist auch da. Ich beobachte noch ein paar Tage...

/e3: Leider war das doch kein permanenter Fix - auch mit dedizierten Interfaces pro VLAN fehlt ab und an die Route. Aktueller Fix, der nun seit 2 Tagen hält, ist eine statische Route mit ::/0 und dem entsprechenden Gateway anzulegen. Nicht schön aber wenn das die Lösung ist, soll es so sein

Been having weird IPv6 issues recently, too. Noticed today that for whatever reason my OPNsense doesn't have a default IPv6 route anymore. Clients and the firewall itself (on the WAN interface) have their addresses properly assigned, but the route is missing, resulting in no connectivity. Could that be your problem aswell?

If memory serves me correctly, my problem came with the update to 24.1.2, but i don't remember exactly. I have daily config backups - is the OPNsense release version in there somewhere so that i can verify?

/e: I think i might have solved my issue, and it might be related to gateways. My IPv6 gateway existed prior to upgrading to v24 with the gateway stuff being migrated during upgrade. I had configured upstream monitoring and set one of OpenDNS's addresses as the monitoring target. I now went and removed the gateway. It got automatically recreated and the default route appeared. Added the monitoring target again and enabled gateway monitoring. So far so good, route is still there. Will see tomorrow whether this all survives a nightly reboot.

You can specify the MTU that the created interface is supposed to get in the wireguard "Instance" settings, but you have to toggle "advanced settings" for the field to appear

You can do it on the CLI using ifctl and the OS's interface name

example: ifctl -6pi pppoe0

Encountered the same issue today. GW config XML looks exactly like Moonshine's. Both IPv4 and IPv6 gateways on WAN were affected. In my case however, there's no LAN interface, i'm running this instance as a VPN hub. Other than that there's nothing special going on

Assuming you already have a gateway for each VPN provider in place you can use firewall rules for the respective networks to force them through a specific gateway

You could disable default gateway switching so opnsense will always use the primary line. Then use gateway groups and firewall rules to handle failover for clients. Could work but means your tunnel loses the benefits of redundancy

Wasn't there, at some point, an option somewhere to reset firewall states on gateway failover? That should do the trick, but i can't find it...

/e: I'm not crazy, it used to be there. But apparently that also only worked one-way. See https://forum.opnsense.org/index.php?topic=25818.0 and https://github.com/opnsense/core/issues/5387

I guess a custom script that checks for this condition and resets the WG tunnel if necessary is an option? Cronjobs don't allow custom scripts anymore, but monit does. So you could try your luck with that and selectively killing the tunnel's firewall state, should kick it back into using the primary gateway

If you need a specific tagged VLAN you'll have to create a VLAN Interface on top of mlxen0 and then add your PPPoE interface to that

You can do a packet capture on mlxen0 to see how the frames leaving your interface look. Right now you'll probably see an untagged frame. After making the suggested changes you'll see it tagged with the VLAN ID you set for your VLAN interface

I guess that's going to boil down to who you (dis)trust more - your ISP or the public resolver you intend to use. You could also look at using one of the privacy-focused resolvers like Quad9. Of course you still have to trust them in the end

Personally i've run both setups, both work fine. Right now i'm using a public resolver and DoT because i wanted to try it out, was happy that it's working and stopped caring at that point  ::)

u can do virsh dumpxml <vmname> and then inspect the output. it should be in the interface definition https://libvirt.org/formatdomain.html#network-interfaces

that said i'm not sure how to best go about this in proxmox. i recall it as advanced interface options, either look for a checkbox or put it in the free-text field if available

Any chance you recreated the virtio interface? I've had issues getting LLDP to work in the past, and found out that i needed to add trustGuestRxFilters='yes' to the interface defintion in order to stop the hypervisor from filtering out certain frames