Messages

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

Do you have the QEMU Guest Agent installed? It's available as a plugin. That should enable Proxmox to communicate with the guest, iirc it will also help display correct memory usage stats.

I don't know if anything has recently changed in OpenVPN, but normally you don't need to have all user certificates on both nodes. In fact you don't need to have any of them on your firewall(s) at all.
Technically all that should be necessary is the CA so that the OpenVPN server can validate the user's certificate chain. You could be issuing user certificates in another system and deploy them through whatever mechanism to your clients, it should still work

Hmmm, laut Eingangspost hast du es mit Destination "This Firewall" auch schon probiert, richtig? Die Regel sieht erst mal gut aus, wüsste nicht warum die OPNsense die Source Adresse austauschen sollte. Kannst du mal noch deine Outbound NAT Regel screenshotten, inklusive der automatisch generierten? Eventuell liegt da der Hase im Pfeffer.

Ansonsten passen die Adressen deines ersten Posts, des Screenshots und der ASCII Grafik alle nicht zusammen. Laut Grafik ist da ein weiterer Router. Könnte der eventuell das Problem sein? Zeichne das vielleicht noch mal sauber neu...