entfernt
Nov 11, 2023
view1998
view21
0
Goto Top

Wireguard Server (vServer) mit Windows Client

GermansolvedQuestionVPN
Hallo zusammen,

ich habe einen Wireguard Server nach dieser Anleitung aufgesetzt:
https://www.digitalocean.com/community/tutorials/how-to-set-up-wireguard ...

Allerdings beschreibt dies einen Wireguard Server UND einen Client auf Ubuntu.
Daher bin ich nicht sicher ob ich das mit den Keys richtig gemacht habe.

Nachdem man auf dem Server einen private und einen public key erstellt hat, soll man irgendwann später auch noch mal auf der Gegenseite (Client) einen private und public Key erstellen.

Da ich keinen Ubuntu Client habe sondern später per Wireguard Installation auf einem Windows Client zugreifen will, habe ich die zweiten Schlüsselpaare auch einfach auf dem Server erstellt.

Wenn der Windows Client den Tunnel aufgebaut hat (Aktiv ist) steht im log aber Handshake not complete und wenn ich meine Öffentliche IP auf dem Laptop checke, ist dies immer noch die meines Heimnetzwerks und nicht die des vServers...

Hier mal meine config:

Wg0.conf:
[Interface]
Address = 10.8.0.1/24
Address = fdfa:653f:ecde::/64
SaveConfig = true
PostUp = ufw route allow in on wg0 out on ens6
PostUp = iptables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on ens6
PreDown = iptables -t nat -D POSTROUTING -o ens6 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o ens6 -j MASQUERADE
ListenPort = 51820
PrivateKey = UPg+weaJdmKvW8b-------------/R7nXZFvbXVGQ=

[Peer]
PublicKey = Y0OSmWs0n4YE-------Tuw2XUBK2zyg=

client.conf für den Wireguard Client:

[Interface]
PrivateKey = UPg+weaJdmKvW8b------------/R7nXZFvbXVGQ=
Address = 10.8.0.2/24
Address = fdfa:653f:ecde::2/64
DNS = 212.227.xxx.xx 212.xxx.123.xx 2001:xxx:fe:xx:72ec::1 2001:xxx:fe:xx:72ec::2

[Peer]
PublicKey = Y0OSmWs0n4YE0E------------Tuw2XUBK2zyg=
AllowedIPs = 10.8.0.0/24, fdfa:653f:ecde::/64
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 15

root@ubuntu:~# wg
interface: wg0
  public key: jiDTd5pAECB5------------2Tymf6uQU=
  private key: (hidden)
  listening port: 51820

peer: Y0OSmWs0n4Y--------------Tuw2XUBK2zyg=
  allowed ips: (none)

root@ubuntu:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Sat 2023-11-11 01:55:06 UTC; 9h ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
   Main PID: 1455 (code=exited, status=0/SUCCESS)
        CPU: 88ms

Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] wg setconf wg0 /dev/fd/63
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip -6 address add fdfa:653f:ecde::/64 dev wg0
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip link set mtu 1420 up dev wg0
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ufw route allow in on wg0 out on ens6
Nov 11 01:55:06 ubuntu wg-quick[1489]: Rule added
Nov 11 01:55:06 ubuntu wg-quick[1489]: Rule added (v6)
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] iptables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
Nov 11 01:55:06 ubuntu wg-quick[1455]: [#] ip6tables -t nat -I POSTROUTING -o ens6 -j MASQUERADE
Nov 11 01:55:06 ubuntu systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

root@ubuntu:~# ufw status
Status: active

To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere
OpenSSH                    ALLOW       Anywhere
51820/udp (v6)             ALLOW       Anywhere (v6)
OpenSSH (v6)               ALLOW       Anywhere (v6)

Anywhere on ens6           ALLOW FWD   Anywhere on wg0
Anywhere (v6) on ens6      ALLOW FWD   Anywhere (v6) on wg0

root@ubuntu:~# ip route list default
default via 157.x.x.1 dev ens6 proto dhcp src 157.x.x.171 metric 100
Wobei ich hier nicht verstehe weshalb die erste öffentliche IP in der Ausgabe nur eine 1 hinten hat und die zweite die 171 (wie es auch eigentlich richtig ist)

root@ubuntu:~# sysctl -p
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Wireguard Client Log:

2023-11-11 12:25:41.577932: [MGR] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 12:25:41.586190: [MGR] Starting UI process for user ‘USER’ for session 7
2023-11-11 12:45:15.410757: [TUN] [client] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 12:45:15.411635: [TUN] [client] Watching network interfaces
2023-11-11 12:45:15.415485: [TUN] [client] Resolving DNS names
2023-11-11 12:45:15.415485: [TUN] [client] Creating network adapter
2023-11-11 12:45:15.600172: [TUN] [client] Installing driver 0.10
2023-11-11 12:45:15.604030: [TUN] [client] Extracting driver
2023-11-11 12:45:15.607118: [TUN] [client] Installing driver
2023-11-11 12:45:16.172932: [TUN] [client] Creating adapter
2023-11-11 12:45:16.759359: [TUN] [client] Using WireGuardNT/0.10
2023-11-11 12:45:16.759900: [TUN] [client] Enabling firewall rules
2023-11-11 12:45:16.655150: [TUN] [client] Interface created
2023-11-11 12:45:16.768020: [TUN] [client] Dropping privileges
2023-11-11 12:45:16.769304: [TUN] [client] Setting interface configuration
2023-11-11 12:45:16.769814: [TUN] [client] Peer 1 created
2023-11-11 12:45:16.771916: [TUN] [client] Sending keepalive packet to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:16.773785: [TUN] [client] Monitoring MTU of default v6 routes
2023-11-11 12:45:16.771916: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:16.771916: [TUN] [client] Interface up
2023-11-11 12:45:16.786549: [TUN] [client] Setting device v6 addresses
2023-11-11 12:45:16.871987: [TUN] [client] Monitoring MTU of default v4 routes
2023-11-11 12:45:16.873294: [TUN] [client] Setting device v4 addresses
2023-11-11 12:45:16.898521: [TUN] [client] Startup complete
2023-11-11 12:45:21.824826: [TUN] [client] Handshake for peer 1 (157.x.x.171:51820) did not complete after 5 seconds, retrying (try 2)
2023-11-11 12:45:21.824826: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:26.899884: [TUN] [client] Handshake for peer 1 (157.x.x.171:51820) did not complete after 5 seconds, retrying (try 3)
2023-11-11 12:45:26.900137: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)
2023-11-11 12:45:31.978708: [TUN] [client] Handshake for peer 1 (157.x.x.171:51820) did not complete after 5 seconds, retrying (try 4)
2023-11-11 12:45:31.978708: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.171:51820)



Was mache ich falsch oder was habe ich vergessen ??

VG
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 61941997910

Url: https://administrator.de/contentid/61941997910

Printed on: May 1, 2024 at 19:05 o'clock

21 Comments
Latest comment
Goto Top
Member: aqui
Solution aqui Nov 11, 2023 updated at 17:12:12 (UTC)
Goto Top
Allerdings beschreibt dies einen Wireguard Server
Wie immer die üblichen Kardinalsfehler: face-sad
  • Überflüssiges und kontraproduktives NAT (Address Translation im Tunnel)
  • Falsche Subnetzmasken beim Cryptokey Routing (Allowed IPs) insbesondere die Redirect Maske 0.0.0.0
Vielleicht solltest du als Alternative noch einmal das hiesige Wireguard Tutorial lesen damit du solche Anfänger Fehler vermeidest! 😉

Nebenbei:
Wenn du bequemer und stressfreier mit bordeigenen VPN Clients arbeiten möchtest ohne die umständliche Frickelei mit externen extra VPN Clients dann guckst du hier:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Member: entfernt
entfernt Nov 11, 2023 at 12:25:35 (UTC)
Goto Top
Hallo aqui,

guck ich mir gleich mal an.

Was anderes als wireguard kommt da gerade nicht in frage.
Benutze das hinterher auf dem FireTV Stick und dafür brauche ich wireguard

VG
Member: entfernt
entfernt Nov 11, 2023 at 14:27:01 (UTC)
Goto Top
ok also mit Deiner Anleitung sieht es schon mal besser aus aber auf wieistmeineip bekomme ich immer noch die "falsche Adresse"

Meine neue config:

wg0.conf:
[Interface]
Address = 100.64.64.1/24
PrivateKey = WPobDkq7+IEqM--------------u4Xbm2Pg534=
ListenPort = 51820

[Peer]
PublicKey = lAiS+vClXAD--------------N31LD6mRJyiM6ly8=
AllowedIPs = 100.64.64.100/32, 0.0.0.0/24

client.conf:
[Interface]
PrivateKey = +OGBEeMVze---------------MAdTRtHgdpal0=
Address = 100.64.64.1/24

[Peer]
PublicKey = GtMk1AA3-----------------xcHr/qEzBY=
AllowedIPs = 100.64.64.100/32, 0.0.0.0/24
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 15

root@ubuntu:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor pre>
     Active: active (exited) since Sat 2023-11-11 14:02:44 UTC; 12min ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 558 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCC>
   Main PID: 558 (code=exited, status=0/SUCCESS)
        CPU: 24ms

Nov 11 14:02:43 ubuntu systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip link add wg0 type wireguard
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] wg setconf wg0 /dev/fd/63
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip -4 address add 100.64.64.1/24 dev >
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip link set mtu 1420 up dev wg0
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip -4 route add 0.0.0.0/24 dev wg0
Nov 11 14:02:44 ubuntu systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

root@ubuntu:~# wg show
interface: wg0
  public key: GtMk1AA3T-----------------xJWxcHr/qEzBY=
  private key: (hidden)
  listening port: 51820

peer: lAiS+vClXADSsOA--------------------LD6mRJyiM6ly8=
  endpoint: 87.x.x.x:59681
  allowed ips: 100.64.64.100/32, 0.0.0.0/24
  latest handshake: 5 minutes, 18 seconds ago
  transfer: 796 B received, 276 B sent

root@ubuntu:~# sysctl -p
net.ipv4.ip_forward = 1

wireguard log
2023-11-11 15:11:17.040204: [MGR] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:17.048988: [MGR] Starting UI process for user ‘USER’ for session 1
2023-11-11 15:11:25.828014: [TUN] [client] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:25.828014: [TUN] [client] Watching network interfaces
2023-11-11 15:11:25.830700: [TUN] [client] Resolving DNS names
2023-11-11 15:11:25.831254: [TUN] [client] Creating network adapter
2023-11-11 15:11:25.927675: [TUN] [client] Using existing driver 0.10
2023-11-11 15:11:25.936986: [TUN] [client] Creating adapter
2023-11-11 15:11:26.235951: [TUN] [client] Using WireGuardNT/0.10
2023-11-11 15:11:26.235951: [TUN] [client] Enabling firewall rules
2023-11-11 15:11:26.182525: [TUN] [client] Interface created
2023-11-11 15:11:26.242425: [TUN] [client] Dropping privileges
2023-11-11 15:11:26.242934: [TUN] [client] Setting interface configuration
2023-11-11 15:11:26.243629: [TUN] [client] Peer 1 created
2023-11-11 15:11:26.245212: [TUN] [client] Monitoring MTU of default v4 routes
2023-11-11 15:11:26.244681: [TUN] [client] Sending keepalive packet to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Interface up
2023-11-11 15:11:26.271515: [TUN] [client] Receiving handshake response from peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.271515: [TUN] [client] Keypair 1 created for peer 1
2023-11-11 15:11:26.271515: [TUN] [client] Setting device v4 addresses
2023-11-11 15:11:26.301183: [TUN] [client] Monitoring MTU of default v6 routes
2023-11-11 15:11:26.302199: [TUN] [client] Setting device v6 addresses
2023-11-11 15:11:26.323717: [TUN] [client] Startup complete



11-11-_2023_15-25-38

Was hab ich falsch gemacht?

VG
14-11-_2023_10-15-03
Member: Epixc0re
Epixc0re Nov 11, 2023 at 15:19:45 (UTC)
Goto Top
Hallo,

0.0.0.0/24 ist nicht das ganze Internet. Richtig wäre hier: 0.0.0.0/0

LG
heart1
Member: entfernt
entfernt Nov 11, 2023 updated at 18:15:09 (UTC)
Goto Top
Zitat von @Epixc0re:

Hallo,

0.0.0.0/24 ist nicht das ganze Internet. Richtig wäre hier: 0.0.0.0/0

LG

Hab ich geändert, jetzt erreiche ich den Server nicht mehr....

Also gar nicht mehr, öffentliche IP lässt sich nicht mehr anpingen, putty logischerweise auch nicht mehr...
Member: aqui
aqui Nov 11, 2023 at 20:41:31 (UTC)
Goto Top
...was dann auf ein falsches Routing am Tunnelendpunkt schliessen lässt. face-sad Pathping oder Traceroute sind, wie immer, deine besten Freunde.
Posten des aktuellen Client und Server Setups würde auch helfen.
Member: entfernt
entfernt Nov 11, 2023 at 22:16:07 (UTC)
Goto Top
Zitat von @aqui:

Posten des aktuellen Client und Server Setups würde auch helfen.

Hab ich doch:

Wireguard Server (vServer) mit Windows Client

Oder fehlt da noch was ?

Zitat von @aqui:

...was dann auf ein falsches Routing am Tunnelendpunkt schliessen lässt. face-sad Pathping oder Traceroute sind, wie immer, deine besten Freunde.
Naja da das ja ein vServer ist an den ich nur per putty komme werde ich den wohl neu installieren müssen, richtig ?

VG
Member: aqui
aqui Nov 11, 2023 updated at 22:25:23 (UTC)
Goto Top
Nöö, kann man ja alles auch mit PuTTY und SSH machen. ip r zeigt dir die Routing Tabelle.
Wenn du von da ins Internet willst musst du den WG Tunneltraffic dann natürlich masqueraden, denn RFC 1918 IPs wie dein internes 10.8er Netz sind bekanntlich nicht routebar im Internet.
Da wäre dann die Firewall Konfig hilfreich bzw. deine /etc/nftables.conf.
Hier ist dann ein ip saddr 10.8.0.0/24 oif eth0 masquerade in der Chain "postrouting" zwingend. Guckst du auch hier.
Member: entfernt
entfernt Nov 11, 2023 at 22:46:04 (UTC)
Goto Top
Zitat von @aqui:

Nöö, kann man ja alles auch mit PuTTY und SSH machen. ip r zeigt dir die Routing Tabelle.

Wie gesagt das ist das Problem, komme nicht mehr ran 😅

Hab das so geändert wie hier beschrieben:
Zitat von @Epixc0re:

Hallo,

0.0.0.0/24 ist nicht das ganze Internet. Richtig wäre hier: 0.0.0.0/0

LG

Jetzt kann man die öffentliche IP nicht mehr pingen und ich komme auch mit putty nicht mehr dran 🤷‍♂️
Egal, setze den neu auf und schaue mal ob ich dann mit den nftables weiter komme…
Member: Epixc0re
Epixc0re Nov 12, 2023 at 00:30:40 (UTC)
Goto Top
…

0.0.0.0/0 = an Client in die allowedIPs eintragen
Member: aqui
aqui Nov 12, 2023 updated at 10:47:34 (UTC)
Goto Top
das ist das Problem, komme nicht mehr ran
Oha, dann hast du aber erstmal ein ganz anderes Problem...! ☹️
Da hilft dann in der Tat nur alles auf Anfang.
Member: ASP.NET.Core
ASP.NET.Core Nov 12, 2023 at 14:42:04 (UTC)
Goto Top
Oder beim Hoster schauen. Vor allem an virtuelle Server kommt man oft auch direkt über eine Konsole im Web. Du brauchst halt einen Nutzer, der sich mit PW anmelden darf, also ohne SSH Schlüssel.
heart1
Member: entfernt
entfernt Nov 14, 2023 at 09:22:38 (UTC)
Goto Top
Zitat von @ASP.NET.Core:

Oder beim Hoster schauen. Vor allem an virtuelle Server kommt man oft auch direkt über eine Konsole im Web. Du brauchst halt einen Nutzer, der sich mit PW anmelden darf, also ohne SSH Schlüssel.

Stimmt, allerdings zu spät gesehen, da hatte ich schon neu installiert.

Ich bin jetzt quasi wieder an diesem Punkt hier bekomme aber jetzt bei aktiver Verbindung keine Internetverbindung mehr...
Meine neue config:

wg0.conf:
[Interface]
Address = 100.64.64.1/24
PrivateKey = QDpsUBDpk------------------SD19CgF2hkc=
ListenPort = 51820

[Peer]
PublicKey = x4LyrRAquJ---------------------lbRjh+DNfnqhU=
AllowedIPs = 100.64.64.100/32, 192.168.40.0/24, 192.168.178.0/24

client.conf:
[Interface]
PrivateKey = QOIuIQTtfaz53-----------------tdbdr1+H/QGU=
Address = 100.64.64.1/24

[Peer]
PublicKey = pCqtnC0AXLvrl---------------DRCPFpnerDcO0A=
AllowedIPs = 100.64.64.100/32, 192.168.40.0/24, 192.168.178.0/24
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 15

root@ubuntu:~# systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor pre>
     Active: active (exited) since Sat 2023-11-11 14:02:44 UTC; 12min ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 558 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCC>
   Main PID: 558 (code=exited, status=0/SUCCESS)
        CPU: 24ms

Nov 11 14:02:43 ubuntu systemd[1]: Starting WireGuard via wg-quick(8) for wg0...
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip link add wg0 type wireguard
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] wg setconf wg0 /dev/fd/63
Nov 11 14:02:43 ubuntu wg-quick[558]: [#] ip -4 address add 100.64.64.1/24 dev >
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip link set mtu 1420 up dev wg0
Nov 11 14:02:44 ubuntu wg-quick[558]: [#] ip -4 route add 0.0.0.0/24 dev wg0
Nov 11 14:02:44 ubuntu systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

root@ubuntu:~# wg show
interface: wg0
  public key: pCqtnC0A----------1oIKDRCPFpnerDcO0A=
  private key: (hidden)
  listening port: 51820

peer: x4LyrRAquJXjRB+---------j3lbRjh+DNfnqhU=
  endpoint: 79.x.x.x:64093
  allowed ips: 100.64.64.100/32, 192.168.40.0/24, 192.168.178.0/24
  latest handshake: 7 minutes, 5 seconds ago
  transfer: 360 B received, 408 B sent

root@ubuntu:~# sysctl -p
net.ipv4.ip_forward = 1

wireguard log
2023-11-11 15:11:17.040204: [MGR] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:17.048988: [MGR] Starting UI process for user ‘USER’ for session 1
2023-11-11 15:11:25.828014: [TUN] [client] Starting WireGuard/0.5.3 (Windows 10.0.22621; amd64)
2023-11-11 15:11:25.828014: [TUN] [client] Watching network interfaces
2023-11-11 15:11:25.830700: [TUN] [client] Resolving DNS names
2023-11-11 15:11:25.831254: [TUN] [client] Creating network adapter
2023-11-11 15:11:25.927675: [TUN] [client] Using existing driver 0.10
2023-11-11 15:11:25.936986: [TUN] [client] Creating adapter
2023-11-11 15:11:26.235951: [TUN] [client] Using WireGuardNT/0.10
2023-11-11 15:11:26.235951: [TUN] [client] Enabling firewall rules
2023-11-11 15:11:26.182525: [TUN] [client] Interface created
2023-11-11 15:11:26.242425: [TUN] [client] Dropping privileges
2023-11-11 15:11:26.242934: [TUN] [client] Setting interface configuration
2023-11-11 15:11:26.243629: [TUN] [client] Peer 1 created
2023-11-11 15:11:26.245212: [TUN] [client] Monitoring MTU of default v4 routes
2023-11-11 15:11:26.244681: [TUN] [client] Sending keepalive packet to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Sending handshake initiation to peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.244681: [TUN] [client] Interface up
2023-11-11 15:11:26.271515: [TUN] [client] Receiving handshake response from peer 1 (157.x.x.x:51820)
2023-11-11 15:11:26.271515: [TUN] [client] Keypair 1 created for peer 1
2023-11-11 15:11:26.271515: [TUN] [client] Setting device v4 addresses
2023-11-11 15:11:26.301183: [TUN] [client] Monitoring MTU of default v6 routes
2023-11-11 15:11:26.302199: [TUN] [client] Setting device v6 addresses
2023-11-11 15:11:26.323717: [TUN] [client] Startup complete

nftables
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority 0;
	}
	chain forward {
		type filter hook forward priority 0;
	}
	chain output {
		type filter hook output priority 0;
	}
}

table ip nat {

        define VPN_NETS = {
        192.168.178.0/24
        }
        # fuer VPN Client Pakete ins Internet masquerade ausser VPN Netzwerke
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname ens6 ip daddr $VPN_NETS accept
                ip saddr 100.64.64.0/24 oif ens6 masquerade
        }
}

root@ubuntu:~# ip r
default via 157.97.109.1 dev ens6 proto dhcp src 157.x.x.x metric 100
100.64.64.0/24 dev wg0 proto kernel scope link src 100.64.64.1
157.x.x.1 dev ens6 proto dhcp scope link src 157.x.x.x metric 100
192.168.40.0/24 dev wg0 scope link
192.168.178.0/24 dev wg0 scope link
212.227.123.16 via 157.x.x.1 dev ens6 proto dhcp src 157.x.x.x metric 100
212.227.123.17 via 157.x.x.1 dev ens6 proto dhcp src 157.x.x.x metric 100
Keine Ahnung wo die 212.227.123.16 & 17 herkommen....

14-11-_2023_10-15-03

Irgendwas fehlt mir auf jeden fall noch...

VG
Member: aqui
aqui Nov 14, 2023 updated at 11:07:06 (UTC)
Goto Top
Einen groben Kardianalsfehler hast du begangen, denn du hast dem Server und dem Client die gleiche lokale IP Adresse 100.64.64.1/24 gegeben!!
Mal ehrlich wenn es an solchen Banalitäten die jeder Azubi im ersten Lehrjahr scheitert muss man sich nicht wundern. Doppelte IP Adressen sind ein NoGo im TCP/IP!
Halte dich an das Tutorial das empfhielt dem Server die höchste IP zu geben (bei einem 24er Prefix die .254) und die Clients ab .1 oder auch .101 usw. durchzunummerieren. So vermeidet man solche groben Anfänger Fauxpas'.
Server also:
[Interface]
Address = 100.64.64.254/24
PrivateKey = QDpsUBDpk
ListenPort = 51820

[Peer]
PublicKey = x4LyrRAquJ
AllowedIPs = 100.64.64.101/32
Erster Client dazu:
[Interface]
PrivateKey = QOIuIQTtfaz53
Address = 100.64.64.101/24

[Peer]
PublicKey = pCqtnC0AXLvrl
AllowedIPs = 100.64.64.254/32
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 25
Den Keepalive sollte man nicht unnötigerweise hochsetzen weil die UDP Sessiontimeouts in NAT Routern oder Firewall selten unter 30 liegen!

hier bekomme aber jetzt bei aktiver Verbindung keine Internetverbindung mehr...
Was ja auch verständlich ist, denn das Setup oben ist eine klassische "Split Tunneling" VPN Verbindung die einzig und allein nur das in den VPN Tunnel routet was in die 3 remoten Netze soll.

Wenn du über den Tunnel ins Internet willst musst du aber eine Gateway Redirect Verbindung aufsetzen, die ALLES in den Tunnel routet.
Diese Thematik ist HIER genau beschrieben. Lesen und verstehen... 😉

Folglich sind deine Todos für einen Redirect:
  • AllowedIP Parameter anpassen
  • DNS Server muss einer sein der über den Tunnel erreichbar ist. Ggf. IP Connectivity Check nur mit nackter IP um DNS Probleme temorär auszuschliessen. Ein nslookup muss Adressen auflösen können!
  • Traffic aus dem internen WG IP Netz den die Clients nutzen muss am WG Server masqueraded (NAT per nftables etc.) werden da RFC 1918 IPs NICHT geroutet werden.

Deine nftables Rules sind soweit korrekt. Ein nft list ruleset zeigt die Aktivität der Firewall
Vorsichtig solltest du mit der Nutzung der RFC 6598 Adressen (100.64.0.0 /10) sein fürs interne Netz.
Das geht nur wenn du keine DS-Lite Anschlüsse hast und Provider diesen Shared Adress Space NICHT nutzen mit deinem VPN Setup.
Wenn du da auf Nummer sicher gehen willst nutzt du dann besser RFC 1918 IP Netze mit einer sicheren VPN Adresse.
Member: entfernt
entfernt Nov 14, 2023 updated at 13:32:26 (UTC)
Goto Top
Also aktuell steh ich echt absolut auf dem Schlauch, Du könntest mir das genauso gut gerade auf chinesisch erklären....

Die Internetverbindung klappt zumindest schon mal wieder wenn ich verbunden bin...
Aber dennoch ist meine öffentliche Adresse am Client weiterhin die des Client-Netzes, nicht die des vServers

Ok das mit den doppelten IP-Adressen ist natürlich doof gelaufen ^^

Sieht jetzt aber so aus

Win-CLIENT
[Interface]
PrivateKey = QOIuIQTtfaz53yf-------------1+H/QGU=
Address = 100.64.64.101/24
DNS = 192.168.188.1

[Peer]
PublicKey = pCqtnC0A-----------pnerDcO0A=
AllowedIPs = 100.64.64.254/32
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 25

Server config:
[Interface]
Address = 100.64.64.254/24
PrivateKey = QDpsUBDpk8---------------19CgF2hkc=

ListenPort = 51820

[Peer]
PublicKey = x4LyrRAquJ------------------Rjh+DNfnqhU=
AllowedIPs = 100.64.64.101/32


Wenn du über den Tunnel ins Internet willst musst du aber eine Gateway Redirect Verbindung aufsetzen, die ALLES in den Tunnel routet.
Diese Thematik ist HIER genau beschrieben. Lesen und verstehen... 😉
Wenn ich auf das 0.0.0.0/0 ändere schließe ich mich immer selbst aus und muss das über die Konsole wieder ändern...


Folglich sind deine Todos für einen Redirect:
  • AllowedIP Parameter anpassen
Wie gesagt auf 0.0.0.0/0 klappt bei mir nicht...
* DNS Server muss einer sein der über den Tunnel erreichbar ist. Ggf. IP Connectivity Check nur mit nackter IP um DNS Probleme temorär auszuschliessen. Ein nslookup muss Adressen auflösen können!
Geändert auf 192.168.188.1, ist die Fritte vom Client, keine Ahnung ob das richtig ist....
* Traffic aus dem internen WG IP Netz den die Clients nutzen muss am WG Server masqueraded (NAT per nftables etc.) werden da RFC 1918 IPs NICHT geroutet werden.
Äh ja... Gar keine Ahnung was ich da jetzt wo machen muss :/
Deine nftables Rules sind soweit korrekt. Ein nft list ruleset zeigt die Aktivität der Firewall
root@ubuntu:~# nft list ruleset
table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }
}
table ip nat {
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "ens6" ip daddr 192.168.188.0/24 accept  
                ip saddr 100.64.64.0/24 oif "ens6" masquerade  
        }

        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "ens6" counter packets 43 bytes 12348 masquerade  
        }
}
table ip filter {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                iifname "ens6" oifname "wg0" counter packets 0 bytes 0 accept  
                iifname "wg0" counter packets 37 bytes 17108 accept  
        }
}
table ip6 filter {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                iifname "wg0" counter packets 0 bytes 0 accept  
        }
}
table ip6 nat {
        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "ens6" counter packets 18 bytes 2416 masquerade  
        }
}
Vorsichtig solltest du mit der Nutzung der RFC 6598 Adressen (100.64.0.0 /10) sein fürs interne Netz.
Das geht nur wenn du keine DS-Lite Anschlüsse hast und Provider diesen Shared Adress Space NICHT nutzen mit deinem VPN Setup.
Wenn du da auf Nummer sicher gehen willst nutzt du dann besser RFC 1918 IP Netze mit einer sicheren VPN Adresse.
Also die Testumgebung ist kein DSLite Anschluss aber generell werde ich das dann ändern

Absolut am verzweifeln hier 😵‍💫😫😫
Member: aqui
aqui Nov 14, 2023 at 14:03:43 (UTC)
Goto Top
Also aktuell steh ich echt absolut auf dem Schlauch
Wie ist das möglich, denn die doppelte IP Vergabe der Server und Client IP im internen VPN Netz ist ja eindeutig falsch. Um das zu erkennen muss man kein Chinesisch können....
heart1
Member: entfernt
entfernt Nov 14, 2023 at 14:10:24 (UTC)
Goto Top
Zitat von @aqui:

Also aktuell steh ich echt absolut auf dem Schlauch
Wie ist das möglich, denn die doppelte IP Vergabe der Server und Client IP im internen VPN Netz ist ja eindeutig falsch. Um das zu erkennen muss man kein Chinesisch können....

Das meinte ich auch nicht sondern das ich immer noch nicht dahin komme wo ich hin will ^^
Mit den doppelten IP-Adressen ist klar und das habe ich natürlich behoben.
Aber wie gesagt, ins Internet komme ich jetzt mit verbundenem Tunnel aber wenn ich auf wieistmeineip.de gehe bekomme ich immer noch nicht die IP meines vServers zu sehen....
Member: aqui
aqui Nov 14, 2023 updated at 15:01:57 (UTC)
Goto Top
wenn ich auf wieistmeineip.de gehe bekomme ich immer noch nicht die IP meines vServers zu sehen....
Weil deine DNS Konfig in einem Redirect Setup Blödsinn ist! face-sad

Das doppelte Adressproblem hast du aber zumindestens nun korrigiert. Das o.a. Beispiel war aber reduziert auf eine reine Client Server Kommunikation um die Adressierungsproblematik der doppelten IP aufzuzeigen.

Eine Redirect Konfig sähe dann für den Client so aus:
[Interface]
PrivateKey = QOIuIQTtfaz53yf
Address = 100.64.64.101/24
DNS = 192.168.188.1

[Peer]
PublicKey = pCqtnC0A
AllowedIPs = 0.0.0.0/0
Endpoint = 157.x.x.x:51820
PersistentKeepalive = 25
Die Server Konfig bleibt so wie sie ist.

⚠️ Wichtig ist das der Server eine Default Route auf den Internet Router hat und der Internet Router eine statisch IP Route auf das 100.64.64.0er Netz mit Next Hop auf die lokale WG Server IP.
Das o.a. gilt natürlich nur wenn der Server im eigenen Heimnetz liegt.
Sofern der WG Server ein vServer mit öffentlicher IP ist entfällt das natürlich, denn ein gehosteter vServer hat ja schon ein Bein direkt im Internet und fungiert ja selber dann schon als Router.

Ist er ein vServer, dann darf aber der Client logischerweise niemals die DNS Adresse auf die o.a. gesetzt haben. Klar, denn bei einem Redirect landen DNS Anfragen dann bei 192.168.188.1 und werden durch die Redirect Konfig zwangsweise immer in den Tunnel geroutet, wo natürlich keine RFC1918 IP Netze sind.
Ein vServer kann deshalb unroutebare RFC1918 IPs niemals erreichen und somit landet dann jede DNS Anfrage im Nirwana.

Wenn, dann muss als DNS Server in der Client Konfig hier zwingend die DNS IP Adressen des vServer Hosters stehen!! Welche das sind erfährt man immer auf den Info Seiten seines vServer Hosters. Alternativ geht zur Not eine Allgemeine die aus Datenschutz Sicht unbedenktlich ist wie z.B. 9.9.9.9.
Nun solltest du eigentlich davon genug Ahnung haben um dir die Frage ob das obige DNS Setup richtig oder ob das völliger Unsinn ist, ganz sicher selbst beantworten zu können. face-wink
Bei aktivem VPN Client sollte ein nslookup www.administrator.de immer eine korrekte Antwort ergeben wenn es richtig konfiguriert wurde.

Ob das IP Routing ins Internet über den Redirect sauber funktioniert kann man immer mit Traceroute und einer nackten Internet Ziel IP checken. IP Adresse weil dies DNS Fehler erstmal außen vor lässt.
Bei Winblows ist das das tracert Kommando. Sprich ein tracert 8.8.8.8 sollte dann den kompletten Pfad zum Ziel über den VPN Tunnel zeigen.
Surft man bei aktivem VPN Tunnel z.B. zu http://myexternalip.com dann sollte als Internet IP die WAN Port IP des vServers angezeigt werden über die ja jeglicher VPN Traffic dann ins Internet geht via NAT/Masquerading.
Soviel zur simplen Theorie die de facto keinerlei Fremdsprachen erfordert... face-wink

Noch ein wichtiger Security Tip...
Du solltest die Input und Prerouting Chain der nftables Firewall noch etwas dichter machen, denn im Moment erlaubt deine einfache Konfig allen möglichen Angreifern den Zugriff.
Über failtoban solltest du bei einem öffentlichen vServer auch nachdenken.
Aber bitte erst nachdem alles andere sauber funktioniert!! face-wink
#!/usr/sbin/nft -f

flush ruleset

# Interface name
define pub_iface = "en123"  
# Wireguard port
define wg_port = 51820

table inet drop-bad-ct-states {
	chain prerouting {
		type filter hook prerouting priority -150; policy accept;
		# Drop packets in "invalid" connection-tracking state 
		ct state invalid drop
		# Drop tcp packets for new connections that aren't syn packets 
		tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
		# Drop XMAS packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
		# Drop NULL packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
		# Drop new connections over rate limit
		ct state new limit rate over 1/second burst 20 packets drop
		}
}

table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;
		# Akzeptiert localhost traffic
		iif lo accept

		# Akzeptiert Wireguard tunnel traffic
		iifname "wg0" accept  

		# Akzeptiert traffic vom eigenen Server
		ct state established,related accept

		# Akzeptiert ICMP types
		ip protocol icmp icmp type { time-exceeded, parameter-problem, destination-unreachable } accept
		# Akzeptiert lokale TCP Dienste
		iif $pub_iface tcp dport { ssh, https } ct state new accept

		# Akzeptiert UDP Traffic
		iif $pub_iface udp dport { $wg_port } accept 

		# Akzeptiert Neighbour discovery otherwise IPv6 connectivity breaks.
		ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

		# log and count dropped traffic
		# log prefix "[nftables]Denied: " counter drop 
		# only count dropped traffic
		counter drop
	}
Member: entfernt
entfernt Nov 14, 2023 at 17:31:20 (UTC)
Goto Top
Ok jetzt klappt es face-smile

Noch ein wichtiger Security Tip...
Du solltest die Input und Prerouting Chain der nftables Firewall noch etwas dichter machen, denn im Moment erlaubt deine einfache Konfig allen möglichen Angreifern den Zugriff.

Kann ich das so übernehmen wie Du das gepostet hast oder muss ich da noch was anpassen ?

Eine Kleinigkeit ist mir aber noch aufgefallen.
Wenn ich das richtig verstanden habe, geht ja jetzt der gesamte Verkehr des Clients durch den Tunnel was zur Folge hat, wenn der Tunnel aktiv ist, bricht meine putty Verbindung ab.
Im Grunde könnte ich damit leben weil ich eigentlich nicht beides gleichzeitig brauche, aber würde es eine schnelle Lösung dafür geben ?

VG

Achso, mit dem failtoban guck ich mir auf jeden Fall auch noch an!

Wie immer vielen Dank für Deine kompetente Hilfe und Deine Geduld :D
Member: aqui
aqui Nov 15, 2023, updated at Nov 26, 2023 at 13:58:13 (UTC)
Goto Top
geht ja jetzt der gesamte Verkehr des Clients durch den Tunnel
Das hast du richtig verstanden. Mit "AllowedIPs 0.0.0.0/0" betreibst du ja eine Gateway Redirect Konfig, sprich dein Default Gateway am Client wird komplett auf den VPN Tunnel umgebogen so das sämtlicher, nicht lokaler Traffic in den VPN Tunnel geroutet wird.
wenn der Tunnel aktiv ist, bricht meine putty Verbindung ab.
Nicht wenn du sie dann mit der internen WG IP Adresse des Servers aufbaust. face-wink
Kann ich das so übernehmen
Ja kannst du. Beachte allerdings das es nur der Part mit der Input und Prerouting Chain ist. Den unterne Part mit NAT usw. musst du aus deiner bestehenden Konfig übernehmen.
Die Variablen oben des pub_iface und wg_port musst du natürlich auf deine aktuell verwendeten Namen bzw. Ports anpassen.
Falls erforderlich kann ich dir aber nochmal die vollständige nftables.conf posten. face-wink
Member: aqui
aqui Nov 26, 2023 at 13:57:39 (UTC)
Goto Top
Wenn es das denn nun war:
How can I mark a post as solved?
nicht vergessen!
GermansolvedQuestionVPN
Hotly discussed
DaniEnd of availability for classic Teams clientDani - 2 CommentsFrankUbuntu 24.04 LTS Noble Numbat availableFrankadmtechDeveloper diary: Release 6.1admtech