Messages

I have 50% RAM (4GB) assigned as /var/log/ and I don't use surricata.

Still got

Code Select Expand

[1/2] Extracting suricata-8.0.3: .........
pkg-static: Fail to create /var/log/suricata:No space left on device
while RAM usage was at 2GB.
After disabling RAM disk, the update went through.

Was she watching on a iPhone or iPad with iCloud Privacy extension enabled? Not sure if Zenarmor can block this. Sorry total noob, never used Zenarmor.

For stable VPN connections static IP addresses are mandatory, IMHO. I never used anything else. At least one side of the connection must have a static IP address. Everything else is a gamble for which OPNsense is not to blame, Pick your poison.

Why? I never had any issues with none static IPv4 over WireGuard.

[Darum würde ich dir dringend empfehlen OPNsense zuerst bare metal laufen zu lassen.]

Hi Andreas.

Eins vorweg, ich würde nicht auf Hyper-V setzten.
Wenn du aus der Windows Welt kommst, mag dies auf den ersten Blick einfacher erscheinen.
Proxmox ist aber IMHO einiges besser dafür geeignet. Gerade wenn du jetzt noch nichts am laufen hast.

Aber egal ob Hyper-V oder Proxmox,  Firewall auf Hypervisor den Nachteil, dass bei jedem Hypervisor reboot dein Internet wegfällt.
Das wäre mir persönlich zu doof, aber deine Entscheidung.

Wenn wenn du dich für OPNsense auf Hypervisor entscheidest, gibt es zwei Möglichkeiten:

A: passthrough des NIC
B: virtuelle Bridges

Bei A reichst du den NIC an die OPNsense durch. Der Hypervisor hat dadurch keinen Zugriff mehr auf den NIC.
Falls dein NIC server grade ist und vNIC kann, kannst du auch nur einen der 64 virtuellen NICs durchreichen.

Vorteil von Variante A ist, dass der NIC sich bare metal verhält. Alles läuft auf dem NIC, egal welches offloading und was für Zauberdinge es sonst noch gibt.

Bei Option B ist halt der NIC in Software. Mit allen Nachteilen davon. Dafür ist es einfacher einzurichten, weil du einen NIC nicht exklusiv durchreichen musst an OPNsense.

Das nächste Problem ist deine Fritzbox. AFAIK kann die keinen sauberen bridge mode. Ist die Kabel, Kupfer oder Glas? Braucht es DECT? Ansonsten würde ich versuchen die Fritte durch einen Konverter / Bridge zu ersetzten.

Finde gerade in der Anfangszeit sollte man möglichst viele Fehler ausschliessen und das Setup möglichst einfach halten.
Darum würde ich dir dringend empfehlen OPNsense zuerst bare metal laufen zu lassen.
Du kannst die OPNsense dann immer noch später virtualisieren, mit einem simplen xml Export und Import.

Wild guess, but have you tried using Chrome instead of Firefox? There are rumors of Google making Youtube intentionally bad on none Chrome browsers.

Ja gut, wenn die Logs die gleichen sind, ist der Fehler wieder der gleiche.
Du hast keine public IPv4.

Finde es generell extrem erstaunlich, hast du überhaupt eine public IP über 4G bekommen. Welcher Anbieter bietet sowas überhaupt an?



Für deSEC gibt es dieses bash script: https://github.com/jameskimmel/deSEC_DynDNS

Hast du denn eine public IPv4?

Was sagen die Logs?

Ansonsten kann ich dir nur https://desec.io empfehlen, bin von noip zu denen gewechselt, funktioniert besser und muss nicht jeden Monat erneuert werden. Dort funktioniert auch ein einfaches shell script ohne den ganzen ddclient Ballast.

Update: I don't know why, but the problem is gone after a few reboots.

Since updating to 25.10, my WireGuard RoadWarrior has an issue.
It basically keeps switching between no connection at all and perfectly fine.
When I ran a simple ping, I also see this, 20 or something packets get through without any problem, then 20 or something packets
timeout.


I myself am running WireGuard under macOS behind a OPNsense 25.7.5.

What I have tested yet to try to rule out errors:
- Using the tunnel over IPv4 or IPv6 only
- Issuing pings to google from both sides, to make sure there is no internet issue
- Pings from remote to the destination without a VPN to make sure there is on peering issue
- rebooted OPNsense
- WAN interface MTU is set left blank (I am using PPoE) and it shows "Calculated PPP MTU: 1492"
- MTU WireGuard is 1412
- Firewall normalization for WireGuard is set to 1352


I am out on ideas on where to troubleshoot further or what to do next. Am I missing something with MTU?
Any ideas from you guys?

Was sagen die Logs von DynDNS?

Now my router doesn't get anymore an IPv6 from WAN side

Sounds like an ISP problem. Have you contacted them? What technique do they use, DHCPv6? Request the prefix over IPv4?

For most applications, the source port number is random, that is why it is not colliding.
I still don't understand the whole setup or what you are trying to achieve here.

Can we try something different?
Can we simply make sure 1:1 NAT is disabled under advanced and we have set outbound NAT to automatic?
That would be the sane default setting.
If after that setting something is not working, because some service, for some obscure reason, needed NAT redirect, we can go from there.

My bet would be that this is a misunderstanding from your previous network guy and not something actually needed.
And if it is, now it is a good time to find out and document it :)

Looks pretty strange to me, but I am no NAT expert. Take this with a grain of salt.

First of all, I am wondering if you don't suffer from many other issues like VoIP not working?
Because you have not set it to auto or hybrid.
Do you have 1:1 NAT under advanced enabled?

Second I would wonder if and why these NAT rules are needed.
If they really are, then I would go with hybrid. That way you get your manual NAT redirects, but other normal devices like an iPhone can do STUN other VoIP stuff.

Stimme Patrick zu, eigentlich sollten von "Innen" nach "Aussen" sowieso alle Ports offen sein.

Warum muss der Port offen sein? Na, aus dem gleichen Grund warum Port 443 offen sein muss, damit du auf opnsense.org zugreifen kannst.

NAT und Port Forward ist was ganz anderes, dabei geht es um von "Aussen" nach "Innen".

Als wir letztens in einem kleinen Hotel waren klappte im Hotel-WLAN nix.

Die Frage ist, warum?

Also mein Ziel ist es, von irgendeinem DS Lite Anschluss, irgendwo im Urlaub auf mein Zuhause mit einem richtigen DS Anschluss zuzugreifen.

Auch ein DS Lite Anschluss im sollte auf ein IPv4 only endpoint Zugreifen können. Da war eventuell noch was anderes schief. Vielleicht haben die Ports blockiert um VPN zu unterbinden?

Bin auch noch relativ neu im IPv6-Umfeld. Aber man muss ja mal langsam auch die "neue" Technik umschwenken.

Nur um eines gleich klarzustellen, der Tunnel und das lokale Netzwerk sind zwei verschiedene paar Schuhe und haben nix miteinander zu tun. Ich kann per IPv6 Tunnel auf mein IPv4 Heimnetz zugreifen und umgekehrt.



Die sauberste Lösung wäre natürlich, dein Zuhause hat echtes Dual Stack.
Da Wireguard leider nicht wirklich dual stack ready ist (bevorzugt IPv4), würde ich zwei DynDNS einrichten ipv4wg.kay.com und ipv6wg.kay.com. Dann kannst du auf dem Gerät selber bestimmen, worüber der Tunnel gehen soll.

Wenn du dann noch einen standard Port wie 80 oder 443 nimmst, kannst du auch eventuelle Hotel Port Blocker umgehen.