04.12.2023, aktualisiert um 23:03:57 Uhr

3988

WireGuard funktioniert nur mit einem Tunnel

Moin,

seit mehreren Tagen versuche ich im Rechenzentrum ein WireGuard-Server zum laufen zu bringen.
Jeweils 1 Tunnel alleine geht = nur beim Aufbau eines 2ten Tunnels geht der 2te Tunnel nicht ins öffentliche Netz

Eckdaten vom Server:

/26 Netz. (62 öffentliche IPv4 Adressen)
VMWARE unterbau
10 virtuelle Netzwerkkarten (ens32 => ens42)
Debian 12 (neu aufgesetzt, somit aktueller Stand)

SERVER-Ausgaben:

ip a
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0e:57:7c:ba:9b brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet 109.+++.+++.23/26 brd 109.+++.+++.63 scope global ens32
       valid_lft forever preferred_lft forever
    inet6 fe80::++:++:++:abb9/64 scope link
       valid_lft forever preferred_lft forever 

[..]

50: VPN1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 192.168.206.101/24 scope global VPN1
       valid_lft forever preferred_lft forever

cat /etc/wireguard/VPN1.conf

[Interface]
Address = 192.168.206.101/24
SaveConfig = true
PostUp = iptables -A FORWARD -i wg1 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens32 -j MASQUERADE; ip6tables -A FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o ens32 -j MASQUE>
PostDown = iptables -D FORWARD -i wg1 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens32 -j MASQUERADE; ip6tables -D FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o ens32 -j MASQ>
ListenPort = 50001
PrivateKey = qM+++++FA=

[Peer]
PublicKey = Kr+++++UM=
AllowedIPs = 192.168.206.201/32

interface: VPN1
  public key: KH+++++xc=
  private key: (hidden)
  listening port: 50001

peer: Kr+++++UM=
  endpoint: 79.+++.+++.224:61989
  allowed ips: 192.168.206.201/32
  latest handshake: 35 seconds ago
  transfer: 319.81 KiB received, 4.83 KiB sent

CLIENTSEITIG

Debian 12 neu aufgesetzt
Ebendfalls VMWare unterbau.
Netzwerkkarte: NAT und Briged getestet. Aktuell auf NAT (192.168.30.*)
Steht bei mir daheim über 100MBits DSL (Fritte: 192.168.2.1).

ip a

2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:<MAC>:10 brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 192.168.30.110/24 brd 192.168.30.255 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::+++;+++:cb10/64 scope link
       valid_lft forever preferred_lft forever
20: VPN1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 192.168.206.201/32 scope global VPN1
       valid_lft forever preferred_lft forever

cat /etc/wireguard/VPN1.conf

## Der Client. Public Key bei der Ausgabe von: cat /etc/wireguard/pubkey
[Interface]
PrivateKey = D9+++++lEs=
Address = 192.168.206.201/32
DNS = 1.1.1.1

## Der Server. Public Key ist der, wenn man die Schnittstelle startet und bei "interface: VPN1" schaut (beim Server) 
[Peer]
PublicKey = KH+++++xc=
Endpoint = 109.+++.+++.23:50001
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

interface: VPN1
  public key: Kr+++++UM=
  private key: (hidden)
  listening port: 60783
  fwmark: 0xba0a

peer: KH+++++Fxc=
  endpoint: 109.+++.+++.23:50001
  allowed ips: 0.0.0.0/0
  latest handshake: 42 seconds ago
  transfer: 7.12 KiB received, 793.95 KiB sent
  persistent keepalive: every 25 seconds

So. Wieman sieht, besteht der VPN-Tunnel. Pings gehen auch alle perfekt durch

Ausgaben vom Client aus

ping 109.+++.+++.23 (<= die IP vom Server von ens32)
PING 109.+++.+++.23 (109.+++.+++.23) 56(84) bytes of data.
64 bytes from 109.+++.+++.23: icmp_seq=1 ttl=64 time=16.5 ms

ping 192.168.206.101
PING 192.168.206.101 (192.168.206.101) 56(84) bytes of data.
64 bytes from 192.168.206.101: icmp_seq=1 ttl=64 time=15.9 ms

ping 192.168.206.201
PING 192.168.206.201 (192.168.206.201) 56(84) bytes of data.
64 bytes from 192.168.206.201: icmp_seq=1 ttl=64 time=0.021 ms

ping google.de
PING google.de (172.217.19.67) 56(84) bytes of data.
64 bytes from ham02s17-in-f3.1e100.net (172.217.19.67): icmp_seq=38 ttl=117 time=28.8 ms

Wie schon eingangs erwähnt ist der Aufbau EINES Tunnels problemlos möglich.
Wenn ich aber VPN2 hochfahre, dann bekommt VPN kein ping von googel. Die anderen erwähnten pings gehen aber.

Hinweis:
VPN2 benutzt natürlich seine eigene Netzwerkkarte (ens34) die mit einer öffentlichen IP-v4-Adresse(109.+++.+++.24) erreichbar ist.
VPN2 hat auch eigene Keys und natürlich eigene Ports (immer +1).
Sprich:
SERVER

[Interface]
Address = 192.168.206.102/24
PostUp = iptables -A FORWARD -i wg2 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens34   <= etc. wg1 wurde zu wg2 || ens32 zu ens34
ListenPort = 50002

[Peer]
AllowedIPs = 192.168.206.202/32

CLIENT

[Interface]
Address = 192.168.206.202/32

[Peer]
Endpoint = 109.+++.+++.24:50002

Das waren jetzt nur die differenzen. Keys und so existieren natürlich auch. Sofern gewünscht kann ich das ungekürzt nochmal mit reinpacken

Weiß einer Rat wo ich suchen könnte/müsste ?
Bzw. welche Ausgabe soll ich auch Posten ?
Wieso kann ich keine 2 physiche Netzwerkkarten(aus Sicht des BS) mit 2 öffentlichen IP Adressen hochfahren ?

VIELEN DANK

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6999663623

Url: https://administrator.de/forum/wireguard-funktioniert-nur-mit-einem-tunnel-6999663623.html

Ausgedruckt am: 22.12.2024 um 11:12 Uhr

33 Kommentare

Neuester Kommentar

Servus!

Ohne deine Konfig genauer studiert zu haben:
Ich vermute, dass der Aufbau des 2. Tunnels eine weitere Default-Route aktiviert. Dein Debian weiß dann nicht mehr, wohin mit den Paketen und macht Murks.

Hallo,

Zitat von @Snowman25:
weitere Default-Route aktiviert. Dein Debian weiß dann nicht mehr, wohin mit den Paketen und macht Murks.

Welches OS kommt denn mit mehreren Default Gateways klar? Mit mehreren Gateways kommt eigentlich jedes OS klar.
https://de.wikipedia.org/wiki/Standardannahme
https://de.langenscheidt.com/englisch-deutsch/default
https://www.computerweekly.com/de/definition/Default
https://www.dictindustry.de/englisch-deutsch/default
https://www.thomas-krenn.com/de/wiki/Zwei_Default_Gateways_in_einem_Syst ...
https://www.linuxmaker.com/linux/ein-system-mit-zwei-default-gateways.ht ...
https://www.andysblog.de/linux-mehrere-gateways-und-unterschiedliche-sub ...
https://de.wikipedia.org/wiki/Routingtabelle

Gruß,
Peter

VPN1.conf:
Address = 192.168.206.101/24
VPN2.conf
Address = 192.168.206.102/24

Die zwei Bereiche überlappen sich. Ich bin mir nicht sicher ob das in Ordnung ist.

Versuche mal unabhängige Bereiche z.B.:
VPN2.conf
Address = 192.168.207.101/24

@NordicMike
DANKE.. das war es tatsächlich.
Dann kann ich auch den: ListenPort = 50002 wieder auf standard setzen.
Jetzt klappt der Aufbau super.

ABER: Weißt du auch einen Rat zur Portfreigabe.
Ich bin mir noch nicht ganz sicher, ob ich VPN bzw. dessen Route korrekt verstanden habe.

Aus Sicht des Client:
192.168.30.110/24 (NAT vom VMWare Player
an 192.168.201.201/32 (definiert in der VPN1.conf)

an 192.168.101.101/32 (an Server in dessen VPN1.conf)
raus über 109.+++.+++.23 (öffentliche IP)

MÜSSTE so korrekt sein.
Grund meiner Frage: Ich brauche eine durchgängige Portfreigabe. Die klappt in öffentlichen Bereich dann aber nicht mehr.

Auf dem CLIENT

ss -tulwn | grep LISTEN
tcp   LISTEN 0      128          0.0.0.0:1234       0.0.0.0:*
tcp   LISTEN 0      128             [::]:1234          [::]:*

Der benötigte Port ist auf IPv4+IPv6 offen.

nmap -sT -O 192.168.201.201 -p 1234

PORT     STATE SERVICE
1234/tcp open  pcsync-http

Auf Client vor dem Tunnel auch akiv

nmap -sT -O 192.168.202.202 -p 1234

PORT     STATE SERVICE
1234/tcp open  pcsync-http

Und auch über den Tunnel hinaus offen.

nmap -sT -O 109.+++.+++.23 -p 1234

PORT     STATE  SERVICE
1234/tcp closed pcsync-http

Und DA hab ich mein Problem. Über die öffentliche IP erreiche ich den Port nicht mehr.
Auf den WireGuard Server ist die FW mitunter auch schon runtergefahren.
ufw allow 1234/udp war aber schon aktiv. HÄTTE somit auch mit FW greifen müssen.

Wo könnte hier die Ursache sein?
Könnte es sein, dass ich das im RZ erst anfragen/freigeben muß?
Oder hab ich noch intern ein Problem?
Danke nochmals für Ideen.

Ich habe die Beschreibung noch nicht ganz verstanden. Ich dachte 50002 wäre dein Listen Port, wo kommt nun Port 1234 zum Einsatz?

Zum Thema öffentlich: Öffentlich würde ich sowieso nur auf Port 443 rein lassen.

Die zwei Bereiche überlappen sich.

Wo überlappen die sich denn?? Die beiden IPs sind doch zumindestens für ein /24er Netz vollkommen korrekt wenn es um die interne WG IP Adressierung geht! Siehe Wireguard Tutorial:
Merkzettel: VPN Installation mit Wireguard

Der TO redet oben von einem /26er Netz intern aber hat seine Konfig dann überall mit /24er Masken versehen. Wirr und versteht man nicht denn diese Adressierung ist dann falsch wenn eine /26er relevant sein soll. 🧐

Den weiteren Kardinalsfehler den der TO gemacht hat ist, leider mal wieder, das völlig überflüssige NAT (Masquerading) im Tunnel. Damit ist dann ein transparentes Routing nicht möglich, denn das NAT im VPN Tunnel schafft, wie immer, eine routingtechnische Einbahnstrasse.

Eine klassische Konfig mit einem WG Server und 2 Client Peers sähe so aus wenn das interne WG IP Netz, wie vom TO geplant, ein /26er Netz ist:
Bei einer 192.168.206.101 Server Adresse (Vorgabe des TO's oben) mit einem /26er Prefix intern verwendet der TO also das...

Netzwerk: 192.168.206.64
Adressierbare Hostadressen: 192.168.206.65 bis 192.168.206.126
Client Adressen hier im Beispiel mit dem o.a. internen Netz des TOs: Client-1 = 192.168.206.65, Client-2 = 192.168.206.66

Konfiguration Server:

[Interface]
Address = 192.168.206.101/26
PrivateKey = <Privater_Key_Server>
ListenPort = 50001

[Peer]
PublicKey = <Öffentlicher_Key_Client-1>
AllowedIPs = 192.168.206.65/32

[Peer]
PublicKey = <Öffentlicher_Key_Client-2>
AllowedIPs = 192.168.206.66/32 

Konfiguration Client-1:

[Interface]
Address = 192.168.206.65/26
PrivateKey = <Privater_Key_Client-1>

[Peer]
PublicKey = <Öffentlicher_Key_Server>
Endpoint = 109.x.y.24:50001
AllowedIPs = 192.168.206.101/32 
PersistentkeepAlive = 25

Konfiguration Client-2:

[Interface]
Address = 192.168.206.66/26
PrivateKey = <Privater_Key_Client-2>

[Peer]
PublicKey = <Öffentlicher_Key_Server>
Endpoint = 109.x.y.24:50001
AllowedIPs = 192.168.206.101/32 
PersistentkeepAlive = 25 

Was ist denn so schwer an solch einer banalen WG Konfig?! 🤔
Siehe dazu auch ein Praxistutorial.

Die interne IP Adressierung kann man auch etwas intelligenter lösen und nicht so wirr wie der TO wenn man sich das Leben etwas erleichtern will.
Man gibt dem Server die höchste Adresse im internen Netz und die Clients starten "unten" z.B. bei .1 aufsteigend nach oben.
Mit dem Beispiel des TO und seinem selbst vorgegebenen /26er Prefix (255.255.255.192), dann z.B. das 0er Netz mit:

Netzwerk = 192.168.206.0/26 (Adressrange: 192.168.206.1 bis 192.168.206.62)
Server = 192.168.206.62
Client-1 = 192.168.206.1
Client-1 = 192.168.206.2

IP Adressierung erste Klasse Grundschule... 😉

Wo überlappen die sich denn??

Die zwei Instanzen der VPN Netze:

VPN1.conf:
Address = 192.168.206.101/24
VPN2.conf
Address = 192.168.206.102/24

Der TO redet oben von einem /26er Netz intern aber hat seine Konfig dann überall mit /24er Masken versehen.

Sein "externes" Netz ist /26, nicht sein internes. Die Konfig seiner externen Netzwerkkarte ens32 wäre also mit dem oben abgebildeten "inet 109.+++.+++.23/26" korrekt. Die 24er Masken hat er auf den Schnittstellen der zwei VPN Instanzen, die kann er so groß wählen wie er möchte. Diese müssen ja nicht gleich groß mit seinem externen Netzwerk sein.

Also so habe ich es zumindest verstanden...

Die zwei Instanzen der VPN Netze:

Sind auch überflüssig und braucht man in der Regel ja nicht bei WG.

Diese müssen ja nicht gleich groß mit seinem externen Netzwerk sein.

Absolut korrekt.

Sein "externes" Netz ist /26, nicht sein internes.

Sorry, das war in der etwas wirren Schilderung oben nicht ganz klar. Gut, die Standard Konfig mit 2 Peers steht ja oben und die Anpassung der IP Adressen ist ja auch kein Hexenwerk.

Sind auch überflüssig und braucht man in der Regel ja nicht bei WG.

Stimmt eigentlich. Auf eine Instanz können sich mehrere Clients verbinden.
Eine zweite Instanz kann man aufbauen, wenn man unterschiedliche Firewall Regeln pro Instanz erstellen möchte und man die einzelnen IPs der Clients nicht pflegen möchte.

wenn man unterschiedliche Firewall Regeln pro Instanz erstellen möchte

Aber auch das wäre überflüssig, denn das kann man mit entsprechenden nftables Regeln auch zentral umsetzen.
Unterschiedliche Instanzen sind überflüssige Performancefresser und machen das Setup unnötigerweise komplexer und unsicherer.

mit entsprechenden nftables Regeln auch zentral umsetzen

Dafür müsstest du eben die einzelnen IPs der Clients (oder dessen MAC Adressen) pflegen, um sie in der Regel zu unterscheiden.
Wenn das System genügend RAM hat können ruhig zwei Instanzen laufen. Bei uns laufen 7 Instanzen und OpenVPN ist ausreichend performant um die WAN Leitung komplett dicht zu bekommen

Dafür müsstest du eben die einzelnen IPs der Clients (oder dessen MAC Adressen) pflegen

Das ist ja bei WG und seinem Cryptokey Routing ja quasi "im System" eingebaut.

und OpenVPN ist ausreichend performant

Nicht wirklich... 🤣 OpenVPN skaliert da eher sehr schlecht und IPsec oder WG machen da einen deutlich besseren (VPN) Job.

Aber wir wollen hier jetzt nicht den Thread des TO's kapern und ihm wieder das Wort geben... 🏴‍☠️

Welche üble Hardware wurde da genommen? Unser OpenVPN schafft deutlich mehr

Zitat von @NordicMike:
Ich habe die Beschreibung noch nicht ganz verstanden. Ich dachte 50002 wäre dein Listen Port, wo kommt nun Port 1234 zum Einsatz?

Nein... 50002 ist ja der Listing-Port von WG.
1234 ist der Port warum ich überhaupt VPN benötigt. Ich habe eine Programm, was zwingend einen gewissen Port benötigt. Dieser ist leider auch nicht veränderbar.
Wenn ich das Programm einmal starte = alles i.o.
Starte ich es ein 2tes mal parallel, gibt es eine Fehlermeldung, dass Port XY schon belegt ist.

@aqui
Dein Vorschlag werde ich gleich umsetzen. Dann ist das sauber im Range. Ich hab den INTERNEN Adressbereich tatsächlich garnicht berechnen. Vermutlich mach ich einen /24 draus. Da brauch ich nciht rechnen... den kennt wohl jeder auswendig

(1-255)

Allerdings MUß jeder VPN Tunnel extern über eine andere IP rauskommen.
(Vermutlich MUß nicht.. aber 1: ich hab IP Adressen ungenutzt drüber und 2: ich finde das Routing einfacher. Wenn jetzt noch FW mit MAC-Adress-Filter zum Einsatz kommt, dann wird's ein immer schwierigeres Setup).

Nachtrag: Ich hatte auf alle 3 Testsystemen einen dauerping auf googel am laufen und habe dann die VPN aufgebaut. Auf alle 3 Systemen hatte ich dann einen Ping..... damals. Mitunter geht dieser nur noch bei einen System.
Tunnel selbst besteht aber noch. War somit nicht von langer "Haltbarkeit"

Der WG-Server sagt:

interface: VPN3
  public key: lY+++++Gk=
  private key: (hidden)
  listening port: 50003

peer: ZR+++l8=
  endpoint: 84.+++.+++.243:36088
  allowed ips: 192.168.203.203/32
  latest handshake: 3 minutes, 46 seconds ago
  transfer: 62.41 KiB received, 32.88 KiB sent

interface: VPN2
  public key: A5+++++Ro=
  private key: (hidden)
  listening port: 50002

peer: L/+++++DM=
  endpoint: 84.+++.+++.243:50307
  allowed ips: 192.168.202.202/32
  latest handshake: 57 seconds ago
  transfer: 23.61 MiB received, 88.12 MiB sent

interface: VPN1
  public key: KH+++++Fxc=
  private key: (hidden)
  listening port: 50001

peer: Kr+++++UM=
  endpoint: 84.+++.+++.243:54745
  allowed ips: 192.168.201.201/32
  latest handshake: 2 minutes, 43 seconds ago
  transfer: 16.57 MiB received, 481.90 MiB sent

Aber ich setze mal aqui's Vorschlag + /24 um.
Ich werde berichten

Port 1234 muss nicht über das öffentliche Netz durchgereicht werden. Sobald die VPN Verbindung steht, gehen da alle Ports verschlüsselt durch. Es reicht, dass nur der VPN Port, also 50002 von Aussen erreichbar ist, den ich persönlich zwecks Fehlervermeidung auf 443 gelegt hätte.

Port 1234 muss nicht über das öffentliche Netz durchgereicht werden. Sobald die VPN Verbindung steht, gehen da alle Ports verschlüsselt durch. Es reicht, dass nur der VPN Port, also 50002 oder 50001 von Aussen erreichbar ist, den ich persönlich zwecks Fehlervermeidung auf 443 gelegt hätte.

Allerdings MUß jeder VPN Tunnel extern über eine andere IP rauskommen.

Darf man fragen warum? Was sollte der tiefere Sinn von sowas sein?

Zum Rest mit dem 1234 Port hat Kollege @NordicMike ja schon alles gesagt...

Also erstmal die gute Nachricht...

Die 3 Spielwiesen laufen... sprich: ping kommt auch nach gute 2h bei googel an.

ABER: Wireguard geht immer über eine IP raus.

VPN1 + VPN2 + VPN3 liefern beim Befehl... die gleiche öffentliche IP.

curl ifconfig.me
109.+++.+++.24

Die *.24 ist VPN2 zugewiesen.

Nochmal zur Übersicht:

interface: VPN1
  public key: KH+++++xc=
  private key: (hidden)
  listening port: 50001

peer: Kr+++++UM=
  endpoint: 84.xxx.xxx.243:50000
  allowed ips: 192.168.201.0/24
  latest handshake: 8 seconds ago
  transfer: 5.92 MiB received, 195.44 MiB sent

interface: VPN2
  public key: A5+++++Ro=
  private key: (hidden)
  listening port: 50002

peer: L/+++++DM=
  endpoint: 84.+++.+++.243:59866
  allowed ips: 192.168.202.0/24
  latest handshake: 1 minute, 29 seconds ago
  transfer: 7.01 MiB received, 111.62 MiB sent

interface: VPN3
  public key: lY+++++Gk=
  private key: (hidden)
  listening port: 50003

peer: ZR+++++l8=
  endpoint: 84.+++.+++.243:38235
  allowed ips: 192.168.203.0/24
  latest handshake: 48 seconds ago
  transfer: 4.82 MiB received, 311.17 MiB sent

Wie man sieht... /24. Danke aqui. Damit scheinen die VPN's nun erstmal zu laufen.

Zur Erinnerung. Jede VPN Verbindung hat sein eigenes Template (conf-Datei)
Hier jetzt mal VPN3

[Interface]
Address = 192.168.103.103/24
SaveConfig = true
PostUp = iptables -A FORWARD -i VPN3 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens35 -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i VPN3 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens35 -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT
ListenPort = 50003
PrivateKey = SO+++++0Y=

[Peer]
PublicKey = ZR+++++l8=
AllowedIPs = 192.168.203.0/24

Wie man hier sieht, weise ich der FW für VPN3 die Netzwerkkarte: ens35 zu.
diese sieht wie folgt aus:

4: ens35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0e:57:7c:ba:9b brd ff:ff:ff:ff:ff:ff
    altname enp2s3
    inet 109.+++.+++.26/26 brd 109.+++.+++.63 scope global ens35
       valid_lft forever preferred_lft forever
    inet6 fe80::++++:abcd/64 scope link
       valid_lft forever preferred_lft forever

später
68: VPN3: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 192.168.103.103/24 scope global harvester3
       valid_lft forever preferred_lft forever

Warum jetzt die Ausgabe von VPN3?

VPN1 hab ich auf die IP/Netzwerkkarte(ens32) gesetzt. Also 109.+++.+++.23/26 (also der Wireguard-Server selbst)
VPN2 hab ich auf die IP/Netzwerkkarte(ens34) gesetzt. Also 109.+++.+++.24/26
VPN3 hab ich auf die IP/Netzwerkkarte(ens35) gesetzt. Also 109.+++.+++.26/26

curl sagt aber auf allen 3 Servern dass ich über die 109.+++.+++.24 rausgehe.
Was mich wundert. ERWARTET hätte ich ja ggf. noch die WG-IP Adresse selbst. Also die 109.+++.+++.23.

Ergo hier jetzt die VPN3 die "konfliktfrei" sein sollte. Also nicht von WG benutzt wird mit der curl-Ausgabe übereinstimmt.

Entsprechend unlogisch ist das Verhalten jetzt für mich.
Weiß hier einer Rat wieso WG so arbeitet ?

NAchtrag:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i ens32 -p tcp -m tcp --dport 1234 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i ens34 -p tcp -m tcp --dport 1234 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -i ens35 -p tcp -m tcp --dport 1234 -m state --state NEW,ESTABLISHED -j ACCEPT
-A FORWARD -i VPN1 -j ACCEPT
-A FORWARD -o VPN1 -j ACCEPT
-A FORWARD -i VPN2 -j ACCEPT
-A FORWARD -o VPN2 -j ACCEPT
-A FORWARD -i VPN3 -j ACCEPT
-A FORWARD -o VPN3 -j ACCEPT

sollte der FORWARD nicht mit einer Netzwerkkarte versehen sein?
So wie bei den 3 vorherigen Einträgen ?

Sieht schon mal verdächtig aus. ++hmmm++

Sind deine WAN Interfaces am Server separate NICs und wenn ja wie sind die angeschlossen?
Oder arbeitest du mit Secondary IP Adressen auf einer NIC?
https://www.garron.me/en/linux/add-secondary-ip-linux.html
https://ostechnix.com/how-to-assign-multiple-ip-addresses-to-single-netw ...

Relevant ist für die WAN Absender IP immer die Routing Tabelle des Servers die dir ip r zeigt.
Wenn dein Server üblicherweise Responder ist bestimmen immer die Clients mit der Endpoint Adresse die sie ansprechen auch die Absender IP. Der Server kann diese NICHT innerhalb einer Session ändern was zum sofortigen Abbruch führen würde.

Zitat von @aqui:

Sind deine WAN Interfaces am Server separate NICs und wenn ja wie sind die angeschlossen?
Oder arbeitest du mit Secondary IP Adressen auf einer NIC?

Da der Unterbau ESXi ist lautet die inoffizielle Antwort: Virtuelle NIC's.
Aus Sicht vom BS aus sollten das aber dann aber als physikalische NICs gesehen werden.

Dennoch mal die Ausgabe

default via 109.xxx.xxx.1 dev ens34 onlink
xxx.xxx.0/26 dev ens34 proto kernel scope link src 109.xxx.xxx.24
xxx.xxx.0/26 dev ens35 proto kernel scope link src 109.xxx.xxx.26
xxx.xxx.0/26 dev ens32 proto kernel scope link src 109.xxx.xxx.23
168.101.0/24 dev VPN1 proto kernel scope link src 192.168.101.101
168.102.0/24 dev VPN2 proto kernel scope link src 192.168.102.102
168.103.0/24 dev VPN3 proto kernel scope link src 192.168.103.103
168.201.0/24 dev VPN1 scope link
168.202.0/24 dev VPN2 scope link
168.203.0/24 dev VPN3 scope link 

Nachtrag von routel

Dst             Gateway         Prefsrc         Protocol Scope   Dev              Table
default         109.xxx.xxx.1                                    ens34
xxx.xxx.0/26                 109.xxx.xxx.24  kernel   link    ens34
xxx.xxx.0/26                 109.xxx.xxx.26  kernel   link    ens35
xxx.xxx.0/26                 109.xxx.xxx.23  kernel   link    ens32
168.101.0/24                 192.168.101.101 kernel   link    VPN1
168.102.0/24                 192.168.102.102 kernel   link    VPN2
168.103.0/24                 192.168.103.103 kernel   link    VPN3
168.201.0/24                                          link    VPN1
168.202.0/24                                          link    VPN2
168.203.0/24                                          link    VPN3
xxx.xxx.23                  109.xxx.xxx.23  kernel   host    ens32            local
xxx.xxx.24                  109.xxx.xxx.24  kernel   host    ens34            local
xxx.xxx.26                  109.xxx.xxx.26  kernel   host    ens35            local
xxx.xxx.63                  109.xxx.xxx.24  kernel   link    ens34            local
xxx.xxx.63                  109.xxx.xxx.26  kernel   link    ens35            local
xxx.xxx.63                  109.xxx.xxx.23  kernel   link    ens32            local
0.0.0/8                     127.0.0.1       kernel   host    lo               local
0.0.1                       127.0.0.1       kernel   host    lo               local
255.255.255                 127.0.0.1       kernel   link    lo               local
168.101.101                 192.168.101.101 kernel   host    VPN1       local
168.101.255                 192.168.101.101 kernel   link    VPN1       local
168.102.102                 192.168.102.102 kernel   host    VPN2       local
168.102.255                 192.168.102.102 kernel   link    VPN2       local
168.103.103                 192.168.103.103 kernel   host    VPN3       local
168.103.255                 192.168.103.103 kernel   link    VPN3       local

Anhand der ersten Zeile sehe ich dann schon warum NIC2 immer als ausgehende IP Adresse angezeigt wird.
Ein Rätzel weniger. Nur aktuell nicht wirklich weiter hilfreich.
Aber ich suche schon fleißig im Web. Bin offensichtlich nciht der erste der das Problem hat.. aber bisher wenig Lösungen

IPv4 Forwarding ist natürlich aktiv

cat /proc/sys/net/ipv4/ip_forward
1

https://www.wireguard.com/netns/#the-classic-solutions

Das hatte ich mir gestern schon als wichtig markiert.
Sprich: gestern schon gelesen und nicht wirklich kapiert.

Jetzt nochmal... mit dem Wissen, dass das nun tatsächlich die Lösung sein könnte.

Ich lese es mir jetzt sicherlich nochmal ein 3tes mal durch. Aber keine Ahnung was der Author mir hier sagen möchte.
Eingans offensichtlich mehrere Lösungsansätze, die keinen Reboot überleben.
Damit könnte ich aber leben.

Wiregard fährt ja die Tunnel nicht automatisch hoch. Da hab ich wenig schmerzen damit, vor den WG start noch ein paar Routen erneut zu setzen.
Nur welche wäre denn nun für mich die passende?

Anhand der ersten Zeile sehe ich dann schon warum NIC2 immer als ausgehende IP Adresse angezeigt wird.

Wie gesagt: Statt überflüssiger NICs nur eine und Secondary IPs, die lösen dein Problem...

Ein Rätzel weniger

Bretzel??

https://www.duden.de/rechtschreibung/Raetsel

Zitat von @aqui:
Wie gesagt: Statt überflüssiger NICs nur eine und Secondary IPs, die lösen dein Problem...

Na DAS klingt schon mal einfacher. Denn mit dem umbiegen der route bin ich nicht weiter gekommen.
Glücklicherweise gibt es Snapshots ^^

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface + VPN1
allow-hotplug ens32
iface ens32 inet static
        address 109.+++.+++.23/26
        gateway 109.+++.+++.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 1.1.1.1

#VPN2
allow-hotplug ens34
iface ens34 inet static
        address 109.+++.+++.24/26
        gateway 109.+++.+++.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 1.1.1.1

# TEsteintrag multiple IP's 
allow-hotplug ens34:0
iface ens34:0 inet static
  address 109.+++.+++.27/26
  netmask 255.255.255.192

ein ifup ens34:0 brachte dann auch schon n Ping.

Dann die configs nach angepasst... und gebetet, dass curl eine ander IP ausgibt.
ABER... leider nicht. Was hab ich gemacht.

Auf n Wireguard-Server den VPN3 angepasst.

[Interface]
Address = 192.168.103.103/24
SaveConfig = false
#PostUp = iptables -A FORWARD -i VPN3 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens35 -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT
#PostDown = iptables -D FORWARD -i VPN3 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens35 -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT
PostUp   = iptables -A FORWARD -i VPN3 -j ACCEPT; iptables -t nat -A POSTROUTING -s 192.168.103.0/24 -o ens34:0 -j SNAT --to-source 109.+++.+++.27; iptables -A FORWARD -o VPN3 -j >
PostDown = iptables -D FORWARD -i VPN3 -j ACCEPT; iptables -t nat -D POSTROUTING -s 192.168.103.0/24 -o ens34:0 -j SNAT --to-source 109.+++.+++.27; iptables -D FORWARD -o VPN3 -j >
ListenPort = 50003
PrivateKey = SO+++++0Y=

[Peer]
PublicKey = ZR+++++l8=
AllowedIPs = 192.168.203.0/24

Die Client-Seite hat nur die neue IP Adresse (die 27) bekommen. Rest unverändert

## Der Client. Public Key bei der Ausgabe von: cat /etc/wireguard/pubkey
[Interface]
PrivateKey = go+++++Eo=
Address = 192.168.203.203/24
DNS = 1.1.1.1

## Der Server. Public Key ist der, wenn man die Schnittstelle startet und bei "interface: harvester3" schaut 
[Peer]
PublicKey = lY+++++Gk=
Endpoint = 109.+++.+++.27:50003
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

curl ifconfig.me
109.+++.+++.24

Hätte ja nun 109.+++.+++.27 ergebebn müssen, WENN ich alles richtig gemacht habe.
Nur wo liegt denn nun mein Fehler?

P.s. die kryptische mask hab ich auch versucht... .ohne Lösung

PostUp   = iptables -t nat -A POSTROUTING -m mark --mark 0xCA6C/0xFFFFFFFF -j SNAT --to-source 109.+++.+++.27; iptables -A FORWARD -i VPN3 -j ACCEPT; iptables -t nat -A POSTROUTING -s 192.168.103.0/24 -o ens34:0 -j SNAT --to-source 109.+++.+++.27
PostDown = iptables -t nat -D POSTROUTING -m mark --mark 0xCA6C/0xFFFFFFFF -j SNAT --to-source 109.+++.+++.27; iptables -D FORWARD -i VPN3 -j ACCEPT; iptables -t nat -D POSTROUTING -s 192.168.103.0/24 -o ens34:0 -j SNAT --to-source 109.+++.+++.27
 

Nur die Quelladresse umzuschreiben geht nicht, es wird ja weiterhin die Main Routing-Tabelle genutzt und da ist nunmal nur ein Default-GW über ein Interface drin und das wird immer genutzt auch wenn du die SRC umschreibst, für sowas legt man i.d.R. separate Routing-Tabellen mit Routing Rules an.

Beispiel wenn man mehrere Interfaces nutzt und den Traffic über bestimmte Interfaces laufen lassen will:

/etc/iproute2/rt_tables 2 neue Routing-Tabellen am Ende hinzufügen

#...
#..
10 table-client1
20 table-client2

2 Routing-Rules hinzufügen (z.B. für zwei Clients die unterschiedliche ausgehende Ports/Adressen nutzen sollen, "from" kann natürlich auch Subnetze umfassen, ist ja nur ein Beispiel)

ip -4 rule add from 192.168.206.201/32 table table-client1
ip -4 rule add from 192.168.206.202/32 table table-client2

Default Routes den neuen Tabellen hinzufügen (Default GW-IP des Providers angeben und auf Interface achten)

ip -4 route add default via 109.+++.+++.1 dev ens32 table table-client1
ip -4 route add default via 109.+++.+++.1 dev ens33 table table-client2

Traffic auf ens32 und ens33 natürlich ausgehend masqueraden

iptables -t nat -A POSTROUTING -o ens32 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE

Done.

Klappt hier im Test einwandfrei.

Alternativ kannst du statt Quell-Subnetzen auch firewall marks nutzen die du im Wireguard-Setup setzt und dann in der Routing-Rule auswertest und damit entsprechend auf die separaten Routing-Tabellen mappst.

Aber wie auch von @aqui gesagt, ein Interface mit mehreren virtuellen IPs geht natürlich auch dann sparst du dir die Tabellen und schreibst nur die SRC um.

Gruß Katrin

Hi Katrin... vielen Dank. Ich konnte dir sogar (teilweise) folgen

Bei manchen muß ich mich aber nochmal einlesen.

ABER: greift leider nicht. Ich geh immer noch über die 109.+++.+++.24 raus.

Ich würde nochmal das ganze an ein Interface aufzeigen. VPN3
Ich hoffe dass ich einfach nur ein dummen Fehler drin hab.

ip -a auf den Wireguard-Server

4: ens35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:+++:cd brd ff:ff:ff:ff:ff:ff
    altname enp2s3
    inet 109.+++.+++.26/26 brd 109.+++.++.63 scope global ens35
       valid_lft forever preferred_lft forever
[..]
81: VPN3: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 192.168.103.103/24 scope global VPN3
       valid_lft forever preferred_lft forever

nano /etc/wireguard/VPN3.conf

[Interface]
Address = 192.168.103.103/24
SaveConfig = false
PostUp = iptables -A FORWARD -i VPN3 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens35 -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i VPN -j ACCEPT; iptables -t nat -D POSTROUTING -o ens35 -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT

ListenPort = 50003
PrivateKey = SO+++0Y=

[Peer]
PublicKey = ZR+++l8=
AllowedIPs = 192.168.203.0/24

interface: VPN3
  public key: lY+++Gk=
  private key: (hidden)
  listening port: 50003

peer: ZR+++l8=
  endpoint: 84.+++.+++.149:58517
  allowed ips: 192.168.203.0/24
  latest handshake: 1 minute, 22 seconds ago
  transfer: 3.06 MiB received, 155.85 MiB sent

CLIENT

nano /etc/wireguard/VPN3.conf

## Der Client. Public Key bei der Ausgabe von: cat /etc/wireguard/pubkey
[Interface]
PrivateKey = go+++Eo=
Address = 192.168.203.203/24
DNS = 1.1.1.1

## Der Server. Public Key ist der, wenn man die Schnittstelle startet und bei "interface: harvester3" schaut 
[Peer]
PublicKey = lY+++Gk=
Endpoint = 109.xxx.xxx.26:50003
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Das waren die bekannten Dinge. Dann jetzt nochmal sicherheitshalber dein Vorschlag aufgelistet für VPN3

30 table-client3

ip -4 rule add from 192.168.206.203/32 table table-client3
ip -4 route add default via 109.+++.+++.1 dev ens35 table table-client3
iptables -t nat -A POSTROUTING -o ens35 -j MASQUERADE

Auf dem Client zeigt "curl ifconfig.me" aber immer noch die 109.xxx.xxx.24
ens35 lautet aber 109.xxx.xxx.26

Jetzt bin ich mal gespannt, wo mein Fehler liegt

Deine IP Addressierung ist total für'n A...., stimmt alles nicht überein. Mal benutzt du 192.168.206.203 mal 192.168.203.203 und am Server 192.168.103.103/24 ????? 🙃

Alles vollkommen fremde Subnetze, bring da erst mal Ordnung rein und trink einen Kaffee ... ☕

Wie gesagt klappt out of the box hier im Test, wenn man denn auch die Brille aufsetzt

Bei manchen muß ich mich aber nochmal einlesen.

Dann tu das erst mal, hilft ungemein fürs Verständnis. Rumprobieren auf gut Glück ist meist nie gut.

Wie gesagt klappt out of the box hie rim Test

Hier übrigens auch! 😉

Zitat von @aqui:
Hier übrigens auch! 😉

Welcome to the club

soo... Zwischenmeldung.

Da ich gerstern so viel rumgespielt habe, hab ich mir vermutlich die Spielwiese zerschossen.
Also nochmal alles bei 0 begonnen. Was auch gut war, da nun alle Hinweise+Tipps hier einfließen konnten.

Fazit: Es läuft jetzt sogar mit der öffentlichen Portweiterleitung.
ABER: Nach der Holzhammermethode = sprich: VM 2x kopiert. 3 Spielwiesen laufen nun.
Unschön... aber geht erstmal für weitere Test.

Wenn weitere Tests aber passend laufen, würde ich das Problem nochmal angehen wollen, sodass WireGuard 3x Tunnel mit je einer sep. öffentlichen IP verwaltet.

Dazu würde ich jetzt vorab schon mal eine Frage an euch beiden Stellen:
RemoteHands per Teamviewer per Bezahlung. PP Freunde, Ama Gutschein, Ama Wunschliste, Telefonguthaben, etc.
Natürlich erstmal 1h pauschal vorab. Sprich: Erst das Geld und dann eure DL.

Config's sehen aktuell wie folgt aus:

SERVER

nano /etc/wireguard/wg0.conf

[Interface]
Address = 10.8.0.1/24
SaveConfig = true
PostUp = ufw route allow in on wg0 out on ens32
PostUp = iptables -t nat -I POSTROUTING -o ens32 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o ens32 -j MASQUERADE
PostUp = iptables -t nat -A PREROUTING -i ens32 -d 109.xxx.xxx.23 -p tcp --dport 1234 -j DNAT --to-destination 10.8.0.2:8444
PostUp = iptables -A FORWARD -i ens32 -p tcp --dport 1234 -d 10.8.0.2 -j ACCEPT
PreDown = ufw route delete allow in on wg0 out on ens32
PreDown = iptables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o ens32 -j MASQUERADE
ListenPort = 51820
PrivateKey = 0M+++++Uw=

[Peer]
PublicKey = FP+++++U8=
AllowedIPs = 10.8.0.0/24

CLIENT

nano /etc/wireguard/wg-client1.conf
[Interface]
Address = 10.8.0.2/24
DNS = 1.1.1.1
PrivateKey = gN+++++Gc=

[Peer]
PublicKey = Q/+++++BE=
AllowedIPs = 0.0.0.0/0
Endpoint = 109.+++.+++.23:51820
PersistentKeepalive = 25

Ich melde mich die Tage wieder. Mal schauen, ob ich morgen noch Zeit finde.
Ihr dürft mir aber gern mal einen Preis für 1h per PM nennen.. und: ob Ihr überhaupt Willig seid

Habt Dank