Beiträge von frank_m

Zitat von DJPRMF

My issue is that, with the configuration that i am making, the server is not working with IPv6.

Unfortunately, we can't see the configuration you are making. We just see some commands you are typing in, without knowledge of other things flying around.

Zitat von DJPRMF

Because... that is how you configure a server?

Yes. I create configuration files for the system services, reboot the system and observe, if everything works like expected. This is the only guarantee, that everything works after a reboot of the server like expected. A reboot can always happen, so I can't rely on several manual commands to be typed in before a system starts to work. And be prepared: The network setup is just the first step, firewall and maybe other things will follow.

Zitat von DJPRMF

And with the information provided, that is everything that is needed, do you see any issue?

No. But as I said, the shown configuration files are not matching your active configuration. So I have not seen everything. Maybe there is an error you have not shown us. I want to rule out the possibility that something like that exists before we go to the next step.

Zitat von DJPRMF

Also aside, i don't know why are you being kinda rude in those exchanges... chill dude. Im just asking for help...

Yes, but if you want help, than please provide the information asked for. I did it three times now and got nothing usable.

No. Are you going to type in these commands after every boot? What does it help to try out different manual commands? If there is a configuration error, you will never find out this way. BTW, the resulting configuration of these manual commands is still wrong, there is a subnet route, which should not be there, but most likely this is not the root cause for your problem.

How looks the active configuration if you reboot your system and touch nothing?

Then I repeat: There is another configuration mechanism active. There are still addresses and routes, you do not have configured. The subnet routes e.g. are not necessary, not configured and maybe even disturbing (I do not have them). The 2XXX:4XXX:5x:4xx:4xxx:62ff:fe4b:9f5d/64 is not configured, but active.

For the first tests stick to the default address shown in the SCP. This is the address the Netcup infrastructure is using internally, if they want to access the server. The address has permanently to be configured, at least for receiving packets. Later, you can configure another address for outgoing and incoming traffic.

No, it is not.

This is in the configuration file:

Zitat von DJPRMF

IPV6ADDR=2xxx:4xxx:5x:4xx::1/64

But this is active:

Zitat von DJPRMF

inet6 2XXX:4XXX:5x:4xx::1/128 scope global noprefixroute

And: noprefixroute is set, but:

Zitat von DJPRMF

2XXX:4XXX:5x:4xx::1 dev eth0 proto kernel metric 100 pref medium

2XXX:4XXX:5x:4xx::/64 dev eth0 proto kernel metric 100 pref medium

So, please show your active configuration resulting out of your configuration files. Your current active configuration does definitely not match your configuration files. How should we debug your config, when you are showing us a setup, in which you have played around?

It seems, there is an additional mechanism active configuring your network devices, since the configuration is not matching your ifcfg-eth0, and there are addresses and routes you do not have configured in your ifcfg-eth0.

Yes, no problem here.

In order to debug your problem, you should post your configuration files (IP, router and nameserver), the output from "ip -6 a" (or "ifconfig -a"), from "ip -6 r" and from ping and traceroute commands to external IPs and hostnames.

Zitat von DJPRMF

Gateway fe80::1 doesn't ping at all—and I think it should.

No, it should not. It is just a dummy for setting the default gateway to link eth0 (or whatever your device is). The IPv6 subnet at Netcup is switched, not routed.

Ich hab die Meldung des Öfteren gesehen, wenn ich das SCP just im Moment eines Reboots aufgerufen habe. Dann konnte das SCP den guest-agent nicht erreichen, was vermutlich zu der Meldung führte. Nachdem der Server wieder sauber hochgefahren war, war die Meldung auch wieder weg.

Zitat von NaN

Ich hoffe für dich, dass du irgendwann kapierst, wie sehr dich deine Unfähigkeit, sachliche Korrekturen zu akzeptieren, in deiner Kommunikation einschränkt.

Sachliche Kommentare und Korrekturen sind ok. Aber das war pure Besserwisserei über ein Randtheme mit keinerlei praktischer Relevanz für das Thema, noch dazu so dargestellt, als sei meine Darstellung falsch - was nachweislich gemäß der offiziellen Doku nicht so ist.

Also übe sachliche Kritik, dann bekommst du auch sachliche Antworten. Ansonsten halt auf dem Niveau, das passt.

Solange meine Lösungen für Otto-Normal-User funktionieren, der offiziellen Dokumentation entsprechen und nur von Besserwissern so bemängelt werden, ist das für mich ok. Bleib du mal weiter in deiner Bubble mit überprüften Absender-Adressen, und lass andere funktionierende Wireguard-Setups machen. Dann ist allen geholfen.

Zitat von NaN

Naja, es ist da auch nur halbrichtig erklärt.

Natürlich. Wenn es dir nicht in den Kram passt, dann sind sogar die offiziellen Man Pages "nur halb richtig". Übrigens ist es nicht nur die Man Page, auch die Wireguard Web-Seiten erklären das Routing im VPN anhand der Allowed IPs Einträge. Und mach dir mal den Spaß und frage eine KI nach der Funktion, was die dir erzählt.

Zitat von NaN

Wenn man andere Vorstellungen hat, welcher Traffic genau durch das VPN geroutet werden soll (z.B. nur bestimmte Services), dann kann und muss man das selbst machen.

Darum geht es überhaupt nicht. Es geht darum, wohin wg die Pakete routet, die bereits im VPN sind. Welche Pakete da reinkommen, entscheidest du an anderer Stelle, das hab ich auch immer so geschrieben. Und da kann es wohl wenig Zweifel geben, dass sowohl die Man Page als auch meine Ausführungen recht haben: Die AllowedIPs entscheiden darüber, wie die Pakete innerhalb des VPNs geroutet werden. DAS ist relevant für die Nutzer, die sich ihr VPN Netz aufbauen und dabei einen zentralen Knoten für Roadwarror und LAN-LAN Netze nutzen.

Auch wenn du die Überprüfung der eingehenden Source Adressen als "Hauptfunktion" bezeichnest, so ist es in der Praxis doch das Routing, dass mit dieser Option konfiguriert wird. Darüber werden die Datenströme im VPN gelenkt. Das ist der Punkt, über den sich die Anwender Gedanken machen und ihr Netz-Setup planen. Von daher. Turne auf deiner "Hauptfunktion" so lange herum, wie du willst, in der Praxis spielt die andere Funktion die Hauptrolle.

Zitat von NaN

Es wird nur überprüft, was der AllowedIPs Parameter für den Peer festlegt: Von welchen Adressen Pakete kommen dürfen.

Wenn es nur das ist: Wie sagst du dem VPN Server denn, dass er die Pakete für die Fritzbox zur Fritzbox schicken soll, und nicht zu einem seiner anderen VPN Peers?

Zitat von 00philip

Kommando zurück... funktioniert nicht - das Telefon war versehentlich im WLAN

Ja, das hab ich erwartet.

Zitat von 00philip

AllowedIPs im Wireguard Server ist tatsächlich ein Source IP des Peer.

Demnach müsste ja die Server-Config richtig sein.

Nein, die Server Config ist nicht richtig.

In den Fritzbox-Block muss ein 192.168.1.0/24 mit rein. Vergiss den Unsinn, den NaN da schreibt, in der Praxis entscheidet der AllowedIPs Eintrag darüber, welche Pakete in den Tunnel geleitet werden. In deinem iPhone steht die 192.168.1.0/24 drin, weil das iPhone die Pakete zum VPN Server schicken muss. In die Server-Config muss 192.168.1.0/24 in den Frtzbox Block rein, damit der Server weiß, dass er die Pakete vom iPhone mit Ziel Fritzbox zur Fritzbox schicken muss, Entsprechend muss 192.168.1.0/24 aus dem iPhone Eintrag raus: Dahin dürfen die Pakete mit Ziel Fritzbox nicht geschickt werden.

Dazu nimm alle MASQUERADE Einträge raus. Die sind in deinem Szenario vor allem im Zusammenspiel mit einer Fritzbox kontraproduktiv.

Zitat von 00philip

Ich maskiere die IP damit, um nicht die öffentliche IP des Peers im Tunnel zu haben.

Das entscheidet aber nicht die MASQURADE Regel auf dem Server, sondern in dem Fall der Client, also das iPhone. Und das kann in wg nur die IP des Transportnetzes nutzen.

Deine Konfiguration ist immer noch ziemlich komisch, aber wenn es funktioniert, seis drum.

Zitat von NaN

Das ist genau falschrum erklärt. Wireguard überprüft nur die Source-Adressen ankommender Pakete, also was vom Peer empfangen wird. Was du meinst ist, dass der Tunnel anhand der Peer-Adressen ausgewählt wird, also effektiv nur das durch den Tunnel gesendet wird, was eine Target-Adresse in den AllowedIPs des Peers hat. Das prüft der empfangende Peer aber nicht, weil er die Information, die er dazu bräuchte, gar nicht hat.

Das ist doch genau das, was ich beschrieben habe. Wen interessiert, was der empfangende Client überprüft, wenn er eh nichts damit macht oder ihm Informationen fehlen? Und genau wie du schreibst: Die Allowed IPs entscheiden darüber, wohin die Daten fließen. Und da wg auch direkt die Routen dafür anlegt, kann man sich da über falsche Einträge auch mal schnell vom Zugang oder vom Internet aussperren. Hier sorgt der Eintrag dafür, dass die Pakete fürs Fritzbox Netz zum iPhone gesendet werden.

@00philip Die Konfigurationen der Endgeräte sehen soweit gut aus. Wenn du jetzt noch die Server-Konfiguration so anpasst, wie ich es oben beschrieben habe, dann könnte es schon klappen,

Ohne einen Überblick über die Netzwerk-Konfiguration zu haben, wird es schwierig. Dennoch fallen hier direkt einige Dinge auf, die so eigentlich nicht sein können.

1. Wofür brauchst du die MASQURADE Regel? Es geht doch um einen Heimnetz-Zugang. Dafür brauchst du eigentlich gar kein NAT.
2. Zur Fritzbox erlaubst du nur eine IP mit /32. Gehen wir davon aus, dass das die IP der Fritzbox ist, dann kannst du nur auf die Fritzbox zugreifen, aber nicht aufs Heimnetz
3. Dafür steht das Subentz der Fritzbox im iPhone Eintrag. Da hat es wirklich gar nichts zu suchen, denn damit leitest du den Traffic, der eigentlich ins Frirtzbox Netz gehen sollte, zum iPhone.

Grundsätzlich: Mach dir klar, welche Daten wohin fließen müssen. In wg Konfigurationen gibt man immer nur an, welche Daten in Senderichtung fließen dürfen, aber nie, welche Daten von einem Partner empfangen werden dürfen. Das Fritzbox-Subnetz müsstest du also im iPhone und im Fritzbox-Block auf dem Server eintragen, aber nicht im iPhone Block auf dem Server. Mach dir darüber hinaus klar, was eine NAT Regel auf einem VPN Server macht. Da dein VPN Server in der "Mitte" der Verbindung sitzt, kannst du damit einen Heimnetz-Zugriff auch zuverlässig unterbinden. Nicht zuletzt: Schau dir die AVM Dokus an. LAN-LAN Konfigurationen über Fritzboxen sind speziell, vor allem im Zusammenspiel mit anderen WG Servern, da die Boxen kein Transport-Netz benutzen (Reminder: Dein MASQURADE EIntrag!). Und nicht zu vergessen: ip_forward ist an auf dem Server?

Wenn du weitere Hilfe benötigst, brauchen wir als Erstes eine exakte Übersicht über deine Netzwerkkonfiguration, also welche Sub-Netze sind wo im Einsatz. Danach dann die Konfigurationen aller beteiligten wg Partner.

It depends, which IPv6 is the right one.

Both addresses ::1 and ::54b6:93ff:fe35:219b can be used in general. The EUI-64 identifier is the one netcup is "officially" using to address the server. If you are buying additional /64 networks, they will be routed to your ::54b6:93ff:fe35:219b address.

Nevertheless, you can use the ::1 address, at least as additional address on your interfaces. In any case you have to ensure, the DNS entries are using the correct address, in particular for Let's Encrypt. Firewall rules etc. have to consider the addresses as well.

Ja, nutze ich problemlos seit 2022. Die Themen rund um DNSSEC kamen meines Erachtens daher, dass man den systemd-resolved so einstellen konnte, dass er strikt DNSSEC forderte - was bei vielen Aufrufen zwangsläufig scheiterte. Erschwerend kam hinzu, dass einige Distributionen ihn so standardmäßig auslieferten - und dann hat sich bei vielen der Eindruck manifestiert, dass er nicht funktioniert, und dass es am DNSSEC liegt. Dabei ist es am Ende einfach nur eine Frage der korrekten Konfiguration. Ich hab heute noch "DNSSEC=allow-downgrade" drin.

Zitat von svenn

Ist PMTU-Discovery anbieterseitig kaputt / blockiert aufgrund von "ICMP drop any" oder ähnlichem wird die Verbindung bei MTU-Unterschieden zwischen Server und Client kein Spass

Das ist kein CG-NAT-spezifisches Problem.

Zitat von svenn

WireGuard: theoretisch kein Einfluss, ausser bei z.B. o² - dort gehen je nach Setup die Keepalives nicht, sobald sich die CGNAT-IP ins Internet ändert.

Das ist ebenfalls kein CG-NAT, sondern eine Wireguard-Problem, das bei jeder dynamischen IP auftritt - selbst wenn beide Seiten öffentliche IPs haben.

Zitat von svenn

Das DG-Problem mit VPNs aller Art ist mir (leider aus eigener Erfahrung) ein bekanntes Thema

Kann ich überhaupt nicht bestätigen.

Zitat von svenn

Was du aus meiner Sicht dagegen tun kannst: Dein Glück versuchen und nach einer dynamischen / statischen v4 bei der DG fragen

Das hat DG noch nie gemacht.

Zitat von svenn

Kurz und knapp: CGNAT ist generell "böse" was VPNs, VOIP, Games und co. anbetrifft

Zumindest für VPN ist das Unsinn. CGNAT wird nur zum Problem, wenn PPTP strikt ausgelegt wird und nur eine Verbindung pro Quell-IP zulässt. Aber PPTP nutzt eh niemand mehr. Für IPSec gibt es NAT-T. Auf OpenVPN oder Wireguard hat es gar keinen Einfluss.

Du hast offenbar über den VPN Tunnel gemessen. Das ist natürlich wenig hilfreich, wenn du die Paketfehlerraten des Anschlusses feststellen willst. Du musst natürlich über die direkte Verbindung messen, wenn es dir darum geht.

Aber du erreichst mit UDP über den Tunnel 183 MBit/s, das ist bei 200 MBit/s Upload genau der Wert, der zu erwarten ist. Bei mir sind es 187 MBit/s, das passt also. Was komisch ist, obwohl du mit 300 MBit/s sendest und nur 180 ankommen, ist die Paketfehlerrate 0. Die ist bei mir 37% in einer Messung mit den gleichen Parametern.

Wie dem auch sei, der VPN Tunnel scheint perfekt zu funktionieren. Alles andere ist dein Applikationssetup. Wenn du mit TCP schwankende Bandbreiten feststellt, kommen wieder MTU und MSS ins Spiel. Funktioniert die Path MTU Discovery auf der Strecke?