aus der doku: NAT and Firewall Traversal Persistence By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT.
Schicke doch Mal Traffic auf die Verbindung, ich meine zu erinnern, dass die Verbindung erst aufgebaut wird, wenn auch ein Paket rüber will. Weiter ändere das /32 des getunnelten Verkehrs auf /24 und prüfe dann Mal die jeweiligen Routing Tabellen. Evtl wird mit dem Netz eine andere Route bevorzugt anstatt sie in den Tunnel zu senden (niedrigere metric).
Bei pfsense gibts bei ipsec tunneln auch n automatic ping host, der die tunnel immer offen hält, falls man das braucht. Ansonsten sind die auch zu, wenn kein traffic fliesst. gibt's sowas bei wireguard auch? Also könnte es das wirklich sein, was Andreas sagt.
Wireguard baut einen Verbindung auf sobalt Daten über den Tunnel gehen. Daher ist der erste Ping auch langsamer. Alternativ wird mit keepalive direkt eine Verbindung aufgebaut und aufrecht gehalten.
"WireGuard" baut den VPN-Tunnel erst auf, wenn Traffic erzeugt wird, der über den WireGuard-Tunnel zu routen ist. Vorher findet kein Handshake statt, der Tunnel wird dann also nicht aufgebaut. Wenn man zum Beispiel die IP-Adresse der WireGuard-Schnittstelle der Gegenseite anpingt, dann sollte der WireGuard-Tunnel aufgebaut (Handshake) und der Traffic über den Tunnel übertragen werden. Wenn deine WireGuard-Configs fehlerhaft wären, dann wäre beim Parsen der Config-Dateien bereits Fehler aufgetreten und deshalb gar keine WireGuard-Schnittstellen erzeugt worden. Bei einer fehlerhaften Config wird also bereits beim Ausführen des Befehls" wg-quick wg0 up" (für die 1. WireGuard-Schnittstelle) ein Fehler ausgespuckt.
Der Witz an wg ist noch, dass es ein Connection-less Protokoll ist. Die Tunnel UDP Pakete werden angenommen und entschlüsselt + auf Allowed-IP geprüft. GGf. wird die Endpoint IP von der das Paket kam dann gemerkt, wenn kein fixer Endpoint gesetzt ist.
Hast du mal versucht ein älteres Release von Wireguard zu verwenden? Falls das Problem bleibt, könntest du bspw. eine andere Linux-Distribution in Verbindung mit versch. Wireguard-Releases testen. So könntest du wenigstens herausfinden, ob es an der Linux-Distri oder an der Wireguard Version liegt.
Was sagt den das log? dmesg -wT | grep wireguard Ehrlich gesagt hatte ich aber die Tage ähnliche Probleme hab es nur auf mein unvermögen geschoben beides Debian 11 (eventuell lag es gar nicht an mir?) Lieber Dennis ich konnte soeben den Problem nachstellen wenn ich auf einer Debian 11 Maschine via wg show nachgucke ist alles top der Port wird aber nicht geöffnet! lsof -i :51820 liefert mir nix zurück
Ich frage mal doof, ich schau öfters deine stream auch live. Aber warum steht in der wireguard config auf der Server Seite eine Netz id und keine IP wie auf dem Client?
Interessanterweise scheint Debian11 nicht nur hier Probleme zu machen: Wir setzen Kubernetes-RKE von Rancher ein… eine Woche auf Debian11 versucht…, Ubuntu20 / Debian10 kein Problem. Ja, irgendwas mit nftables iptables-Legacy. Hatte dann auch keinen Bock mehr zu suchen…., frohes Fest, Grüße aus Köln!
Hi, erstmal vielen Dank für die coolen Videos. Gibt es eine Möglichkeit vaultwarden abzusichern? Soweit ich das verstehe, habe ich ja mit einem selbstgehosteten vaultwarden server die "Gefahr", dass jeder der die Adresse kennt sich auch einen account machen könnte!? Oder ist das falsch?
@@RaspberryPiCloud das war auch die Idee, aber ich finde es nicht. Weder auf docker hub, noch auf bitwarden, noch in den Einstellungen!? Sry, aber hast du nen Tipp?
hallo zusammen, gab es dazu jetzt eine Lösung? ich habe heute versucht mit einen WG Container zustellen bekomme abe rdie Verbindung auch nicht zustande. die WG App sagt das ich VPSN habe, aber ich kann keine Seite laden oder anderen Datenverkehr über Wg bekommen
Warum wird eigentlich auf vielen Webseiten behauptet wie einfach wireguard sei? Wenn ich mir anschau was ich HÄNDISCH alles manuell einrichten muss um un Debian wireguard einzurichten, kann ich nur noch mit dem Kopf schütteln.
Kommt die Lösung auch in einem video und nicht nur im Live-Stream? Kann nämlich leider morgen nicht am Livestream teilnehmen bin auf dem Festland "arbeiten"
Mir kommt das gerade irgendwie bekannt vor. Allerdings war ich nicht so schlau nen TCPdump anzuwerfen. Debian WG Server auf ESXi free 6.7 und Android + Win 10 Clients. Es hat nach der Einrichtung einmal funktioniert und dann nie wieder. Nachdem ich mir damit ein Wochenende versaut hatte, hab ich mein OpenVPN wieder hoch gefahren. Das wollte ich eigentlich bezüglich der besseren Performance durch WG ersetzen.
gleiche problem hier, allerdings mit ubuntu 20.04er image für nen LXC... kriege seit neuestem keine verbindung mehr hin, auch TCPdump zeigt nix mehr an.... beim kumpel exakt gleiche deployment... funktioniert
Moin ich hatte das Problem glaaube ich auch und konnte es dadurch lösen, das ich in die Cofig des Cleints einnen DNS hinterlegt habe. Danach hat die Verbindung einwandfrei funktioniert.
Hab auch so ne lustige Sache mit WireGuard, alles läuft außer wenn ich mit VOIP intern oder extern raustelefonieren will, aber kann angerufen werden intern/extern. :D Mit OpenVPN klappt alles ohne Probleme. Hab das Gefühl irgendwie mag Wireguard VOIP im Nat nicht so.
Ich bin auf meinem pine64 auf dem kernel 5.10.60-sunxi64 aber bei mir läuft das sowieso ohne Kernel-Unterstützung das hat noch nie funktioniert auf dem pine64. Aber es läuft zumindest
Im Zweifel mal eine neue VM mit aktueller Debian-ISO installieren, wenn du immer von "Templates" sprichst, die du dir selber zusammen geschusterst hast.
@@RaspberryPiCloud Hm, vielleicht mal den tcp dump auf das Wireguard inter face statt ens18 probieren. Ansonsten ist es wohl ein routing und/oder NATting Problem.
@@r2ixRUclips gehört Google und Linux auf Chromebook läuft nur im hauseigenen Container unter ChromeOS welches Kernel 5.15.x anzeigt aber unter /lib/modules/ 5.10.x aufweist. Ergo wird man gezwungen nur unter ChromeOS über Wireguard zu verbinden. Bin ich der Einzige dem sich da gleich Verschwörungstheorien auftun, ganz dem Motto "verkauft günstige Chromebooks an alle Opfer, sodass sie nichts eigenständig gebacken bekommen und macht Kernel 5.10.x untauglich ?😅
ich glaube das die netzwerk intsllation auch putt ist. irgend was will nicht mehr oder hat noch nie richtig funktioniert. ich hab auch mal eine neue linux intallation gemach und mein admin hate keine rechte ist der beste bug ever wenn man keine rchte auf dem system hat. wo nur neu instaliren oder tiefes eingraifen um sich die rechte wieder zu beschafen hilft. beide wege sind etwa gleich lang. neu instalieren ist meiner meinung immer der bessere weg. weil man nicht weis was noch kaputt gegangen ist und linux mit falschen rechten ist da ein grüpel system. wei immer nur die helfte das macht was es so und die andere helfe streikt und sagt nein ich will nicht mehr.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
aus der doku:
NAT and Firewall Traversal Persistence
By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT.
Schicke doch Mal Traffic auf die Verbindung, ich meine zu erinnern, dass die Verbindung erst aufgebaut wird, wenn auch ein Paket rüber will. Weiter ändere das /32 des getunnelten Verkehrs auf /24 und prüfe dann Mal die jeweiligen Routing Tabellen. Evtl wird mit dem Netz eine andere Route bevorzugt anstatt sie in den Tunnel zu senden (niedrigere metric).
Bei pfsense gibts bei ipsec tunneln auch n automatic ping host, der die tunnel immer offen hält, falls man das braucht. Ansonsten sind die auch zu, wenn kein traffic fliesst. gibt's sowas bei wireguard auch? Also könnte es das wirklich sein, was Andreas sagt.
Exakt - wenn man will, dass der Tunnel periodisch Daten sendet (z.B. um NAT am Leben zu halten) kann man PersistentKeepalive nutzen..
Wireguard baut einen Verbindung auf sobalt Daten über den Tunnel gehen. Daher ist der erste Ping auch langsamer. Alternativ wird mit keepalive direkt eine Verbindung aufgebaut und aufrecht gehalten.
Stimmt er hatte kein keepalive drin! Daran habe ich gar nicht gedacht. Aber baut er nicht Trotzdem eine erste Verbindung auf?
@@m-electronics5977 Nein macht er erst wenn du Daten sendest. Einfach einen Ping sende zum testen.
Cooles Video, bin sehr auf die Lösung gespannt 😄
5:57 epic simulation
"WireGuard" baut den VPN-Tunnel erst auf, wenn Traffic erzeugt wird, der über den WireGuard-Tunnel zu routen ist. Vorher findet kein Handshake statt, der Tunnel wird dann also nicht aufgebaut. Wenn man zum Beispiel die IP-Adresse der WireGuard-Schnittstelle der Gegenseite anpingt, dann sollte der WireGuard-Tunnel aufgebaut (Handshake) und der Traffic über den Tunnel übertragen werden.
Wenn deine WireGuard-Configs fehlerhaft wären, dann wäre beim Parsen der Config-Dateien bereits Fehler aufgetreten und deshalb gar keine WireGuard-Schnittstellen erzeugt worden. Bei einer fehlerhaften Config wird also bereits beim Ausführen des Befehls" wg-quick wg0 up" (für die 1. WireGuard-Schnittstelle) ein Fehler ausgespuckt.
Der Witz an wg ist noch, dass es ein Connection-less Protokoll ist. Die Tunnel UDP Pakete werden angenommen und entschlüsselt + auf Allowed-IP geprüft. GGf. wird die Endpoint IP von der das Paket kam dann gemerkt, wenn kein fixer Endpoint gesetzt ist.
Hast du mal versucht ein älteres Release von Wireguard zu verwenden?
Falls das Problem bleibt, könntest du bspw. eine andere Linux-Distribution in Verbindung mit versch. Wireguard-Releases testen. So könntest du wenigstens herausfinden, ob es an der Linux-Distri oder an der Wireguard Version liegt.
Was sagt den das log? dmesg -wT | grep wireguard Ehrlich gesagt hatte ich aber die Tage ähnliche Probleme hab es nur auf mein unvermögen geschoben beides Debian 11 (eventuell lag es gar nicht an mir?) Lieber Dennis ich konnte soeben den Problem nachstellen wenn ich auf einer Debian 11 Maschine via wg show nachgucke ist alles top der Port wird aber nicht geöffnet! lsof -i :51820 liefert mir nix zurück
Ich frage mal doof, ich schau öfters deine stream auch live. Aber warum steht in der wireguard config auf der Server Seite eine Netz id und keine IP wie auf dem Client?
Was ist den mit dem Haken Firewall bei Proxmox auf den Container? Ist der vielleicht an?
Firewall ist aus. Und ist kein Container.
Interessanterweise scheint Debian11 nicht nur hier Probleme zu machen: Wir setzen Kubernetes-RKE von Rancher ein… eine Woche auf Debian11 versucht…, Ubuntu20 / Debian10 kein Problem. Ja, irgendwas mit nftables iptables-Legacy. Hatte dann auch keinen Bock mehr zu suchen…., frohes Fest, Grüße aus Köln!
Hi, erstmal vielen Dank für die coolen Videos. Gibt es eine Möglichkeit vaultwarden abzusichern? Soweit ich das verstehe, habe ich ja mit einem selbstgehosteten vaultwarden server die "Gefahr", dass jeder der die Adresse kennt sich auch einen account machen könnte!? Oder ist das falsch?
Du kannst doch auch die Registrierung abschalten. Dann kann da keiner einen Account erstellen.
@@RaspberryPiCloud das war auch die Idee, aber ich finde es nicht. Weder auf docker hub, noch auf bitwarden, noch in den Einstellungen!? Sry, aber hast du nen Tipp?
@@RaspberryPiCloud OK, durch den Hinweis habe ich es dann doch gefunden! Dankeschön!!!!
hallo zusammen, gab es dazu jetzt eine Lösung? ich habe heute versucht mit einen WG Container zustellen bekomme abe rdie Verbindung auch nicht zustande. die WG App sagt das ich VPSN habe, aber ich kann keine Seite laden oder anderen Datenverkehr über Wg bekommen
Warum wird eigentlich auf vielen Webseiten behauptet wie einfach wireguard sei? Wenn ich mir anschau was ich HÄNDISCH alles manuell einrichten muss um un Debian wireguard einzurichten, kann ich nur noch mit dem Kopf schütteln.
Kommt die Lösung auch in einem video und nicht nur im Live-Stream? Kann nämlich leider morgen nicht am Livestream teilnehmen bin auf dem Festland "arbeiten"
Sind das Container aufm Proxmox Host? Dann müssen noch Einstellungen auf dem Host geändert werden.
Sind 2 vollwertige VMs. (qemu KVM)
Mir kommt das gerade irgendwie bekannt vor. Allerdings war ich nicht so schlau nen TCPdump anzuwerfen.
Debian WG Server auf ESXi free 6.7 und Android + Win 10 Clients. Es hat nach der Einrichtung einmal funktioniert und dann nie wieder. Nachdem ich mir damit ein Wochenende versaut hatte, hab ich mein OpenVPN wieder hoch gefahren. Das wollte ich eigentlich bezüglich der besseren Performance durch WG ersetzen.
Du kannst in wireguard die logs einschalten, dann bekommst du mehr Details die dir helfen könnten
gleiche problem hier, allerdings mit ubuntu 20.04er image für nen LXC... kriege seit neuestem keine verbindung mehr hin, auch TCPdump zeigt nix mehr an.... beim kumpel exakt gleiche deployment... funktioniert
Ich würde mal die 1:1 gleiche CONFIG auf einer älteren DEBIAN Version testen wenn es dort geht und mit der neuen nicht dann ist es ein BUG.
Wireguard dauert keine 5min und läuft. Man sieht also, das man nicht alles so einfach hinbekommt - auch wenn man meint, das wäre so ;)
Warum sind jetzt die docker-training Videos wieder offline??!!!!
Die waren noch garnicht öffentlich
@@RaspberryPiCloud Doch waren sie. Habe ja angefangen sie zu kucken
Warum können sie nicht jetzt schon online kommen? Fand den Anfang sehr interessant. Kommt die Lösung zum Wireguard problem heute im Livestream?
Ich weiß immer noch nicht wie du nicht im Video schon selber anfangen kannst zu lachen weil du eigentlich selber weißt
Moin ich hatte das Problem glaaube ich auch und konnte es dadurch lösen, das ich in die Cofig des Cleints einnen DNS hinterlegt habe. Danach hat die Verbindung einwandfrei funktioniert.
Hab auch so ne lustige Sache mit WireGuard, alles läuft außer wenn ich mit VOIP intern oder extern raustelefonieren will, aber kann angerufen werden intern/extern. :D
Mit OpenVPN klappt alles ohne Probleme. Hab das Gefühl irgendwie mag Wireguard VOIP im Nat nicht so.
Hm, meine Kommentare verschwinden immer, ggf. wegen "gefährlicher" Konfigurationsdaten. Hast Du das tun-Device in den Container-Konfigurationen drin?
Ich bin auf meinem pine64 auf dem kernel 5.10.60-sunxi64 aber bei mir läuft das sowieso ohne Kernel-Unterstützung das hat noch nie funktioniert auf dem pine64. Aber es läuft zumindest
Morgen ist Livestream!!!
vielleicht mal ein Ping von einer VM zur anderen ? Super Content übrigens 😎
Ja, ICMP klappt wunderbar.
Das ist die Regierung 🤣 die will doch keine Verschlüsslung mehr
WireGuard loggt nichts. Das musst du erst aktivieren.
Mit einer VM geht es. Mit einer CT nicht ....
Ist eine VM ;)
Auch in unpriviligierten Containern kannst du WireGuard nutzen ;)
Sofern die Module mit modrobe auf dem Host geladen wurden
@@LampJustin Richtig das geht problemlos.
Setz in der Sender-Konfig mal die MTU auf 1387
Im Zweifel mal eine neue VM mit aktueller Debian-ISO installieren, wenn du immer von "Templates" sprichst, die du dir selber zusammen geschusterst hast.
Ja es sind Templates, allerdings Blanko templates.
Schalte mal die IP Weiterleitung im Kernel an. Würde ja mehr schreiben, aber scheinbar werden meine Kommentare immer sofort gelöscht..
sys... ip forward habe ich bereits...
@@RaspberryPiCloud Hm, vielleicht mal den tcp dump auf das Wireguard inter face statt ens18 probieren. Ansonsten ist es wohl ein routing und/oder NATting Problem.
@@RaspberryPiCloud Alter Schwede, egal was ich antworte, RUclips löscht es instant. Keinen Bock mehr. Viel Glück dabei :D
@@r2ixRUclips gehört Google und Linux auf Chromebook läuft nur im hauseigenen Container unter ChromeOS welches Kernel 5.15.x anzeigt aber unter /lib/modules/ 5.10.x aufweist. Ergo wird man gezwungen nur unter ChromeOS über Wireguard zu verbinden. Bin ich der Einzige dem sich da gleich Verschwörungstheorien auftun, ganz dem Motto "verkauft günstige Chromebooks an alle Opfer, sodass sie nichts eigenständig gebacken bekommen und macht Kernel 5.10.x untauglich ?😅
Welcome to my world :-(
Also ich meine bei mir läuft es mit 5.10.x
ich glaube das die netzwerk intsllation auch putt ist. irgend was will nicht mehr oder hat noch nie richtig funktioniert. ich hab auch mal eine neue linux intallation gemach und mein admin hate keine rechte ist der beste bug ever wenn man keine rchte auf dem system hat. wo nur neu instaliren oder tiefes eingraifen um sich die rechte wieder zu beschafen hilft. beide wege sind etwa gleich lang. neu instalieren ist meiner meinung immer der bessere weg. weil man nicht weis was noch kaputt gegangen ist und linux mit falschen rechten ist da ein grüpel system. wei immer nur die helfte das macht was es so und die andere helfe streikt und sagt nein ich will nicht mehr.