Messages

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.

Did you buy OPNsense Business Support package?


Looking at this:
https://community.intel.com/t5/Embedded-Connectivity/Intel-X553-driver-Support-for-Freebsd-12-1/m-p/697726

it seems to me like Intels stance on this is, that you need to contact you Qotom to resolve any issues.

I guess you already tried the latest drivers?
https://www.intel.com/content/www/us/en/download/14303/intel-network-adapters-driver-for-pcie-10-gigabit-network-connections-under-freebsd.html?wapkw=x553

Not sure what the question is.
Yes you got a working recursive, local DNS aka unbound up and running.

XGS-PON

XGS-PON is a PITA and you might need a bridge in front of OPNsense.
If not, you could simply get a XGS-PON SFP+ module (again, please check with your ISP, I have seen the weirdest stuff when it comes to XGS-PON) and either an old SSF PC with a SFP+ NIC or something like the DEC740 from OPNsense.

In general, despite some very recently announced and I think still unavailable Intel NICs, 10Gbit copper uses way more power and is way more expensive than fiber or DAC.

Ohne seriöses Troubleshooting ist es Kaffeesatzlesen.

Letzter Stand war glaube ich, OPNsense kann IPv6 anpingen, Clients dahinter aber nicht?

Das deutet eigentlich nicht auf ein Telekom Problem.