[Gelöst] Wireguard-Server - kein Routing ins Heimnetz?

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Massa

Massa

Mitglied
Mitglied seit
18 Dez 2004
Beiträge
224
Punkte für Reaktionen
4
Punkte
18
Hallo zusammen,

ich wollte den Wireguard-Server in Freetz-NG aktivieren und dazu nutzen, um von unterwegs mit meinem Windows-Laptop einfach auf mein Heimnetz zuzugreifen (und zwar ohne, dass ich eine "andere" Internetverbindung verliere - d.h. eine Split-Konfiguration).

Hierzu habe ich zuerst auf der FB per ssh mit dem "wg"-Kommando einen neuen privaten Schlüssel generiert (wg genkey) und daraus einen öffentlichen abgeleitet (wg pubkey .
Den privaten habe ich in der wireguard-Web-Konfigseite unter "[INTERFACE]" eingetragen, den öffentlichen habe ich bei meinem Windows-Client unter "[Peer]" eingetragen.
Als IP-Adressbereich habe ich IPv4 192.168.130.0/24 gewählt - beim FB-Server habe .20 als Adresse eingetragen, beim Client .21
Die Server-Konfiguration sieht bei mir so aus:
INI: 
[Interface]
# privater Server-Key:
PrivateKey = <generierter FB-Server-Private-Key>
# Anmerkung: Adresse ist auf der Hauptseite eingetragen...
#Address    = 192.168.130.20/24
ListenPort = 42678

[Peer]
# öffentlicher Client-Key:
PublicKey  = <mit dem wireguard-Windows-Client generierter Public-Key>
AllowedIPs = 192.168.130.21/32
# in Sekunden:
PersistentKeepalive = 21

Auf dem Windows-Client mit dem offiziellen wireguard-Client (v0.1.1) sieht die Tunnel-Konfiguration so aus:
INI: 
[Interface]
PrivateKey = <wireguard Windows-Client-Private-Key>
Address = 192.168.130.21/24
DNS = 192.168.130.20, meinedomain.internal

[Peer]
PublicKey = <vom FB-Server aus dem privaten Schlüssel generierter Public-Key>
AllowedIPs = 192.168.130.20/32
Endpoint = mydyndns.name:42678
PersistentKeepalive = 21
(Anmerkung: das "meinedoamain.internal" hinter dem DNS-Eintrag führt dazu, dass das bei Windows als "Verbindungsspezifisches DNS-Suffix" eingetragen wird - k.A. ob das so gewollt oder ein Bug vom Windows-Client ist...).

Eine Verbindung lässt sich aufbauen - auch ein Ping von beiden Seiten auf die jeweils andere IP-Adresse funktioniert.
Auch die DNS-Namensauflösung meiner internen Rechner über den Wireguard FB-Server funktioniert.
Aber mehr nicht - ich erreiche keine meiner internen Adressen (alle im Subnet 192.168.0.0/24).
Da wird also keine Route für das Subnet gesetzt - dachte ich...
...also habe ich testweise auf meinem Windows-Rechner über route add 192.168.0.0 mask 255.255.255.0 192.168.130.20 mal eine Route hinzugefügt
(wenn's dann mal geht, sollte das später dann irgendwie automatisch funktionieren - aber "PostUp" etc. gibt es im Windows-Client nicht; aber das ist ein später zu lösendes Problem - erst einmal muss es überhaupt funktionieren).
Das bringt aber leider auch nichts - "ping" und "tracert" auf Rechner in meinem Heim-Netzwerk (z.B. auf die LAN IP-Adresse der FB) gehen ins Leere (sprich: timeout)....

Muss ich da auf der Box noch eine Route anlegen? Oder in der Firewall was freischalten?
Oder mache ich noch was grundsätzliches falsch?

Hat das jemand bei sich am Laufen?

Hier noch die Ausgabe von ifconfig wg0 auf der FB:
Code: 
wg0       Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.130.20  P-t-P:192.168.130.20  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:333 errors:0 dropped:0 overruns:0 frame:0
          TX packets:220 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:28568 (27.8 KiB)  TX bytes:29272 (28.5 KiB)
das bei stehender (!) Verbindung zum Client - das mit dem "Link encap: UNSPEC" kommt mir komisch vor...
 
Insti schrieb:
und in welchem Subnet ist dein Windows WG Client?
Zum Vergrößern anklicken....
Das hängt davon ab, wo ich mich befinde - bei meinen aktuellen Tests bin ich z.B. in einem lokalen 172.30.0.0/16 Netzwerk, das aber ebenfalls über einen Router / NAT mit dem Internet verbunden ist...

Aber das sollte doch eigentlich keine Rolle spielen, oder doch?
Nachdem die Verbindung erfolgreich aufgebaut wurde, habe ich ja die virtuelle Schnittstelle mit der IP-Adresse 192.168.130.21 und der Netzmaske 255.255.255.0 - und da müsste doch eigentlich "nur" bekannt gemacht werden, dass das 192.168.0.0/24-Netzwerk über diese Schnittstelle (bzw. deren Gateway-Adresse auf der anderen Seite, d.h. 192.168.130.20) zu routen ist, oder nicht?
Deswegen ja die manuellen "route add"-Befehle - die aber leider nichts gebracht haben...
 
Massa schrieb:
Aber das sollte doch eigentlich keine Rolle spielen, oder doch?
Zum Vergrößern anklicken....
Doch. Der Client darf nicht im gleichen Subnet sein wie der Server. Einfach erklärt, die Subnet IP des VPN Client muss sich mindestens im 3 Block von der ipv4 des Server unterscheiden. Bsp.
- Server 192.168.178.1 / Client 192.168.178.25 damit bekommst du eine Verbindung aber erreichst keinen Host.
- Server 192.168.178.1 / Client 192.168.1.25 damit geht es.
 
Massa schrieb:
Nachdem die Verbindung erfolgreich aufgebaut wurde, habe ich ja die virtuelle Schnittstelle mit der IP-Adresse 192.168.130.21 und der Netzmaske 255.255.255.0 - und da müsste doch eigentlich "nur" bekannt gemacht werden, dass das 192.168.0.0/24-Netzwerk über diese Schnittstelle (bzw. deren Gateway-Adresse auf der anderen Seite, d.h. 192.168.130.20) zu routen ist, oder nicht?
Zum Vergrößern anklicken....
Versuch mal auf der FB in der [Peer]-Section mit:
Code: 
AllowedIPs = 192.168.130.21/32,  192.168.0.0/24
 
Insti schrieb:
Doch. Der Client darf nicht im gleichen Subnet sein wie der Server. Einfach erklärt, die Subnet IP des VPN Client muss sich mindestens im 3 Block von der ipv4 des Server unterscheiden.
Zum Vergrößern anklicken....
Achso, ja - das ist klar; aber das ist nicht der Fall.

sf3978 schrieb:
Code: 
AllowedIPs = 192.168.130.21/32,   192.168.0.0/24
Zum Vergrößern anklicken....
Das hat keinen Effekt.

Ich habe auch schon versucht, ob eine direkte Host-Route auf die LAN-Adresse der FB funktioniert:
Code: 
route add 192.168.0.10 mask 255.255.255.255 192.168.130.20
Auch ohne Effekt... :confused:

Es scheint mir so, als ob die wg0-Schnittstelle in der Fritzbox eine "Sackgasse" ist und innerhalb der FB nicht weitergeroutet bzw. durch eine Firewall-Regel blockiert wird (die Routing-Tabelle sieht auf der FB für mich ebenfalls O.K. aus)

[EDIT]: in Internet-Anleitungen für die Einrichtung von Wireguard steht bei Linux-Servern ganz oft noch folgendes mit drin:
Code: 
PostUp = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
Ist das bei der FB auch notwendig?
Falls ja, wie würde die entsprechenden Kommandos hier aussehen?
 
Massa schrieb:
Es scheint mir so, als ob die wg0-Schnittstelle in der Fritzbox eine "Sackgasse" ist und innerhalb der FB nicht weitergeroutet bzw. ...
Zum Vergrößern anklicken....
Versuch mal in der FritzBox mit einer statischen Route in das Subnetz/netmask der FritzBox und der IP-Adresse des wg0-Interfaces als gateway.

Massa schrieb:
Code: 
PostUp = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
Zum Vergrößern anklicken....
Ich denke in der FritzBox ist das source-NAT (MASQUERADE) für alle Interfaces schon per default aktiviert.
 
sf3978 schrieb:
Versuch mal in der FritzBox mit einer statischen Route in das Subnetz/netmask der FritzBox und der IP-Adresse des wg0-Interfaces als gateway.
Zum Vergrößern anklicken....
Meinst Du:route add -net 192.168.0.0/24 gw 192.168.130.20 dev wg0?
Das funktioniert auch nicht - es erscheint mir aber auch nicht sinnvoll - das würde ja bedeuten, dass die Suche bei Aufruf einer 192.168.0.x-Adresse (je nach Metrik) nicht nur auf der LAN-Schnittstelle sondern auch auf der Wireguard-Schnittstelle gesucht würde.
Und da gibt's diese Adressen ja nicht - es ist ja eher der umgekehrte Fall; ich muss auf dem Windowsrechner wissen, dass die Suche nach 192.168.0.x-Adressen auf der Wireguard-Gateway stattfinden soll und nicht beim Default-Gateway...

sf3978 schrieb:
Ich denke in der FritzBox ist das source-NAT (MASQUERADE) für alle Interfaces schon per default aktiviert.
Zum Vergrößern anklicken....
Wo/wie kann ich das abfragen?
iptables gibt es ja auf der Box nicht?!
 
Massa schrieb:
...; ich muss auf dem Windowsrechner wissen, dass die Suche nach 192.168.0.x-Adressen auf der Wireguard-Gateway stattfinden soll und nicht beim Default-Gateway...
Zum Vergrößern anklicken....
Dann teste mal auf dem Windows-Rechner mit wireshark (oder gleichwertig), ob ein Ping auf eine 192.168.0.x-Adresse durch das Wireguard-Gateway geht. Wenn das der Fall ist, liegt das Problem evtl. bei der FritzBox. Evtl. kann das WG-Interface auf der FritzBox, nicht als VPN-gateway benutzt werden und auf den anderen Geräten im Subnetz der FritzBox, muss/soll auch WireGuard installiert werden/sein.
 
Komischerweise taucht in Wireshark die Wireguard-Schnittstelle überhaupt nicht auf (auch nicht, wenn ich Wireshark erst starte, wenn die Wireguard-Verbindung schon steht).
Und wenn ich einfach auf "alle" (in Wireshark vorhandenen) Schnittstellen höre, finde ich nirgends die ICMP-Pakete zu meinen 192.168.0-Adressen... :confused:

[EDIT:] ich habe es sowohl mit npcap als Treiber als auch mit WinPCAP und mit Win10PCAP versucht - überall das gleiche - die Wireguard-Schnittstelle ist nicht sichtbar...
 
Massa schrieb:
... - die Wireguard-Schnittstelle ist nicht sichtbar...
Zum Vergrößern anklicken....
Dann versuch mal im wireshark mit einem Filter für wireguard-Datenpakete:
Code: 
udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000

Evtl. auch statt Windows eine Linux-Live-CD/DVD oder USB-Stick mit Linux-Live-System (oder gleichwertig) benutzen.
 
Hi,

deine Konfigs müssen folgendermaßen aussehen, dann klappt es:

FB:

Code: 
[Interface]
# privater Server-Key:
PrivateKey = <generierter FB-Server-Private-Key>
# Anmerkung: Adresse ist auf der Hauptseite eingetragen...
Address = 192.168.130.20/24
ListenPort = 42678

[Peer]
# öffentlicher Client-Key:
PublicKey = <mit dem wireguard-Windows-Client generierter Public-Key>
AllowedIPs = 192.168.130.21/32
# in Sekunden:
PersistentKeepalive = 21

Windows:

Code: 
[Interface]
PrivateKey = <wireguard Windows-Client-Private-Key>
Address = 192.168.130.21/24
DNS = 192.168.130.20, meinedomain.internal

[Peer]
PublicKey = <vom FB-Server aus dem privaten Schlüssel generierter Public-Key>
AllowedIPs = 192.168.130.0/24, 192.168.0.0/24
Endpoint = mydyndns.name:42678
PersistentKeepalive = 21

Oder wenn du sämlichen Verkehr über das VPN routen möchtest, dann in der Windows-Konfig "AllowedIPs = 0.0.0.0/0" eintragen.
 
Zuletzt bearbeitet:
@Whoopie: Danke für Deinen Hilfeversuch.
Meine aktuelle Konfiguration sah' schon (fast) so aus, wie von Dir beschrieben:

Freetz (Wireguard-Server):
INI: 
[Interface]
# privater Server-Key:
PrivateKey = <my-server-key>
# in der "Einstellungen"-Seite so konfiguriert:
#Address    = 192.168.130.20/24
ListenPort = 42678
:)
[Peer]
# öffentlicher Client-Key:
PublicKey  = <public-winclient-key>
AllowedIPs = 192.168.130.21/32
PersistentKeepalive = 21

Windows (Wireguard-Client):
INI: 
[Interface]
PrivateKey = <my-winclient-priv-key>
ListenPort = 51820
Address = 192.168.130.21/24
DNS = 192.168.130.20, myinternal.domain

[Peer]
PublicKey = <public-server-key>
AllowedIPs = [B]192.168.130.20/32[/B], 192.168.0.0/24
Endpoint = mydyndnsname:42678
PersistentKeepalive = 21

Ich habe nur die Netzmaske vom Server (Peer) auf dem Windows-Client als Einzeladresse definiert - aber auch, wenn ich wie von Dir beschrieben, dort ein Subnetz erlaube, ändert sich im Verhalten nichts:
Wenn ich damit den Tunnel aufbaue, kann ich (ohne weitere Routen auf dem Windows-Client setzen zu müssen) sowohl 192.168.130.20 (Wireguard-Server IP) als auch 192.168.0.10 (die LAN-Adresse der Fritzbox) anpingen. Das ist schonmal gut! :)
Aber leider war's das auch schon - versuche ich, andere Adressen (192.168.0.x) aus meinem internen Heimnetz anzupingen, kommt immer noch Timeout..

Nachdem die Verbindung steht, sind folgende Routing-Einträge auf dem Windows-Client automatisch durch Wireguard hinzugefügt worden:
Code: 
Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
192.168.0.0    255.255.255.0   Auf Verbindung    192.168.130.21      5
192.168.0.255  255.255.255.255   Auf Verbindung    192.168.130.21    261
192.168.130.0    255.255.255.0   Auf Verbindung    192.168.130.21    261
192.168.130.20  255.255.255.255   Auf Verbindung    192.168.130.21      5
192.168.130.21  255.255.255.255   Auf Verbindung    192.168.130.21    261
192.168.130.255  255.255.255.255   Auf Verbindung    192.168.130.21    261

Auf der Fritzbox sieht der relevante Teil der Routing-Tabelle so aus:
Code: 
192.168.0.0/24 dev lan scope link  src 192.168.0.10
192.168.130.0/24 dev wg0 scope link  src 192.168.130.20
192.168.130.21 dev wg0 scope link

Nachdem ich jetzt ja auch zu 192.168.0.10 komme, denke ich immer noch, dass auf dem Windows-Client alles O.K. ist, aber auf der FritzBox selber noch was fehlt, damit die Pakete vom wg0 weitergeleitet werden - oder die Rückantworten zurückgeleitet werden...

sf3978 schrieb:
Code: 
udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000
Zum Vergrößern anklicken....
Da kommt übrigens in Wireshark ein Fehler, dass die Syntax falsch ist... (0x100000 is no valid byte sequence) - aber selbst wenn ich die Wireguard-Pakete "zu fassen bekomme", sehe ich nur, dass scheinbar alles O.K. ist (soweit ich das beurteilen kann)

sf3978 schrieb:
Evtl. auch statt Windows eine Linux-Live-CD/DVD oder USB-Stick mit Linux-Live-System (oder gleichwertig) benutzen
Zum Vergrößern anklicken....
Du meinst, dort mal den Wireguard-Client einrichten?
 
Ich nutze bei Wireguard ein 10.0.0.0/24 Netz und damit klappt es einwandfrei. Ich hatte damals Wireguard in Freetz eingebaut, daher weiss ich, dass es eigentlich gehen muss, falls sich in den letzten Monaten nicht ein Fehler eingeschlichen hat (aber ich habe in den Sourcen auf die Schnelle nichts gefunden).

Probier doch auch mal ein 10er Netz, vielleicht klappt's ja.

Die anderen Geräte mit 192.168.0.x IP-Adressen nutzen die FB auch als Gateway, ja?
Oder ist das ggf. ein Windows-Firewall-Thema, dass die Geräte nicht auf Pings außerhalb des LAN-IP-Bereichs antworten? Schonmal die Firewall kurzzeitig deaktiviert?
 
Massa schrieb:
Da kommt übrigens in Wireshark ein Fehler, dass die Syntax falsch ist... (0x100000 is no valid byte sequence) - ...
Zum Vergrößern anklicken....

Hmm, bei mit geht dieser Filter, mit tcpdump ohne Probleme:
Code: 
:~# tcpdump -vvveni eth0 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:13:01.693188 ##:##:##:17:62:b4 > ##:##:##:62:3c:ae, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 58140, offset 0, flags [none], proto UDP (17), length 60)
    192.168.178.22.55521 > 192.168.178.13.*****: [udp sum ok] UDP, length 32
09:13:35.741039 ##:##:##:17:62:b4 > ##:##:##:62:3c:ae, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 59961, offset 0, flags [none], proto UDP (17), length 60)
    192.168.178.22.55521 > 192.168.178.13.*****: [udp sum ok] UDP, length 32
09:13:35.745731 ##:##:##:17:62:b4 > ##:##:##:62:3c:ae, ethertype IPv4 (0x0800), length 190: (tos 0x0, ttl 64, id 59962, offset 0, flags [none], proto UDP (17), length 176)
    192.168.178.22.55521 > 192.168.178.13.*****: [udp sum ok] UDP, length 148
Massa schrieb:
Du meinst, dort mal den Wireguard-Client einrichten?
Zum Vergrößern anklicken....
Ja.

EDIT:

Massa schrieb:
Wenn ich damit den Tunnel aufbaue, kann ich (ohne weitere Routen auf dem Windows-Client setzen zu müssen) sowohl 192.168.130.20 (Wireguard-Server IP) als auch 192.168.0.10 (die LAN-Adresse der Fritzbox) anpingen.
Zum Vergrößern anklicken....

BTW: Wenn Du tcpdump auf deiner FritzBox hast, dann schau mal nach, ob ein Ping via WG-Tunnel an ein Gerät im (W)LAN der FritzBox, das LAN-Interface der FritzBox erreicht/passiert.
 
Zuletzt bearbeitet:
@sf3978: ich arbeite nur selten mit Wireshark da scheint es eine andere Syntax zu geben:
Wireshark_Filter.jpg

@Whoopie: ich habe das ganze jetzt mit einem 10'er Subnetz neu konfiguriert - und tatsächlich, damit funktioniert es nun o_O
Ich verstehe zwar nicht warum - aber wenn's so ist, ist's halt so.

Also hier jetzt zu Dokuzwecken meine funktionierende Konfigurationen:

FritzBox Wireguard-Server:
INI: 
[Interface]
PrivateKey = <privater FritzBox Wireguard-Server-Key>
# ist auf der "Einstellungen"-Seite so eingestellt:
#Address    = 10.168.0.10/24
ListenPort = 42678

[Peer]
PublicKey  = <öffentlicher Windows Wireguard-Client-Key>
# die eine Adresse des Clients:
AllowedIPs = 10.168.0.11/32

Windows Wireguard-Client:
INI: 
[Interface]
PrivateKey = <privater Windows Wireguard-Client-Key>
ListenPort = 51820
Address = 10.168.0.11/24
DNS = 10.168.0.10, meineheimnetz.domain

[Peer]
PublicKey = <öffentlicher Fritzbox Wireguard-Server-Key>
# das Subnetz für die Wireguard-Verbindung und alle internen Netze, auf die man zugreifen möchte:
AllowedIPs = 10.168.0.0/24, 192.168.0.0/24
# die öffentlich erreichbare Internet-Adresse + Port des Wireguard-Servers:
Endpoint = meindyndnsname:42678
# damit die Verbindung auch ohne Datenverkehr offen bleibt (in Sekunden):
PersistentKeepalive = 21

Nach Aufbau der Verbindung, habe ich auf dem Windows-Rechner sowohl eine Verbindung ins Heimnetz als auch ins Netz, mit dem der Rechner ins Internet kommt - genau so, wie ich es wollte! :cool:
Folgende Routeneinträge hat Wireguard auf dem Windows-System hinzugefügt:
Code: 
Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
10.168.0.0    255.255.255.0   Auf Verbindung      10.168.0.11      5
10.168.0.11  255.255.255.255   Auf Verbindung      10.168.0.11    261
10.168.0.255  255.255.255.255   Auf Verbindung      10.168.0.11    261
192.168.0.0    255.255.255.0   Auf Verbindung      10.168.0.11      5
192.168.0.255  255.255.255.255   Auf Verbindung      10.168.0.11    261
 
Zuletzt bearbeitet:
Massa schrieb:
@sf3978: ich arbeite nur selten mit Wireshark da scheint es eine andere Syntax zu geben:
Zum Vergrößern anklicken....
Eigentlich nicht, denn das ist ja der ws-Filter (denn ich mit tcpdump nutze):
Capture Filter
To filter WireGuard traffic while capturing, you can use:
  • udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000
This filter works like the WireGuard heuristics, it test the first byte for a valid message type (1, 2, 3, or 4), and checks that the next three reserved bytes are zero.

Alternatively if you know the UDP port number, you can filter it like this:
  • udp port 51820
Zum Vergrößern anklicken....
Siehe: https://wiki.wireshark.org/WireGuard

Massa schrieb:
ich habe das ganze jetzt mit einem 10'er Subnetz neu konfiguriert - und tatsächlich, damit funktioniert es nun o_O
Ich verstehe zwar nicht warum - aber wenn's so ist, ist's halt so.
Also hier jetzt zu Dokuzwecken meine funktionierende Konfigurationen:
Zum Vergrößern anklicken....
Das mit dem erforderlichen 10-er Subnetz, ist dann eine "Spezialität" der FritzBox.

INI: 
[Interface]
# damit die Verbindung auch ohne Datenverkehr offen bleibt (in Sekunden):
PersistentKeepalive = 21
BTW: "PersistentKeepalive" wird auf dem WG-Server nicht benötigt.
 
sf3978 schrieb:
Siehe: https://wiki.wireshark.org/WireGuard
Zum Vergrößern anklicken....
Die Seite kenne ich, über die bin ich auch schon gestolpert - und habe mich dann gewundert, dass der Filter im Windows-Wireshark nicht funktioniert...

sf3978 schrieb:
Das mit dem erforderlichen 10-er Subnetz, ist dann eine "Spezialität" der FritzBox.
Zum Vergrößern anklicken....
Keine Ahnung ob das an Freetz liegt oder bei mir an meiner Netzwerkstruktur oder an was auch immer...
...Hauptsache, es funktioniert jetzt ;)

sf3978 schrieb:
INI: 
[Interface]PersistentKeepalive = 21
BTW: "PersistentKeepalive" wird auf dem WG-Server nicht benötigt.
Zum Vergrößern anklicken....
Danke, hab's mal entfernt!

[EDIT:] ich habe jetzt mal einen zusätzlichen Client (Peer) für mein Smartphone eingerichtet - das hat mit dem Wireguard Android-Client (und übertragen der Konfiguration) auf Anhieb funktioniert :cool:
 
Freut mich, dass es nun klappt. Vielleicht mag die FritzBox kein weiteres Netz im 192.168.x.x-Bereich. Da ich für meine VPNs immer einen 10er IP-Bereich nehme, ist mir das noch nie aufgefallen.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 294 (Mitglieder: 25, Gäste: 269)

Neueste Beiträge

Statistik des Forums

Themen
246,336
Beiträge
2,250,400
Mitglieder
373,987
Neuestes Mitglied
Julian1987
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück