[Frage] FRITZ!Box WireGuard mit einem VPN-Anbieter verbinden | dann gehen aber keine Wireguard Verbindungen mehr "zur" Box?!

[chrsto]

Musstest Du da auch etwas editieren

Nein. Bei mir standen dort allerdings andere IP Adressen drin: 10.2.x.x statt 10.20.x.x

 

[buddsoup]

Nein. Bei mir standen dort allerdings andere IP Adressen drin: 10.2.x.x statt 10.20.x.x

Ok - danke Dir für die Info.
Das war ein Copy-Paste-Fehler von mir. Bei mir standen/stehen auch 10.2.x.x drin.

 

[frank_m24]

Ich habe das Netz der fritz.box von 192.168.178.x auf ein 10.20.x.x Netz verändert.

Dann wird das vermutlich der Grund für den Konflikt sein. Welche Netzmaske hast du da vergeben?

 

[buddsoup]

Welche Netzmaske hast du da vergeben?

255.255.255.0
Hatte danach aber ja auch Werksreset gemacht und mit einer IP aus dem 192.168.222.x (255.255.255.0) probiert.
Das ging auch nicht.

 

[Benares]

Mmh, ich tippe eher darauf, dass

AllowedIPs = 0.0.0.0/0

die Ursache ist. Damit läuft der komplette Verkehr über den VPN-Provider-Tunnel und für eine Host-Anbindung (z.B. 192.168.222.0/24) bleibt nichts mehr übrig.

 

[buddsoup]

Mmh, ich tippe eher darauf, dass

AllowedIPs = 0.0.0.0/0

die Ursache ist.

Komisch, dass es mit der Config bei @chrsto aber läuft.

 

[frank_m24]

AllowedIPs = 0.0.0.0/0

Hatte ich auch im Verdacht, aber ohne das macht so ein VPN Provider ja gar keinen Sinn. Aber man könnte das Subnetz ja mal rausnehmen, dafür gibt es ja so Kalkulatoren.

 

[buddsoup]

Hatte ich auch im Verdacht, aber ohne das macht so ein VPN Provider ja gar keinen Sinn.

So schaut es aus. Was ich einfach nicht verstehe, dass es bei @chrsto in dem Standard-Setup so läuft und bei mir immer wieder der Fehler kommt.

Im Log der Box sind es auch immer wieder die gleichen Fehler die angezeigt werden:

2024-01-14 16:50:21.134 - Device - Detected new not-mastered slave (WG_TEST)​

2024-01-14 16:50:21.143 - Slave - Slaves network conflicts with existing peer​

2024-01-14 16:50:21.143 - Device - Could not add connection for not mastered slave​

​

Was mir noch gerade als Idee kommt ist, dass es evtl. am myfritz.net Dienst liegt und @chrsto evtl. ja etwas anderes nutzt?

 

[frank_m24]

Teste es trotzdem mal ohne dein Heim-Subnetz. Und Regelverstöße werden immer noch nicht gern gesehen! Man kann seine Beiträge editieren, auch jetzt noch!

 

[buddsoup]

Teste es trotzdem mal ohne dein Heim-Subnetz.

Was meinst Du damit genau?

Und Regelverstöße werden immer noch nicht gern gesehen! Man kann seine Beiträge editieren, auch jetzt noch!

Dachte, wenn es um was separates geht, dass es man es dann in einem extra Beitrag schreibt. Versuche mich zu bessern (sorry).

 

[frank_m24]

Versuche mich zu bessern (sorry).

Und warum änderst die Beiträge dann nicht? Wie gesagt: Das geht auch jetzt noch!

Was meinst Du damit genau?

Du klammerst dein Subnetz aus den Allowed IPs aus. Dafür gibt es extra "Wireguard Allowed IP Kalkulatoren" im Internet.

 

[buddsoup]

Du klammerst dein Subnetz aus den Allowed IPs aus.

Das habe ich probiert. Dann kommt auch der "Netzwerkkonflikt".

Was klappt ist, wenn ich eine Config baue, wo ich "nicht" den gesamten Verkehr über IPv4 raussende. Dann kann ich danach ein Client-VPN erstellen und auch verbinden.

Klappt zwar auf dem Weg, bringt halt nur nix, weil das ProtonVPN dann ja nicht entspr. routet.

 

[frank_m24]

Was klappt ist, wenn ich eine Config baue, wo ich "nicht" den gesamten Verkehr über IPv4 raussende.

Aber was ist denn dann der Unterschied zu dem Fall, dass du dein lokales Subnetz entfernst?

 

[buddsoup]

Aber was ist denn dann der Unterschied zu dem Fall, dass du dein lokales Subnetz entfernst?

Gute Frage, das eine klappt, das andere halt nicht und es kommt entspr. Fehlermeldung der fritz.box

Habe es auch schon probiert, dass ich quasi die ProtonVPN Verbindung baue, IPv4 rausnehmen, Client-VPN erstelle, danach wieder all-taffic via IPv4 anstelle. Kommt zwar keine Fehlermeldung, aber er Verbindet sich dann nicht.

 

[Benares]

Mal konkret, was hast bei "AllowedIPs =" mittlerweile drin?

 

[buddsoup]

"AllowedIPs =" mittlerweile drin?

- Am Anfang halt mit der Standard Konfig: 0.0.0.0/0
- danach mit: 0.0.0.0/5, 8.0.0.0/7, 10.0.0.0/12, 10.16.0.0/14, 10.20.0.0/22, 10.20.5.0/24, 10.20.6.0/23, 10.20.8.0/21, 10.20.16.0/20, 10.20.32.0/19, 10.20.64.0/18, 10.20.128.0/17, 10.21.0.0/16, 10.22.0.0/15, 10.24.0.0/13, 10.32.0.0/11, 10.64.0.0/10, 10.128.0.0/9, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/1
(was soviel bedeutet wie 10.20.4.0/24 Netz ausgeschlossen > weil mein eigenes Netz mit 255.255.255.0 Maske)

EDIT: Bei der Standard Konfig verbindet er sich mit dem VPN-Anbieter (Proton), ich kann danach aber keine weiteren Client-VPNs mehr erstellen.
Bei der 2. Variante lässt er mich noch nicht mal mehr den VPN-Anbieter (Proton) erstellen und meldet schon Fehler.

 

[frank_m24]

Habe es auch schon probiert, dass ich quasi die ProtonVPN Verbindung baue, IPv4 rausnehmen, Client-VPN erstelle, danach wieder all-taffic via IPv4 anstelle.

Ach, du meinst diesen Haken, den du zusätzlich setzt? Brauchst du den sicher? Weil Allowed IPs 0.0.0.0/0 bewirkt genau das gleiche, wie dieser Haken.

 

[buddsoup]

Ach, du meinst diesen Haken, den du zusätlich setzt?

Ja genau den. Wenn ich den rausnehme, dann geht es nicht obwohl weiterhin dort 0.0.0.0/0 steht.

 

[buddsoup]

Ich habe mir die Sache jetzt noch einmal angeschaut und auch recherchiert.

Wenn ich das jetzt richtig verstanden habe, dann kann das so eigentlich nicht gehen? Bzw. wenn man das AVM Support-Dokument so liest wie es geschrieben steht:
Ich meine hier Punkt 1 des Links, sprich bei einem VPN-Anbieter wird ja der ganze Traffic schon getunnelt und somit ist wohl kein weiterer VPN mehr möglich?

AVM Wissensdokument #3712

Oder hat das damit nichts zu tun und AVM meint damit, dass kein weiterer VPN-Anbieter bzw. weitere entfernte Box möglich ist, aber Wireguard-VPN-Clients gehen trotzdem?

 

[frank_m24]

Ja, das wird mit dem Haken nicht funktionieren. Wenn überhaupt, dann nur ohne diesen Haken.