[Frage] Freetz-NG // Wireguard

syncgw

Neuer User
Mitglied seit
26 Feb 2017
Beiträge
13
Punkte für Reaktionen
0
Punkte
1
Hei,
ich wollte mal wirguard ausprobieren. Ziel ist es, dass ich (und meine Frau) sich auf meine FritzBox 7490 aus dem Ausland verbinden kann und auf das NAS (192.168.10.10) zugreifen kann.

Was ist soweit fertig gestellt habe:
  1. Aktuelles Freetz mit Wireguard, Replace Kernel und AVM-portfd kompiliert und auf Box eingespielt
  2. geöffneten Ports für den Zugriff aus dem Internet : 51200, UDP, IPv4, UDP 51200
  3. Wireguard IP-Adresse: 10.0.0.1/24
  4. Server-Konfiguration:
    [Interface] ListenPort = 51200 PrivateKey = Private-Server-Key [Peer] PublicKey = Public-Client1-Key PublicKey = Public-Client2-Key
  5. Wireguard gestartet. Scheint zu funktionieren:
    wg0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.0.0.1 P-t-P:10.0.0.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
  6. Dann Tunsafe Win10 Client installiert
  7. Client Konfiguration
    [Interface] PrivateKey = Private-Client1-Key DNS = 192.168.10.250 Address = 10.0.0.1/24 [Peer] PublicKey = Public-Server-Key AllowedIPs = 192.168.10.0/24 Endpoint = xxx.myfritz.net:51200 PersistentKeepalive = 25
Soweit ich Wireguard verstanden habe, so sollte das so funktionieren. Es kommt aber auf dem Client immer nur die Meldungen

[16:24:31] Loading file: C:\Program Files\TunSafe\Config\TunSafe.conf [16:24:31] Resolved xxx.myfritz.net to 27.122.225.239 [16:24:31] TAP Driver Version 9.21 [16:24:31] Added Route 192.168.10.0/24 => 10.0.0.2 [16:24:31] Sending handshake... [16:24:36] Retrying handshake, attempt 2... [16:24:42] Retrying handshake, attempt 3... [16:24:44] Deleted Route 192.168.10.0/24 => 10.0.0.2

Hat jemand eine Idee, was ich falsch mache?
 
Zuletzt bearbeitet:
Was ist das? Das gibt es (zumindest in Freetz) gar nicht: https://github.com/Freetz/freetz/tree/master/make und lt. #1 soll das ja das genutzte Projekt sein.

Auch im Freetz-NG gibt es ein solches Paket nicht ... höchstens noch ein "avm_portfw" (https://github.com/Freetz-NG/freetz-ng/tree/master/make).

Ansonsten sollte man bei Problemen auch immer die eigene (Freetz/Freetz-NG-)Konfiguration "dazupacken" und sie nicht nur in Prosa "beschreiben" (wo kein Mensch weiß, ob das auch alles ist) ... besser aber die "komprimierte" Form, falls man das Signieren der Firmware-Images durch Freetz auch aktiviert hat (dann steht das Kennwort für den privaten Schlüssel nicht in der Konfigurationsdatei, die man den anderen zeigt - Freetz-NG handhabt das anders).

Letztlich sollte man aber auch bei der Suche nach dem Problem nicht einfach nur davon ausgehen, was man "eingestellt" hat (oder eingestellt zu haben glaubt), sondern das auch entsprechend überprüfen und sowohl auf der Seite "Sicherheit" im FRITZ!OS-GUI als auch in der Support-Datei (da noch deutlich ausführlicher) sollte ja vermerkt sein, ob die Ports auch tatsächlich freigegeben sind.

Denn das, was der Client da protokolliert, sind ja nichts weiter als "Versuche", eine Verbindung aufzubauen ... damit ist noch lange nicht gesagt, daß auch nur ein Paket tatsächlich beim Wireguard-Server ankommt - oder steht irgendetwas in dessen Protokoll? Warum wird das eigentlich so "schamhaft" verschwiegen und nicht ebenfalls gezeigt?
 
Ahoi,
es ist Freetz-NG. Support-Datei ist jetzt beigefügt. Wenn ich wüsste wo ich genauer etwas heraus finden kann, dann hätte ich da nach geschaut. Wo ich mehr Informationen her bekommen könnte, weiß ich nicht. Wenn mir jemand wie du sagst, wo noch etwas zu finden ist, dann schaue ich mir das gerne selber an.... Ich konnte nur nirgendwo (auch nicht in der HIlfe) ein HowTo WireGuard on Fritz-NG finden.

Für avm_portfw habe ich den Port konfiguriert und in der normalen FritzBox die Meldung aus Diagnose->Sicherheit mit angegeben. Also sollte alles, was an der Fritz-Box an dem Port ankommt auch in Wireguard verfügbar sein. Aber auch da gilt - ich mache erste Gehversuche mit Freetz-NG und kann mich nur anhand von Postings lang hangeln. Der vorhandene Hilfe kann ich dabei nichts wirklich hilfreiches entnehmen.

Ich kann auch gerne die Config-Datei für den make hier anhänngen - nur weiß ich nicht, welche Datei das genau ist.

TunSafe hat keinen Debug-Modus. Mehr Meldungen gibt der Client nicht aus.

Sorry, wenn mein Anfangsposting falsch rüber gekommen ist!
 

Anhänge

  • FRITZ.Box_7490_(UI)_113.07.12-freetz-ng-16946M-db88da305_2020-07-17_1850_support.tar.zip
    44 KB · Aufrufe: 23
Nimm mal den Original-Wireguard-Client für Windows, nicht TunSafe.
 
Hei Whoopie,
ok, das probier ich - vielleicht sagt der mir ja mehr...
 
Hast Du das von Hand gemacht oder ist tatsächlich eine Neuerung in Freetz-NG, die ich mir schon lange vorstellen konnte als Erweiterung ALLER Firmware-Versionen von AVM, eingezogen, ohne daß ich das bemerkt habe? (Danach suchen werde/will ich jetzt nicht.)

Im Gegensatz zur originalen Support-Datei von AVM kann/könnte man nämlich die Daten auch "spartenweise" zusammenfassen und nur das ausgeben, was für die Diagnose eines Problems einigermaßen hilfreich zu sein verspricht und nicht immer gleich alles in eine Support-Datei packen, wie es AVM macht. Auch ein kleines Programm/Skript zum Zerlegen des AVM-Formats ist eigentlich lange überfällig - ich weiß zufällig genau, daß diese Dateien bei AVM auch schon lange nicht mehr "von Hand" verarbeitet und zerlegt werden müssen, sondern daß es da entsprechende Unterstützung durch Tools gibt.

Aber die "präsentierten" Daten sind in dieser Form leider weder Fisch noch Fleisch, wenn es um die Frage geht, ob die Ports nun durchgereicht werden oder nicht. Die Informationen zu den tatsächlich erfolgreich eingerichteten Port-Weiterleitungen stehen im Abschnitt "PCPD" der AVM-Support-Datei, die mit "##### BEGIN SECTION PCPD" startet und mit "##### END SECTION PCPD" beschlossen wird. Darin sollte sich die Information finden lassen, ob der freizugebende Port tatsächlich beim "pcpd" von AVM "angemeldet" ist oder nicht.

Bei der Konfiguration ist (bei jedem Freetz-Problem, egal welcher Fork) eigentlich immer die Datei gemeint, die zeigt, welche eigenen (vom Standard abweichenden) Einstellungen jemand vorgenommen hat und das ist die ".config.compressed" im Freetz-Basisverzeichnis (ich glaube nicht, daß das in Freetz-NG anders ist), die man mittels "make config-compress" (aus dem Kopf, steht irgendwo bzw. kann durch "tab completion" der "make targets" auch automatisch angezeigt werden) erstellen kann.

An das Log des "wireguard"-LKM zu gelangen, könnte in Freetz (egal welcher Fork) tatsächlich schwierig sein ... das muß man schon mit passender Konfiguration (WIREGUARD_DEBUG=y) übersetzen (oder passendem "make target", nämlich "module-debug"), damit die entsprechenden Meldungen überhaupt enthalten sind/erzeugt werden und dann werden automatisch auch noch einige Tests eingebaut in den Code, wo ich nicht weiß, ob die auf einer FRITZ!Box auch problemlos durchlaufen. Aber theoretisch sollte es auch funktionieren (es müßte vielleicht mal jemand probieren oder es meldet sich jemand, der es schon erfolgreich durchexerziert hat) und wenn das der Fall wäre und der Kernel ohnehin ersetzt wird (dann kann man nämlich auch gleich noch "CONFIG_DYNAMIC_DEBUG" mit einbauen lassen, ansonsten sieht man die "pr_debug()"-Aufrufe (u.ä., was auf Debug-Code hinausläuft) nämlich immer noch nicht bzw. wird (ohne dynamische Auswahl) von den Infos "erschlagen"), sollte man (mit ziemlichem Aufwand, das gebe ich zu) auch entsprechende Informationen erlangen können, ob da überhaupt Pakete beim LKM ankommen. Einen dedizierten Prozess für einen Daemon gibt es bei Wireguard halt nicht: https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8

Alternativ kann man aber - wenn man die Kontaktversuche so unter Kontrolle hat, daß man tatsächlich immer davon ausgehen kann, daß eingehende Pakete vom eigenen Client stammen - auch die Paketzähler für das wg0-Interface ansehen - dann weiß man zwar nicht, was da ankommt, aber es sollte zu sehen sein, DASS etwas übertragen wurde und ans Ziel gelangte.

PS: Sorry, die erste Version war versehentlich "entwischt" beim Schreiben, daher hatte ich sie noch einmal gelöscht.
 
Soweit ich Wireguard verstanden habe, so sollte das so funktionieren.
Ob der WireGuard lauscht kann man mit z. B.:
Code:
ss -a -u -e -l -p -n | grep -i 51200
sehen bzw. ob WG-Datenpakete am Interface ankommen, kann man mit einem Filter sniffen:
Code:
tcpdump -vvveni <Interface> 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'
(Interface anpassen oder "any" benutzen).
 
@syncgw

Bitte entschuldige, wenn ich mich hier mal "kontraproduktiv" einmische. Kontraproduktiv nenne ich das deswegen, weil ich selbst zwar schon recht lange und vom ersten Moment an auch problemlos Wireguard nutze, aber deswegen keine F!B "zerbastelt" habe. (Und JA, ich habe auch viele Jahre "gefreetzt".)

Ich wollte also zuerst auch erst einmal Wireguard ausprobieren.
Also habe ich mir zwei sonst nicht mehr genutzte Raspberry Pi 2B gegriffen und allein mit der vorhandenen Dokumentation zwei WG-Server aufgesetzt. Hat einen Nachmittag mit Einlesen in die Dokumente und Anwenden gedauert und lief auf Anhieb. Zwei oder drei Monate, nachdem ich das gemacht hatte, standen in der c't einige sehr gute Artikel, mit denen das noch wesentlich schneller geht (aber vlt. ohne den von mir gewollten eigenen Lernvorgang?).

Mittlerweile habe ich "aufgerüstet". Habe mir in der Bucht für je 5-10€nen 6 Stück F!B 7412 geholt und diese mit OpenWRT geflasht und darauf WG eingerichtet. Auch hierfür gibt es eine ausgezeichnete Anleitung in der c't. Nach etwas Übung brauche ich jetzt max. eine Stunde und der WG-Server läuft.

Jetzt betreibe ich ein eigenes VPN-Netz mit 5 in Deutschland und in zwei weiteren europäischen Ländern verteilt stationierten WG-Servern, welche direkt miteinander vernetzt sind. Und an jedem Server sind alle "außerhäusig" betriebenen mobilen Geräte der jeweiligen Nutzer dauerhaft mit dem Heimnetz verbunden. Hauptzweck ist aber die verteilte vollautomatische Datensicherung unserer Rechner (per Duplicati) reihum auf die NAS meiner Freunde. So ganz nebenbei telefonieren wir miteinander über das VPN und den nicht in DL lebenden Freunden ist es möglich, die aus nicht verständlichen Gründen installierte Blockade der dt. Mediatheken zu umgehen.
Dass wir unsere Upload-Geschwindigkeit über das VPN fast vollständig auslasten können, erwähne ich nur am Rande.

Ich schreibe dir das, weil ich niemals auf die Idee kommen würde, dafür meine F!B 7590 zu freetzen. Allein der Gedanke, dass da vlt. temporär einige Zeit keine Internet-Verbindung zustände kommt (WAF) schreckt mich ab. Und ich würde auch niemals auf einem Gerät, welches per TR-096 erreichbar ist, ein VPN als vertrauenswürdig einstufen. (Ich weiß, dass mir jetzt gleich wieder jemand einen Aluhut aufsetzen wird. Ich kann damit leben. Aber mein beruflicher Hintergrund meldet sich wieder lautstark zu Wort.)


MfG Peter
 
  • Like
Reaktionen: rmh
Zwischenbericht:
  • @PeterPawn FREETZ-NG kann jetzt auch bei richtiger Konfiguration angeblich WireGuard. Die Support-Datei habe ich über das WebIF gezogen
  • Stopp WG und keine Port-Freigabe über avm_portfw. ipvoid gibt status ICODE]Open|filtered[/ICODE] zurück
  • Stopp WG und Freigabe Port über avm_portfw. ipvoid gibt status Closed zurück
  • Start WG und Freigabe Port über avm_portfw. ipvoid gibt status Open|filtered[/ zurück. Also sieht es für erstmal so aus, als ob sich WG an den Port connected.
  • @sf3978 Rudi-Shell (in FREETZ-NG) kennt die Befehle nicht. In welchem Paket sind die enthalten?
  • Ping funktioniert auf die WG-IP-Adresse, aber Zähler ändert sich nicht
  • @Whoopie Danke für den Tipp. Nutze jetzt den offiziellen WG-Client.
  • Dann dachte ich mir, ich versuche einen erst einmal überhaupt eine Verbindung mit einem WG-Server zustande zu bekommen. Also habe ich lokal im Win10 nach dieser Anleitung einen WG-Server gestartet und die beigefügten Konfigurationsdateien installiert (muss man in .conf umbenennen). Dann die Netzwerkverbindung vom Laptop ausgeschaltet und den Firewall für Private Netzwerke ausgeschaltet. Ich scheine immer noch irgend etwas falsch zu machen - auch da gibt es immer nur Handshake did not complete after 5 seconds. Dabei kann es doch keine Portforwarding oder sonstige Probleme geben, wenn ich auf einer Maschiene den Server und den Client laufen habe...
  • Jetzt habe ich erst einmal genug für heute und gehe lieber Grillen :)
 

Anhänge

  • Client.txt
    240 Bytes · Aufrufe: 17
  • Server.txt
    207 Bytes · Aufrufe: 12
  • wireguard-log.txt
    12.9 KB · Aufrufe: 10
Die Endpoint-IP muss die des LAN-Interfaces sein, also z.B. 192.168.178.101, wenn du es lokal testen möchtest.
 
@sf3978
Rudi-Shell (in FREETZ-NG) kennt die Befehle nicht. In welchem Paket sind die enthalten?
Du kannst auch netstat benutzen. Z. B.:
Code:
netstat -ulpena | grep -i 51200
  • Ping funktioniert auf die WG-IP-Adresse, aber Zähler ändert sich nicht
BTW: Den Filter mit tcpdump musst Du auf das wan-Interface (d. h. das Interface des Endpoints) anwenden und nicht auf das WireGuard-Interface (wg oder gleichwertig). Denn es geht ja um den Tunnel und _nicht_ um die Daten bzw. den Traffic _im_ Tunnel.
 
@Whoopie Ich habe es auch mit (unbenutzten) Adressen aus dem lokalen Netz probiert - es kommt das selbe Ergebnis
Code:
2020-07-19 12:18:25.571774: [TUN] [Test] Startup complete
2020-07-19 12:18:43.892882: [TUN] [Test] peer(1FtR…xgUU) - Retrying handshake because we stopped hearing back after 15 seconds
2020-07-19 12:18:43.900879: [TUN] [Test] peer(1FtR…xgUU) - Sending handshake initiation
2020-07-19 12:18:49.189439: [TUN] [Test] peer(1FtR…xgUU) - Handshake did not complete after 5 seconds, retrying (try 2)
2020-07-19 12:18:49.196307: [TUN] [Test] peer(1FtR…xgUU) - Sending handshake initiation
2020-07-19 12:18:54.373561: [TUN] [Test] peer(1FtR…xgUU) - Handshake did not complete after 5 seconds, retrying (try 3)
2020-07-19 12:18:54.376561: [TUN] [Test] peer(1FtR…xgUU) - Sending handshake initiation
2020-07-19 12:18:59.648068: [TUN] [Test] peer(1FtR…xgUU) - Handshake did not complete after 5 seconds, retrying (try 4)
2020-07-19 12:18:59.656064: [TUN] [Test] peer(1FtR…xgUU) - Sending handshake initiation
2020-07-19 12:19:04.987505: [TUN] [Test] peer(1FtR…xgUU) - Handshake did not complete after 5 seconds, retrying (try 5)
@sf3978 Das ist das Ergebnis von netstat -ulpena | grep -i 51200
Code:
udp        0      0 0.0.0.0:51200           0.0.0.0:*                           -
udp        0      0 :::51200                :::*                                -
Ist das ein gutes Ergebnis?
 

Anhänge

  • wg.zip
    695 Bytes · Aufrufe: 4
Code:
# status IP forwarding
> sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1

Code:
# Wireguard
> lsmod | grep wire
wireguard             157850  0

Code:
# Port
> netstat -ulpena | grep -i 51200
udp        0      0 0.0.0.0:51200           0.0.0.0:*                           -
udp        0      0 :::51200                :::*                                -

Code:
# Trace
> tcpdump -vvveni wlan 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000' &>/tmp/wg &
> cat /tmp/wg
tcpdump: WARNING: wlan: no IPv4 address assigned
tcpdump: listening on wlan, link-type EN10MB (Ethernet), capture size 65535 bytes
09:28:05.585029 d8:12:65:5a:8f:95 > 7c:ff:4d:71:24:7e, ethertype IPv4 (0x0800), length 190: (tos 0x0, ttl 128, id 65452, offset 0, flags [none], proto UDP (17), length 176)
    192.168.10.106.49881 > 46.142.86.120.51200: [udp sum ok] UDP, length 148
09:28:22.986888 7c:ff:4d:71:24:7e > 3e:51:f5:03:36:3e, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 57, id 51901, offset 0, flags [DF], proto UDP (17), length 116)
    212.227.67.33.3478 > 192.168.10.101.45505: [udp sum ok] UDP, length 88
09:28:23.008275 7c:ff:4d:71:24:7e > 3e:51:f5:03:36:3e, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 56, id 36232, offset 0, flags [DF], proto UDP (17), length 116)
    212.227.67.34.3478 > 192.168.10.101.45505: [udp sum ok] UDP, length 88
09:28:23.008769 7c:ff:4d:71:24:7e > 3e:51:f5:03:36:3e, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 56, id 36234, offset 0, flags [DF], proto UDP (17), length 116)
    212.227.67.34.3479 > 192.168.10.101.45505: [udp sum ok] UDP, length 88

4 packets captured
4 packets received by filter
0 packets dropped by kernel

und nu?
 
Code:
# Trace
> tcpdump -vvveni wlan 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000' &>/tmp/wg &
> cat /tmp/wg
tcpdump: WARNING: wlan: no IPv4 address assigned
tcpdump: listening on wlan, link-type EN10MB (Ethernet), capture size 65535 bytes

09:28:05.585029 d8:12:65:5a:8f:95 > 7c:ff:4d:71:24:7e, ethertype IPv4 (0x0800), length 190: (tos 0x0, ttl 128, id 65452, offset 0, flags [none], proto UDP (17), length 176)
    192.168.10.106.49881 > 46.142.86.120.51200: [udp sum ok] UDP, length 148

09:28:22.986888 7c:ff:4d:71:24:7e > 3e:51:f5:03:36:3e, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 57, id 51901, offset 0, flags [DF], proto UDP (17), length 116)
    212.227.67.33.3478 > 192.168.10.101.45505: [udp sum ok] UDP, length 88
09:28:23.008275 7c:ff:4d:71:24:7e > 3e:51:f5:03:36:3e, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 56, id 36232, offset 0, flags [DF], proto UDP (17), length 116)
    212.227.67.34.3478 > 192.168.10.101.45505: [udp sum ok] UDP, length 88
09:28:23.008769 7c:ff:4d:71:24:7e > 3e:51:f5:03:36:3e, ethertype IPv4 (0x0800), length 130: (tos 0x0, ttl 56, id 36234, offset 0, flags [DF], proto UDP (17), length 116)
    212.227.67.34.3479 > 192.168.10.101.45505: [udp sum ok] UDP, length 88
tcpdump sollte man vor dem herstellen der Verbindung zum WireGuard-Server, starten.
Ersichtlich ist nur eine einzige eingehende UDP-Verbindung zum Port 51200.

Ich weiß jetzt nicht, wie man den WG-Filter 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000' den anderen gesnifften Verbindungen zuordnen kann.
Kannst Du die IP-Adressen 212.227.67.33, .34, 192.168.10.101 und den Port 45505 bzw. die MAC-Adresse 3e:51:f5:03:36:3e zuordnen?
 
@sf3978 tcpdump habe ich zuerst gestartet und dann versucht die WG-Verbndung aufzubauen. Dann zwei Handshake did not complete abgewartet. Die 192.168.10.101 und die MAC stammen von meinem Handy im lokalen Netz. Ich nehme mal, dass es mit irgendeinen Android-App-Server schwätzt.
 
Ich nehme mal, dass es mit irgendeinen Android-App-Server schwätzt.
OK und auf deinem Handy ist WireGuard schon installiert? ... weil mit tcpdump und dem WG-Filter, Traffic vom Handy für das WireGuard-Protokoll gesnifft wird. ... oder wird mit diesem Filter evtl. auch andere Traffic erfasst?
 
Oh.. da hast du recht. Auf dem Handy ist kein WireGuard installiert. Die IP und MAC ist aber eindeutig in der Fritz-Box dem Handy zugeordnet. 212.227.67.3 konnte ich Zwischenzeit meinem DSL und Telefonie-Anbieter IONOS Server von 1&1 zuordnen. Ich werde es mal mit einem anderen Port ausprobieren.
 
Ich werde es mal mit einem anderen Port ausprobieren.
Ich denke, den Traffic mit dem Handy kannst Du ignorieren und einen anderen Port (als 51200) brauchst Du auch nicht. Ich habe das nur merkwürdig gefunden, dass man mit diesem Filter auch anderen Traffic als den des WireGuard, sniffen kann.

Auf
Code:
09:28:05.585029 d8:12:65:5a:8f:95 > 7c:ff:4d:71:24:7e, ethertype IPv4 (0x0800), length 190: (tos 0x0, ttl 128, id 65452, offset 0, flags [none], proto UDP (17), length 176)
    192.168.10.106.49881 > 46.142.86.120.51200: [udp sum ok] UDP, length 148
vom Client, hätte der Server antworten müssen, was er aber lt. tcpdump nicht getan hat. Evtl. stimmt die Konfiguration (Server und/oder Client) noch nicht so richtig.
 
Nachdem ich nochmal im Web nach Wireguard gesucht habe, bin ich auf dieses Tool gestoßen. Damit hat es dann geklappt.
 
Nachdem ich nochmal im Web nach Wireguard gesucht habe, bin ich auf dieses Tool gestoßen. Damit hat es dann geklappt.
Und wie sehen die Konfigurationen damit dann jetzt aus?

Wireguard IP-Adresse: 10.0.0.1/24
Client Konfiguration
[Interface] Address = 10.0.0.1/24 [Peer] AllowedIPs = 192.168.10.0/24
Für mein Verständnis hattest Du in Deiner ursprünglichen Konfiguration sowohl für den Server als auch für den Cleint die gleiche IP-Adresse 10.0.0.1 verwendet - das kann so eigentlich nicht funktionieren...

Wenn beim Server 10.0.0.1/24 als Adresse eingetragen ist, müsste beim Client unter Interface z.B. Address = 10.0.0.2/24 stehen.
Und bei Peer sollte der m.E. der Adressbereich auch unter AllowedIPs eingetragen sein: AllowedIPs = 10.0.0.0/24, 192.168.10.0/24
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.