22.11.2020, aktualisiert um 03:37:29 Uhr

8825

Wireguard VPN mit 2x RaspberryPI LAN zu LAN

Hallo zusammen,

ich habe mich die letzten Tage mit der grundsätzlichen Funktion von Wireguard auseinander gesetzt und konnte das Zielnetzwerk über verbundene Clients erreichen und auf allen Geräten arbeiten. Dazu habe ich einen Wireguard Server mit einem Raspberry PI abgebildet.

Auf den Clients dann die entsprechende APP installiert und die PeerX.conf verteilt. Eben eine Config pro Client

Jetzt möchte ich jedoch ein anderes Szenario abbilden, und zwar möchte ich das Zielnetzwerk von mehreren Geräten aus einem gemeinsamen LAN erreichen über einen weiteren Raspberry PI. ... Siehe dazu mein Bild.

PC1 PC2 PC3 (nur als Beispiel), sollen am ende das NAS erreichen und die VPN des Lokalen Raspberry PI benutzen.

Nach meiner Vorstellung habe ich den Raspberry PI auf "meiner Seite" als Client eingerichtet und den auf der "Vater Seite" als Server. Ich dachte mit einer Statischen Route in meinem Router wär es getan, leider verwirft der Raspberry auf eth0 die Pakete:

PING 192.168.201.201 (192.168.201.201): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 4077   0 0000  3f  01 8be8 192.168.100.47  192.168.201.201

Im Edgerouter habe ich zum Test folgende Statische Routen hinterlegt:

Route type = gateway
Destination network = 192.168.201.0/24
Next hop address = 192.168.100.200
Route type = gateway
Destination network = 192.168.178.0/24
Next hop address = 192.168.100.200

Hier die Configs dazu:
Server Seite Vater Raspberry PI

[Interface]
Address = 192.168.201.200/24
ListenPort = 51820
PrivateKey = XXX

#replace eth0 with the interface open to the internet (e.g might be wlan0)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

#Client ICH
[Peer]
PublicKey = XXX
AllowedIPs = 192.168.201.201/32

Client Seite ICH Raspberry PI

[Interface]
Address = 192.168.201.201/32
DNS = 192.168.178.1
PrivateKey = XXX

#replace eth0 with the interface open to the internet (e.g might be wlan0)
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

#Server VATER
[Peer]
PublicKey = XXX
Endpoint = eine.ddnss.org:51820
AllowedIPs = 192.168.201.0/0, 192.168.178.0/24

Soweit so gut, von meinem RaspberryPI kann ich nun die gegen Seite erreichen und die gegen Seite mich.
Desweiteren kann ich das 192.168.178.0/24 von meinem Raspberry aus erreichen.

Bisher alles so wie es soll, jedoch erreiche ich von meinem 192.168.100.0/24 Netz weder das 192.168.201.0/24 Netz, noch das 192.168.178.0/24.

Ich habe das Gefühl, ich müsse noch irgendetwas in den iptables machen oder aber mir fehlt ein Teil (NAT?), damit der Raspberry auf meiner Seite nicht gleich alles verwirft...

Hat jemand Rat um am Ende die gegen Seite von allen Geräten aus zu erreichen?

root@danielraspi:~# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
bytes from 192.168.178.1: icmp_seq=1 ttl=63 time=32.0 ms
bytes from 192.168.178.1: icmp_seq=2 ttl=63 time=31.10 ms
bytes from 192.168.178.1: icmp_seq=3 ttl=63 time=31.7 ms
bytes from 192.168.178.1: icmp_seq=4 ttl=63 time=31.6 ms
bytes from 192.168.178.1: icmp_seq=5 ttl=63 time=32.0 ms

Daniels-MacBook-Pro:~ xxx$ traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 64 hops max, 52 byte packets
 1  192.168.100.1 (192.168.100.1)  1.411 ms  0.885 ms  1.087 ms
 2  192.168.100.200 (192.168.100.200)  1.375 ms  3.218 ms  1.443 ms
 3  * * *
 4  * * *

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

Content-ID: 624694

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

Ausgedruckt am: 22.11.2024 um 12:11 Uhr

24 Kommentare

Neuester Kommentar

Moin. Ohne Kaffee.
Hast Du das IP-Routing auf den Raspis aktiviert ?

Grüße Henere

Die iptable – auf "Serverseite" – ist mMn. korrekt. Meine hier funktioniert zumindest und sieht – before caffee – genauso aus.

a) Ich würde sie aber mal testhalber auf "Clientseite" deaktivieren. Die macht dort eh nur in einem Site2Site-Setup Sinn.

b) Das Fehlerbild kommt mir bekannt vor und klingt nach einem Fehler in den "Allowed-IPs" des Cients:

Bin ... immer noch ohne Kaffee ... wackelig, aber ich habe da nirgends 0/0 drin. Das klappte bei mir trotz diverser Tipp-Seiten nicht. Die "interne" VPN-NAT-Gegenstelle hat bei mir /32 und das dortige "Realnetzwerk" bekommt 0/24. Damit läufts hier seit Monaten dauerhaft stabil auch mit mehreren Clients. Du kannst aber natürlich auch erstmal nur die IP des NAS/32 nehmen.

Viel Erfolg!

ch habe das Gefühl, ich müsse noch irgendetwas in den iptables machen

Ja, du machst NAT im inneren Tunnel was natürlich völliger Quatsch ist. Daraus resultieren die ganzen Probleme denn damit ist kein transparentes Routing zwischen beiden Netzen möglich. Die gesamte Verwendung von iptables und damit auch NAT ist bei eigenen Netzen ja völlig überflüssig und auch kontraproduktiv. Vergiss den Unsinn also und lasse das weg. Wozu willst du NAT in deinen eigenen Netzen machen ? Sinnfrei...und schafft durch die Routing Einbahnstrasse nur Probleme.

Dein ganzes Site-to-Site VPN Konzept ist eigentlich völlig krank und solltest du nochmals überlegen. Wozu hast du denn potente VPN Router in beiden Netzen beschafft die problemlos ein Site-to-Site VPN abbilden können ?
Es ist doch völlig unsinnig dann diese Router nicht zu nutzen und das unsinnigerweise über einen RasPi in jedem Netz zu quälen. Den Sinn und die Logik dieses VPN Konzeptes versteht doch kein Mensch ??
Benutze deine 2 VPN Router um die VPN Netzwerk Kopplung zu machen und gut iss...

Danke euch schon mal für eure Tipps,

Ein Routing ist denke ich auf keinen der Raspberrys aktiv, was müsste ich dafür tun?

ggf hier auf der Server Seit:

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Auf der Client Seite habe ich den iptables Teil mal komplett deaktiviert und erreiche von PC1 immer noch nicht das "178er" Netz

Auf beiden Seiten ist übrigens "net.ipv4.ip_forward = 1" aktiv, weiß gerad nicht obs ne rolle spielt.

Ein Routing ist denke ich auf keinen der Raspberrys aktiv, was müsste ich dafür tun?

Einfach einmal Tutorials lesen !

weiß gerad nicht obs ne rolle spielt.

Nein, spielt natürlich keinerlei Rolle...dzzzz
Was bei OpenVPN gilt, gilt auch bei Wireguard:
Merkzettel: VPN Installation mit OpenVPN

Ändert aber nichts an 2 weiteren Kardinalsfehlern:

NAT im Tunnel ist Unsinn
Generell falsches VPN Konzept. Warum kauft man teure Router fürs Netz die man dann gar nicht Bestimmungs gemäß nutzt ? Aber egal....

Sinn oder unsinn überlass doch bitte mir!

Ich habe doch eine Frage gestellt, die jetzt wieder mit irgend einem OT Müll beantwortet werden muss.

Ich sehe du kennst dich sehr gut aus, aber warum musst du immer trollen, statt zu helfen?

OT ON:
Ich will die 2 Router nicht benutzen und die Router einfach Router sein lassen. Ich habe genügend Tests hinter mir. Der Speed der dinger ist einfach beschissen und ich schaffe nicht mehr wie 18 Mbit/s darüber, egal in welche Richtung, egal mit welchen Einstellungen (kann man sich so auch von anderen Usern bestätigen lassen)! Mit den Wireguard tests konnte ich OutOfTheBox mit mit nem Verbunden Client (über die APP) direkt 37Mbit/s von der Vater Seite holen und viel wichtiger, auf meiner FFTH Seite ging sofort mit 94Mbit die Post ab. Also lass mich doch bitte meine Grüde haben und poch nicht immer darauf rum die Router zu nehmen

Schnell mal was gelesen,

iptables -A FORWARD -i eth0 -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT

wäre das so auf der client Seite korrekt?

@aqui:

Das Thema VPN/NAT wird zwar immer beschimpft. Nur basieren alle(?) Wireguard-Anleitungen auf NATen. Zumindest die, die mir untergekommen sind - und das waren doch einige.

Für Dich ist das aber doch nen Klacks? Wir müsste denn so ein Wireguard(!)-Setup ohne NAT aussehen? Mich würde das wirklich in der Umsetzung interessieren. Nur hilft mir dabei keine Verlinkung auf die - sicherlich sehr ausgefeilte - OpenVPN-Anleitung

@danone:
Fürn Raspi gibts doch umfangreiche Anleitungen, teilweise sogar mit fertigen Scripts für Wirguard und PiHole, da ist das Routing schon fix und fertig. Ansonsten das hier prüfen: https://linuxize.com/post/how-to-set-up-wireguard-vpn-on-ubuntu-20-04/#s ...
Hier ggfs. noch den 51820 freigeben: https://www.heise.de/tipps-tricks/Ubuntu-Firewall-einrichten-4633959.htm ...

Ein einfaches TCPDUMP auf eth0 und TUN zeigt doch was passiert.

@Visucius
Ich bin ja auch nach den Anleitungen vorgegangen, kenne die zb selber. Jedoch wird immer nur beschrieben wie man einem Client (zb Windows 10 PC) mit seinem Wireguard verbindet und das Netz dahinter erreicht.

Das habe ich selber bei meinen anfänglichen Tests auch so umgesetzt und dabei die Geschwindigkeit geprüft gegenüber meiner OpenVPN Lösung.
Dies hat überzeugt und jetzt versuche ich Schritt für Schritt eine Site-to-Site Lösung umzusetzten mit Wireguard.

Was jedoch nie beschrieben wird ist, wenn man den Traffic aus seinem Lan in den Tunnel bekommen möchte.

Im Prinzip will ich mir die einzel Verbindungen der Clients ersparen und nur einen Tunnel zur Gegenseite Aufbauen.

@Henere
ich bin dran, kommt sofort (Danke für deine Hilfe)

ETH0

root@danielraspi:/etc/wireguard# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:40.591164 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 0, length 64
10:41.592300 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 1, length 64
10:42.597728 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 2, length 64
10:43.602891 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 3, length 64
10:44.607054 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 4, length 64
10:45.606996 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 5, length 64
10:46.608593 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 6, length 64
10:47.613766 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 7, length 64
10:48.618862 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 8, length 64
10:49.624211 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 9, length 64
10:50.627980 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 10, length 64
10:51.629313 IP 192.168.100.47 > 192.168.201.201: ICMP echo request, id 10262, seq 11, length 64

Ausgelöst von hier:

Daniels-MacBook-Pro:~ XXX$ ping 192.168.201.201
PING 192.168.201.201 (192.168.201.201): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 b757   0 0000  3f  01 1508 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 1
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 d76b   0 0000  3f  01 f4f3 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 2
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 70ae   0 0000  3f  01 5bb1 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 3
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 7d54   0 0000  3f  01 4f0b 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 4
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 57c6   0 0000  3f  01 7499 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 2287   0 0000  3f  01 a9d8 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 eb8c   0 0000  3f  01 e0d2 192.168.100.47  192.168.201.201 

Request timeout for icmp_seq 10
^C
--- 192.168.201.201 ping statistics ---
12 packets transmitted, 0 packets received, 100.0% packet loss

Richtung 192.168.178.1

13:46.621079 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 0, length 64
13:47.621790 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 1, length 64
13:48.626273 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 2, length 64
13:49.628141 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 3, length 64
13:50.628247 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 4, length 64
13:51.627661 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 5, length 64
13:52.629138 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 14358, seq 6, length 64

Daniels-MacBook-Pro:~ XXX$ ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1): 56 data bytes
Request timeout for icmp_seq 0
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 50a7   0 0000  3f  01 9380 192.168.100.47  192.168.178.1 

Request timeout for icmp_seq 1
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 dadf   0 0000  3f  01 0948 192.168.100.47  192.168.178.1 

Request timeout for icmp_seq 2
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 cb5a   0 0000  3f  01 18cd 192.168.100.47  192.168.178.1 

Request timeout for icmp_seq 3
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f40d   0 0000  3f  01 f019 192.168.100.47  192.168.178.1 

Request timeout for icmp_seq 4
92 bytes from 192.168.100.1: Redirect Host(New addr: 192.168.100.200)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 3642   0 0000  3f  01 ade5 192.168.100.47  192.168.178.1 

Request timeout for icmp_seq 5
^C
--- 192.168.178.1 ping statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss

WG0

root@danielraspi:/etc/wireguard# tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
17:06.318975 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 0, length 64
17:07.324398 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 1, length 64
17:08.329496 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 2, length 64
17:09.331317 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 3, length 64
17:10.331017 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 4, length 64
17:11.335467 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 5, length 64
17:12.338957 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 19222, seq 6, length 64

Ok, wer lesen kann ist klar im Vorteil ... soll ja doch ein Site-to-Site sein und das Problem tritt "diesseits" auf. Und ich sach noch "before coffee" ;---)

Die hier haste bestimmt schon gesehen? https://quacktacular.net/2020/04/24/site-to-site-vpn-with-wireguard-and- ...

Ich selber habe ein Site2Site mit einer "windows-Seite" leider selber nicht zu laufen gebracht. Trotz aktivem Routing. Habe dann das Setup variiert.

Auf der Gegenseite kommt weder auf eth0 noch auf wg0 in tcpdump etwas an, ausgelöst aus meinem 100er Netz

Hier ein ICMP von meinem Raspberry Richtung gegen Seite:

root@danielraspi:~# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
64 bytes from 192.168.178.1: icmp_seq=1 ttl=63 time=41.5 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=63 time=45.7 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=63 time=48.7 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=63 time=36.3 ms
^C
--- 192.168.178.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 36.296/43.056/48.735/4.671 ms

ETH0:

root@horstraspi:~# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
29:01.798161 IP 192.168.178.200 > 192.168.178.1: ICMP echo request, id 1909, seq 1, length 64
29:01.798695 IP 192.168.178.1 > 192.168.178.200: ICMP echo reply, id 1909, seq 1, length 64
29:02.806405 IP 192.168.178.200 > 192.168.178.1: ICMP echo request, id 1909, seq 2, length 64
29:02.806994 IP 192.168.178.1 > 192.168.178.200: ICMP echo reply, id 1909, seq 2, length 64
29:03.810798 IP 192.168.178.200 > 192.168.178.1: ICMP echo request, id 1909, seq 3, length 64
29:03.811320 IP 192.168.178.1 > 192.168.178.200: ICMP echo reply, id 1909, seq 3, length 64
29:04.799912 IP 192.168.178.200 > 192.168.178.1: ICMP echo request, id 1909, seq 4, length 64
29:04.800618 IP 192.168.178.1 > 192.168.178.200: ICMP echo reply, id 1909, seq 4, length 64

WG0:

root@horstraspi:~# tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
30:50.344966 IP 192.168.201.201 > 192.168.178.1: ICMP echo request, id 9633, seq 1, length 64
30:50.345663 IP 192.168.178.1 > 192.168.201.201: ICMP echo reply, id 9633, seq 1, length 64
30:51.355462 IP 192.168.201.201 > 192.168.178.1: ICMP echo request, id 9633, seq 2, length 64
30:51.356052 IP 192.168.178.1 > 192.168.201.201: ICMP echo reply, id 9633, seq 2, length 64
30:52.351117 IP 192.168.201.201 > 192.168.178.1: ICMP echo request, id 9633, seq 3, length 64
30:52.351769 IP 192.168.178.1 > 192.168.201.201: ICMP echo reply, id 9633, seq 3, length 64
30:53.357590 IP 192.168.201.201 > 192.168.178.1: ICMP echo request, id 9633, seq 4, length 64
30:53.358249 IP 192.168.178.1 > 192.168.201.201: ICMP echo reply, id 9633, seq 4, length 64
30:54.346547 IP 192.168.201.201 > 192.168.178.1: ICMP echo request, id 9633, seq 5, length 64
30:54.347120 IP 192.168.178.1 > 192.168.201.201: ICMP echo reply, id 9633, seq 5, length 64

Zitat von @Visucius:

Ok, wer lesen kann ist klar im Vorteil ... soll ja doch ein Site-to-Site sein und das Problem tritt "diesseits" auf. Und ich sach noch "before coffee" ;---)

Die hier haste bestimmt schon gesehen? https://quacktacular.net/2020/04/24/site-to-site-vpn-with-wireguard-and- ...

Ich selber habe ein Site2Site mit einer "windows-Seite" leider selber nicht zu laufen gebracht. Trotz aktivem Routing. Habe dann das Setup variiert.

Habs gerade mal angesehen, im Prinzip alles ähnlich wie bei mir.
""After the image is pulled and container started, you should be able to ping between the peers on the private and WireGuard IP address.""

Das funktioniert bei mir ja auch eben vom Raspberry selber, auch hier wird wieder nichts dazu geschrieben wie es man es machen muss um aus dem "Client Netz" die Gegenseite über den Tunnel zu erreichen.

Er schreibt auch, dass ein Routing notwendig ist aber geht da nicht weiter drauf ein.

Wie gesagt eine Route ins 178er Netz zum Raspi, habe ich meinem Router aktiv.

Wenn ich tcpdump richtig lese, leitet mein Raspi tatsächlich 178er Anfragen in den Tunnel, aber anscheint kennt wg0 keine Route Richtung 178

@danone:
die beiden anderen LINKs (Routing aktivieren in /etc/sysctl.conf) und evtl. die Portfreigabe am Raspi hast Du auch geprüft?

Inhalt sysctl.conf:

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438

Wo genau die müsste ich die Route aktivieren?

Was meinst du mit Portfreigabe, ich erreiche doch den Raspi auf der Gegenseite der Rest ist doch dann im LAN?

Zeile 27/28. Ist aber schon aktiv.

Neustart haste mal gemacht? Manche Einstellungen werden nicht automatisch übernommen.

Ich würde - in der Not - mal testen ob auf dem Client Raspi ne Firewall aktiv ist?! Du willst ja vom lokalen Netzwerk auf den (lokalen) Client-Raspi udn irgendwo dazwischen steht was im Weg?! Ich mache das hiemit:
https://www.heise.de/tipps-tricks/Ubuntu-Firewall-einrichten-4633959.htm ...

Ist aber - zugegebener Maßen - ein stochern im Nebel. Genauso, wie ich irgendwelche ipv6-Unterstützungen in den Routern deaktivieren würde.

eine Firewall ist nirgends dazwischen, wieso auch? außer es versteckt sich eine im OS: https://www.raspberrypi.org/software/

IPv6 spielt hier keine Rolle, denn es geht hier ja ausschließlich um ipv4 ...ich muss es nochmal erwähnen: im LAN

Der Tunnel wird ja aufgebaut, es kommt eine Verbindung zustande.

Der Raspberry Client kann die Geräte im Zielnetzwerk erreichen, so wie es sein soll.

Nebenan stehende Geräte wie PC1, 2, 3 können keine Verbindung zum Ziel Netzwerk erhalten, obwohl eine Route dafür im lokalen Router 192.168.100.1 hinterlegt ist (welcher für alle Geräte das Gateway ist).

Es steht theoretisch nichts im weg.

Wenn ich ein ICMP verfolge, geht dies bis zum eigenen WG0 Interface, kommt aber nie auf der Gegenseite an... Also muss nach meiner Auffassung irgendetwas auf meiner Seite konfiguriert werden damit es geht.

Schade, werde dann wohl doch auf "einzel Verbindungen" zurückgreifen müssen...

Hi,
setze mal auf dem <Daniels-MacBook-Pro> die statische Route zu 192.168.178.0/24 über das Gateway 192.168.100.200, also ohne den Umweg über den Edge Router.
Kannst du dann auf das NAS zugreifen ?

CH

Hi,
gerade folgendes auf dem Macbook probiert:

Daniels-MacBook-Pro:~ xxx$ sudo route -n add 192.168.178.0/24 192.168.100.200

Als Gateway im W-Lan Adapter, zusätzlich die "192.168.100.200" damit es ja da ankommt.

Erstmal geschaut ob die Verbindung noch steht:

root@danielraspi:~# wg
interface: wg0
  public key: xxx
  private key: (hidden)
  listening port: 42255

peer: xxx
  endpoint: 79.204.xxx.xxx:51821
  allowed ips: 192.168.201.0/24, 192.168.178.0/24
  latest handshake: 1 minute, 6 seconds ago
  transfer: 118.72 KiB received, 931.39 KiB sent
root@danielraspi:~# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
64 bytes from 192.168.178.1: icmp_seq=1 ttl=63 time=22.10 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=63 time=21.8 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=63 time=21.10 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=63 time=21.6 ms
^C
--- 192.168.178.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 21.620/22.087/22.957/0.548 ms
root@danielraspi:~#

Jetzt ein ICMP los geschickt von <Daniels-MacBook-Pro>

Daniels-MacBook-Pro:~ xxx$ ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- 192.168.178.1 ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss

Parallel "tcpdump" auf "danielraspi" & "horstraspi":

ETH0 danielraspi:

root@danielraspi:~# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:52:12.388916 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 30754, seq 0, length 64
22:52:13.394111 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 30754, seq 1, length 64
22:52:14.395601 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 30754, seq 2, length 64
22:52:15.395216 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 30754, seq 3, length 64
22:52:16.396924 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 30754, seq 4, length 64
22:52:17.398426 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 30754, seq 5, length 64

WG0 danielraspi:

root@danielraspi:~# tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
22:53:40.186393 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 32034, seq 0, length 64
22:53:41.191106 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 32034, seq 1, length 64
22:53:42.195280 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 32034, seq 2, length 64
22:53:43.197560 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 32034, seq 3, length 64
22:53:44.202794 IP 192.168.100.47 > 192.168.178.1: ICMP echo request, id 32034, seq 4, length 64

WG0 horstraspi:

root@horstraspi:~# tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@horstraspi:~# 

ETH0 horstraspi:

root@horstraspi:~# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@horstraspi:~# 

Wo bleiben die Pakete?

Der Fehler lag in der Wireguard config... *auweia*

Mit folgenden Configs funktioniert es nun

danielraspi (Client):

[Interface]
Address = 192.168.201.201/24
#DNS = 192.168.178.1
PrivateKey = xxx

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j $
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -$

[Peer]
PublicKey = xxx
Endpoint = xxx.ddnss.org:51821
AllowedIPs =192.0.0.0/8,192.168.201.0/24,192.168.178.0/24

horstraspi (Server):

[Interface]
Address = 192.168.201.200/24
ListenPort = 51821
PrivateKey = xxx

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING $
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTIN$

[Peer]
PublicKey = xxx
AllowedIPs = 192.168.0.0/8,192.168.201.0/24,192.168.100.0/24

Natürlich noch die statischen Routen in den beiden Routern hinterlegen und alles läuft wie gewünscht

Danke für eure Anteilnahme

LG danone

Zunächst mal Glückwunsch, dass es geht. Hm, was war es denn jetzt genau?

So wie ich das sehe, hast Du die schon von mir im 2. Post kritisierten "Allowed IPs" modifiziert. Darüber hinaus hast Du jetzt andere "IP-Table-Befehle".

Aber auf beiden Seiten der VPN unterschiedliche. Kann das sein bei Site2Site?

Dein Fehler : 192.168.201.0/0 allowed IP in der Original-Config. Da gent natuerlich nix durch. Schade das ich hier nicht frueher war.

VG

Sato

Zitat von @satosan:

Dein Fehler : 192.168.201.0/0 allowed IP in der Original-Config. Da gent natuerlich nix durch. Schade das ich hier nicht frueher war.

VG

Sato

Ich zitiere mal aus meinem Post von Sonntag 7.38 Uhr:

"b) Das Fehlerbild kommt mir bekannt vor und klingt nach einem Fehler in den "Allowed-IPs" des Cients:

Bin ... immer noch ohne Kaffee ... wackelig, aber ich habe da nirgends 0/0 drin. Das klappte bei mir trotz diverser Tipp-Seiten nicht. Die "interne" VPN-NAT-Gegenstelle hat bei mir /32 und das dortige "Realnetzwerk" bekommt 0/24. Damit läufts hier seit Monaten dauerhaft stabil auch mit mehreren Clients. Du kannst aber natürlich auch erstmal nur die IP des NAS/32 nehmen."

Hätte also auch nix gebracht, wärst Du vorher da gewesen

gelöst Frage Netzwerke Router, Routing

Mehr von danone

OpenVPN Speed Probleme - Grundsatz Fragedanone - 4 Kommentare

L2TP over IPsec nur über IPv6danone

Heiß diskutiert