Wireguard Server zwischen zwei Netzen - keine Kommunikation S2S

Tom8184 · 13. August 2025 um 18:28

Derzeit komme ich aus dem Heimnetz unter der 10.252.1.3 auf das Web Interface des Wohnwagen Router, aber eben nur unter der Tunnel IP. Wäre das noch normal oder müsste ich ihn auch unter der 192.168.5er IP ansprechen können?

Ein Ping auf die 192.168.5.9 sieht so aus
PING 192.168.5.9 (192.168.5.9): 56 data bytes
92 bytes from 10.252.1.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 545d 0 0000 01 01 939d 10.252.1.2 192.168.5.9

92 bytes from 10.252.1.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 c4fc 0 0000 01 01 22fe 10.252.1.2 192.168.5.9

92 bytes from 10.252.1.2: Time to live exceeded
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 fee2 0 0000 01 01 e917 10.252.1.2 192.168.5.9

— 192.168.5.9 ping statistics —
3 packets transmitted, 0 packets received, 100.0% packet loss

m-electronics · 13. August 2025 um 19:34

Irgendwie muss da was mit den Routen falsch sein auf dem WG-Server. In welchem Peer hast du denn welche Route eingetragen?
Nicht, dass du das jetzt genau vertauscht hast (passiert vielen Leuten)
(Bitte nochmal die aktuelle Config des WG-Server)

Tom8184 · 13. August 2025 um 19:44

Danke für deine Geduld. Aktuell vom Server kopiert

interface: wg0
listening port: 51820

peer: pfSense (im 192.168.0er Netz)
endpoint: IP:51280
allowed ips: 10.252.1.2/32, 192.168.5.0/24
latest handshake: 1 minute ago
transfer: 2.91 MiB received, 13.36 MiB sent
persistent keepalive: every 15 seconds

peer: Wohnwagen (192.168.5er Netz)
endpoint: IP:60551
allowed ips: 10.252.1.3/32, 192.168.0.0/24
latest handshake: 1 minute, 8 seconds ago
transfer: 26.06 MiB received, 31.91 MiB sent
persistent keepalive: every 15 seconds

m-electronics · 13. August 2025 um 19:59

Wusste ich es doch
Wie die meisten, du hast wohl noch nicht das Verständnis von den AllowedIPs, was das bedeutet…Mehr dazu gerne morgen Abend…

Tom8184 · 14. August 2025 um 11:52

Verstehe ich wirklich nicht, in allen Anleitungen steht immer drin, unter Allowed IPs muss das entfrente Netz das man erreichen will drin stehen.

Ziitat: “You use the AllowedIPs setting of WireGuard to configure which blocks of IP addresses should be routed through which remote WireGuard peers. If you want to access just a single block of IP addresses through a WireGuard peer, like say a block of IP addresses at a remote site that range from 192.168.100.0 to 192.168.100.255, you’d set the AllowedIPs for it to the following: AllowedIPs = 192.168.100.0/24”

Oder sind die Peers anders herum zu lesen, aber die WG Server Konfiguration für den Client pfSense trage ich doch auch in der pfSense ein. Was verstehe ich falsch?

Ich habe jetzt ein Experiment gemacht, habe den Client meines Handy überarbeitet, nur noch Allowed IPs 0.0.0.0/0 also alles durch den Tunnel. Traceroute auf 10.252.1.1-3 funktionieren einwandfrei. Traceroute auf www.google.de geht über den 10.252.1.1 und ist nach 18 Hops am Ziel. Aber weder Traceroute 192.168.0.x noch 192.168.5.x funktionieren. Bleiben sofort am Server 10.252.1.1 hängen.

Einigermaßen logisch, auch im Firefox, Internet und die 10.252.1er IPs gehen, die 192.168er Netze beide nicht.

Auf meinem PC im 192.168.0er Netz gibt es folgendes Ergebnis:
PS C:\Users\Thomas> tracert 10.252.1.3
Routenverfolgung zu 10.252.1.3 über maximal 30 Hops
1 10 ms 6 ms 4 ms fritz.box [192.168.0.200]
2 9 ms 6 ms 4 ms pfSense-Bridge.fritz.box [192.168.0.254]
3 25 ms 20 ms 20 ms 10.252.1.1
4 38 ms 37 ms 38 ms 10.252.1.3
Ablaufverfolgung beendet.

PS C:\Users\Thomas> tracert 192.168.5.200
Routenverfolgung zu 192.168.5.200 über maximal 30 Hops
1 12 ms * 9 ms fritz.box [192.168.0.200]
2 4 ms 6 ms 4 ms pfSense-Bridge.fritz.box [192.168.0.254]
3 21 ms 21 ms 19 ms 10.252.1.1
4 * * * Zeitüberschreitung der Anforderung.

Damit weiß das 192.168.0er Netz doch eigentlich wo es lang geht zum 192.168.5er Netz.

Können / müssen auf dem Server 10.252.1.1 zusätzliche Gateways angelegt werden und diese entsprechenden Routen zugewiesen werden?
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 02:01:86:0d:e0:ec brd ff:ff:ff:ff:ff:ff
altname enp0s6
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none

wg0 state UNKNOWN, ist das normal und richtig?

m-electronics · 14. August 2025 um 15:23

Du musst anders denken.
Die AllowedIPs der Peers auf dem Server sagen dem Server wohin er dieses Netz schicken muss (über welchen Peer er gehen muss). Wenn du so denkst, würdest du ja nicht das 192.168.5.0/24 zur pfSense schicken oder? Weil dort ist dieses Netz ja nicht?

m-electronics · 14. August 2025 um 15:24

Und kannst du bitte code-formatierung verwenden? Das ist ziemlich nervig zu lesen so, was Konsolenausgabe ist und was nicht?

Tom8184 · 14. August 2025 um 15:50

Hallo,
ok, das ist schwierig zu verstehen. Mein Handy hat als direkter WG Client aber doch allowed 0.0.0.0/0, damit sollte doch jegliche IP über den Tunnel zu erreichen sein oder verstehe ich das auch falsch? Warum gehen Ping oder Traceroute nur auf die 10.252.1er Tunnel IPs oder Internet Adressen?

Das ändert sich auch nicht wenn ich temporär die Firewall auf dem Strato Server deaktiviere.

m-electronics · 14. August 2025 um 15:54

Nein, da ist es ja auch aus Sicht des Handys. Was soll das Handy durch den Tunnel erreichen. Auf dem Server musst du dann ja aus Sicht des Servers schauen.

Tom8184 · 14. August 2025 um 16:04

Mit dem Handy habe ich versucht die Web-Interface der beiden Router 192.168.0.xxx oder 192.168.5.xxx aufzurufen. Geht genauso wenig wie ein Ping in die 192.168er Netze.

Da Ping und Traceroute jeweils beim Server 10.252.1.1 hängen bleiben liegt das Problem für mein Verständnis beim Server. Der scheint mit den 192.168er IPs nichts anfangen zu können. Ich habe etwas von asynchronem Routing gelesen, kann das ein Problem sein und die Antworten kommen einfach nicht zum Handy zurück?

Dann müsste aber doch auf der Server Konsole ein Ping in die 192.168er Netze funktionieren was es nicht tut.

m-electronics · 14. August 2025 um 16:21

Nein, hast du denn die Config auf dem Server mal geändert?

Tom8184 · 14. August 2025 um 18:21

Hallo,
beim ändern der Konfiguration des Clients habe ich irgendwelchen Mist gebaut, der WG Server startet nicht mehr. Muss ihn erst einmal wieder zum Laufen bringen, dann lege ich neue Konfigurationen für den Wohnwagen an, einmal mit Allowed 192.168.0er und einmal mit 192.168.5er IPs.

Bis hiehin noch einmal Danke

m-electronics · 14. August 2025 um 18:37

Denke mal vorher bitte nach: Wo ist von Server-Seite aus welches Netz zu erreichen? Dann jeweils in die entsprechenden Allowed-IPs dieses Peers eintragen.

Tom8184 · 14. August 2025 um 20:47

Hallo,
ich habe für den Wohnwagen nun 2 Konfigurationen angelegt, einmal Router die 10.252.1.11 mit Allowed 192.168.0.x und einmal Router 10.252.1.12 mit 192.168.5.x. Leider aus Sicht des 192.168.5er Netz kein Unterschied zwischen beiden Konfigurationen.

Router 10.252.1.11 - Allowed IPs 192.168.0.0/24:

tracert 192.168.0.254
Routenverfolgung zu 192.168.0.254 über maximal 30 Hops
    1     2 ms     1 ms     1 ms  192.168.5.200
    2    41 ms    30 ms     *     10.252.1.1
    3    34 ms    24 ms    43 ms  169.254.0.254
    4     *        *        *     Zeitüberschreitung der Anforderung.
    5

Router 10.252.1.12 - Allowed IPs 192.168.5.0/24:

tracert 192.168.0.254
Routenverfolgung zu 192.168.0.254 über maximal 30 Hops
    1     4 ms     3 ms     3 ms  192.168.5.200
    2    37 ms    29 ms    41 ms  10.252.1.1
    3    29 ms    35 ms    36 ms  169.254.0.254
    4     *        *        *     Zeitüberschreitung der Anforderung.
    5

Der Server findet in beiden Fällen keinen Weg zur pfSense 192.168.0.254. Auf deren WG Interface ist eine Firewall Regel die alles zulässt, kann also nicht blocken.

Ich denke es liegt am WG Server, dort fehlt irgendetwas. Die Client Konfiguration alleine hilft nicht weiter.

m-electronics · 15. August 2025 um 04:11

Kannst du mal ein Bild zeichnen? (https://draw.io), der Traceroute ergibt in meinem Kopf keinen Sinn. Hat der GL-iNet die .200 im 5er Netz?! Oder wie?

Aber die Config auf dem Server für den GL-iNet mit 192.168.0.0/24 ist auf jeden Fall falsch! Also die ganz schnell löschen😅

Tom8184 · 15. August 2025 um 15:31

Hallo,

ja der GLinet im Wohnwagen hat die .200 im 5er Netz.

Hier noch einmal das Bild ganz vom Anfang diese Threads.
Vom 5er Netz soll alles durch den Tunnel, vom 0er Netz Zuhause soll nur das 5er Netz durch den Tunnel erreicht werden.

Ich habe die Client Konfigurationen noch einmal komplett neu gemacht. Der 5er Router im Wohnwagen hat Allowed IPs das 5er Netz und die pfSense im 0er hat Allowed IPs das 0er Netz.

Leider bringt das aber immer noch keine Änderung. Über den Tunnel sind die Router jeweils unter der Tunnel IP zu erreichen aber keiner unter seiner lokalen IP und auch nichts dahinter.

Für mein Laien-Verständnis fehlt das etwas auf dem WG Server. Ping und Traceroute bleiben da ja auch hängen. Oder die entsprechenden Antworten finden nicht den richtigen Weg zurück, Stichwort asynchrones Routing.

m-electronics · 15. August 2025 um 15:46

Ne, nix asynchrones Routing. Verstehe ich dich richtig? Du hast im Peer für den Wohnwagen als AllowedIPs: 10.252.1.3/32, 192.168.5.0/24 und im Peer für die pfSense: 10.252.1.2/32, 192.168.0.0/24 ?

Tom8184 · 15. August 2025 um 19:21

Hallo,

ja, genau so hatte ich dich verstanden.

Auf dem WG Server gibt es folgende Routen, nix für die 192.168er Netze

ip r
default via 87.106.xxx.x dev ens6 proto dhcp src 87.106.xxx.xxx metric 100 
10.252.1.0/24 dev wg0 proto kernel scope link src 10.252.1.1 
87.106.xxx.x dev ens6 proto dhcp scope link src 87.106.xxx.xxx metric 100 
prohibit 169.254.169.254 
212.227.123.16 via 87.106.xxx.x dev ens6 proto dhcp src 87.106.xxx.xxx metric 100 
212.227.123.17 via 87.106.xxx.x dev ens6 proto dhcp src 87.106.xxx.xxx metric 100

m-electronics · 15. August 2025 um 19:46

Warum gibt es keine Routen? Dann gibt es auch keine passenden AllowedIPs…

Tom8184 · 15. August 2025 um 20:21

Also vielleicht liegt das an Wireguard-UI, diese speichert die Konfigurationen nicht in der wg0.conf sondern in .json Dateien unter /etc/wireguard/db/clients.

Im Web Interface sehen die Clients so aus (Fridolin = Wohnwagen):

In der .json:

{
        "id": "cpccjce2dv3c3bve7q30",
        "private_key": "",
        "public_key": "xxxxx",
        "preshared_key": "xxxxx",
        "name": "pfSense",
        "telegram_userid": "",
        "email": "",
        "allocated_ips": [
                "10.252.1.2/32"
        ],
        "allowed_ips": [
                "192.168.0.0/24",
                "10.252.1.0/24"
        ],
        "extra_allowed_ips": [],
        "endpoint": "",
        "use_server_dns": true,
        "enabled": true,
        "created_at": "2024-05-30T18:47:13.245916156Z",
        "updated_at": "2025-08-15T11:22:02.163772604Z"
}

{
        "id": "d2f3qk62dv3d05rn03k0",
        "private_key": "xxxxx",
        "public_key": "xxxxx",
        "preshared_key": "xxxxx",
        "name": "Fridolin",
        "telegram_userid": "",
        "email": "",
        "allocated_ips": [
                "10.252.1.3/32"
        ],
        "allowed_ips": [
                "192.168.5.0/24",
                "10.252.1.0/24"
        ],
        "extra_allowed_ips": [],
        "endpoint": "",
        "use_server_dns": true,
        "enabled": true,
        "created_at": "2025-08-14T19:47:28.082652712Z",
        "updated_at": "2025-08-15T08:43:49.667845074Z"
}

Wie müsste denn die Route / Routen aussehen?