Bei WireGuard (PiVPN) NAT deaktivieren

rpi444 · September 4, 2024 at 9:09 PM New

Code

root@raspberrypi:# sudo arping -c 3 -I enxb827eb79298d 192.168.115.200
ARPING 192.168.115.200 from 192.168.115.135 enxb827eb79298d
Unicast reply from 192.168.115.200 [00:15:5D:73:B4:C1]  1.318ms
Unicast reply from 192.168.115.200 [00:15:5D:73:B4:C1]  1.047ms
Unicast reply from 192.168.115.200 [00:15:5D:73:B4:C1]  1.395ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

BTW: Wenn Du schon als root angemeldet bist, warum benutzt Du dann auch noch sudo?

Wenn der arping (arp) funktioniert, sollte der ping (icmp) auch funktionieren. Wie ist die Ausgabe von:

Code

ping -c 3 192.168.115.200

?

Bot · Vor 5 Minuten

Bei WireGuard (PiVPN) NAT deaktivieren? Schau mal ob du hier fündig wirst!

jojohannes · September 5, 2024 at 9:31 AM New

Quote from rpi444

BTW: Wenn Du schon als root angemeldet bist, warum benutzt Du dann auch noch sudo?

weil ich die commands einfach kopiert habe, spielt das eine Rolle?

Quote from rpi444

Wenn der arping (arp) funktioniert, sollte der ping (icmp) auch funktionieren. Wie ist die Ausgabe von:

Wie gehabt

Code

PING 192.168.115.200 (192.168.115.200) 56(84) bytes of data.
From 10.199.89.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig
From 10.199.89.1 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig
From 10.199.89.1 icmp_seq=3 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig
192.168.115.200 ping statistics ---

Wenn ich arping ohne interface ausführe, will er über wg0 pingen, ist da vllt der Hund begraben?

Code

arping -c3 192.168.115.200
Interface "wg0" is not ARPable (no ll adress)

rpi444 · September 5, 2024 at 9:44 AM New

Quote from jojohannes

Wenn ich arping ohne interface ausführe, will er über wg0 pingen, ist da vllt der Hund begraben?

Dann mach den Ping mit der source-IP des PI:

Code

ping -c 3 -I 192.168.115.135 192.168.115.200

Bot · Vor einem Moment

jojohannes · September 5, 2024 at 9:50 AM New

Quote from rpi444
Dann mach den Ping mit der source-IP des PI:
Code
ping -c 3 -I 192.168.115.135 192.168.115.200

Geht auch nicht:

Code

PING 192.168.115.200 (192.168.115.200) 56(84) bytes of data.
From 192.168.115.135 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig
From 192.168.115.135 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig
From 192.168.115.135 icmp_seq=3 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig

rpi444 · September 5, 2024 at 10:11 AM New

Quote from jojohannes

Geht auch nicht:

Code

PING 192.168.115.200 (192.168.115.200) 56(84) bytes of data.
From 192.168.115.135 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Es ist eine Zieladresse notwendig

Kannst Du auch dem Gerät mit der IP .200 (Server?) tcpdump starten? ... mit:

Code

sudo tcpdump -c 30 -vvveni <input-Interface> host 192.168.115.135 and icmp

(input-Interface anpassen und ohne spitze Klammern) um zu sehen ob der Ping vom PI, dort ankommt.

jojohannes · September 5, 2024 at 10:34 AM New

Quote from rpi444

(input-Interface anpassen und ohne spitze Klammern) um zu sehen ob der Ping vom PI, dort ankommt.

Habe ich gemacht, da kommt nichts an.

Wenn ich das richtig verstehe verschickt wireguard alles was in AllowedIps steht über den Tunnel, was für mich erklären würde, warum er dann nicht mehr dieses Netz erreichen kann, oder?

Bot · Vor einem Moment

rpi444 · September 5, 2024 at 10:43 AM New

Quote from jojohannes

Quote from rpi444

(input-Interface anpassen und ohne spitze Klammern) um zu sehen ob der Ping vom PI, dort ankommt.

Habe ich gemacht, da kommt nichts an.
Wenn ich das richtig verstehe verschickt wireguard alles was in AllowedIps steht über den Tunnel, was für mich erklären würde, warum er dann nicht mehr dieses Netz erreichen kann, oder?

Naja, nicht Alles, denn der arping kommt ja an. Versuch mal mit:

Code

sudo tcpdump -c 30 -vvveni <input-Interface> host 192.168.115.135 and arp

auf dem Server und mit dem arping vom PI.
Poste vom PI auch die Ausgaben von:

Code

ip r g 192.168.115.200
ip r

EDIT:

WireGuard gibt es für (fast) alle Betriebssysteme. D. h. jedes Gerät kann als WireGuard-peer konfiguriert und benutzt werden. Warum musst Du einen WireGuard-peer als gateway für den Zugang zu anderen Subnetzen, benutzen?

jojohannes · September 5, 2024 at 11:47 AM New

Quote from rpi444

auf dem Server und mit dem arping vom PI.

Arping läuft wie gehabt durch, tcpdump zeigt mit dem o.g. befehl aber nichts an.

Quote from rpi444

root@raspberrypi:# ip r g 192.168.115.200
192.168.115.200 dev wg0 src 10.199.89.1 uid 0
cache
root@raspberrypi:# ip r
default via 192.168.115.46 dev enxb827eb79298d proto static metric 100
10.199.89.0/24 dev wg0 proto kernel scope link src 10.199.89.1
192.168.115.0/24 dev wg0 scope link
192.168.115.0/24 dev enxb827eb79298d proto kernel scope link src 192.168.115.135 metric 100

Quote from rpi444

WireGuard gibt es für (fast) alle Betriebsysteme. D. h. jedes Gerät kann als WireGuard-peer konfiguriert und benutzt werden.

Wie meinst du das? Dass ich für jeden Dienst (Server) einen extra Tunnel anlege? Das wäre für mich keine Option.

Quote from rpi444

Warum musst Du einen WireGuard-peer als gateway für den Zugang zu anderen Subnetzen, benutzen?

IPsec-PSK vom Lancom funktioniert nach Android-Updates nicht mehr und ist auch nicht so schön zu verwalten, wie PiVPN, deswegen wollte ich das damit ablösen.

Lancom (LCOS) selbst unterstützt kein wireguard.

rpi444 · September 5, 2024 at 11:58 AM New

Quote from jojohannes

Quote from rpi444

auf dem Server und mit dem arping vom PI.

Arping läuft wie gehabt durch, tcpdump zeigt mit dem o.g. befehl aber nichts an.

Zeige mal wie Du tcpdump auf dem Server benutzt hast.

Quote from jojohannes

Quote from rpi444

auf dem Server und mit dem arping vom PI.

Arping läuft wie gehabt durch, tcpdump zeigt mit dem o.g. befehl aber nichts an.

Quote from rpi444

root@raspberrypi:# ip r
default via 192.168.115.46 dev enxb827eb79298d proto static metric 100
10.199.89.0/24 dev wg0 proto kernel scope link src 10.199.89.1
192.168.115.0/24 dev wg0 scope link
192.168.115.0/24 dev enxb827eb79298d proto kernel scope link src 192.168.115.135 metric 100

Konfiguriere die definierte Route in das 102.168.115.0/24-er Subnetz via wg0-Interface. mit einer ungünstigeren/schlechteren metric als 100 (z. B. 200).
Wenn Du im Router eine statische Route konfiguriert hast, dann diese für die Tests deaktivieren. Kann es evtl. sein, dass dein Router die icmp-Pings filtert/blockt?
BTW: WireGuard gibt es für OSs und nicht für Hardware. Dein Router muss WireGuard nicht unterstützen.
EDIT:
BTW: WireGuard gibt es auch für Android und WireGuard auf dem PI, benutzt man _ohne PiVPN_, denn nur _ohne_ PiVPN kannst Du WireGuard auf deinem PI "optimal" konfigurieren und benutzen.

Display More

Bot · Vor einem Moment

jojohannes · September 5, 2024 at 12:15 PM New

Quote from rpi444

Zeige mal wie Du tcpdump auf dem Server benutzt hast.

So wie du es geschrieben hast:

Code

sudo tcpdump -c 30 -vvveni <input-Interface> host 192.168.115.135 and arp
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

Wenn ich in der wg0.conf wieder "AllowedIPs = 10.199.89.2/32" eintrage und der normale ICMP-Ping durchläuft, sehe ich das im tcpdump, nur den arping sehe ich nicht.

rpi444 · September 5, 2024 at 12:35 PM New

Quote from jojohannes
Quote from rpi444

Zeige mal wie Du tcpdump auf dem Server benutzt hast.

So wie du es geschrieben hast:
Code
sudo tcpdump -c 30 -vvveni <input-Interface> host 192.168.115.135 and arp
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Wenn ich in der wg0.conf wieder "AllowedIPs = 10.199.89.2/32" eintrage und der normale ICMP-Ping durchläuft, sehe ich das im tcpdump, ...

Siehst Du den icmp-Ping am eth0-Interface des Servers oder am wg0-Interface des Servers? Du benutzt tcpdump doch auf dem Server und nicht auf dem PI, oder?

jojohannes · September 5, 2024 at 12:46 PM New

Sorry hatte tatsächlich beim tcpdump hinten das icmp nicht mit arp ersetzt.

Folgende ausgabe habe ich (nicht wundern ist ein anderer Server mit der ip 192.168.115.196, der andere läuft mit Windows)

Code

tcpdump listening on eth0, link-type EN1OMB (Ethernet), snapshot length 262144 bytes
12:40:18.782715 b8:27:eb:79:29:8d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.198 (ff:ff:ff:ff:ff:ff) tell 192.168.115.135, length 46
 12:40:18.782737 00:15:5d:73:aa:cc > b8:27:eb:79:29:8d, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.115.198 is-at 00:15:5d:73:aa:cc, length 28 12:40:19.782781 b8:27:eb:79:29:8d > 00:15:5d:73:aa:cc, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.198 (00:15:5d:73:aa:cc) tell 192.168.115.135, length 46
 12:40:19.782799 00:15:5d:73:aa:cc > b8:27:eb:79:29:8d, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.115.198 is-at 00:15:5d:73:aa:cc, length 28 12:40:20.596570 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46
 12:40:20.782711 b8:27:eb:79:29:8d > 00:15:5d:73:aa:cc, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.198 (00:15:5d:73:aa:cc) tell 192.168.115.135, length 46
 12:40:20.782729 00:15:5d:73:aa:cc > b8:27:eb:79:29:8d, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.115.198 is-at 00:15:5d:73:aa:cc, length 28 12:40:21.416559 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46
 12:40:22.416605 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46
 12:40:25.823507 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46
 12:40:26.416367 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46
 12:40:27.416412 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46
 12:40:40.995466 00:15:5d:73:aa:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.16 8.115.135 tell 192.168.115.196, length 46

Display More

Bot · Vor einem Moment

rpi444 · September 5, 2024 at 5:07 PM New

Quote from jojohannes

Sorry hatte tatsächlich beim tcpdump hinten das icmp nicht mit arp ersetzt.
Folgende ausgabe habe ich (nicht wundern ist ein anderer Server mit der ip 192.168.115.196, der andere läuft mit Windows)

Ich habe aber geschrieben, dass Du tcpdump auf dem Server (.200) und nicht auf dem PI starten sollst. Denn wir wollen ja, auf dem Server sehen ob der Ping dort ankommt (und aus welchen Gründen auch immer) ein icmp-reply zum PI nicht ankommt.
Wenn Du Windows hast, kannst Du wireshark mit dem richtigen Filter benutzen, statt tcpdump.

jojohannes · September 5, 2024 at 5:17 PM New

Quote from rpi444

Ich habe aber geschrieben, dass Du tcpdump auf dem Server (.200) und nicht auf dem PI starten sollst.

.196 ist nicht der Pi, der hat die .135.

Das macht also keinen Unterschied, die .200 und die .196 sind beide im gleichen Netz.

Bei beiden geht ARP durch und ICMP nicht.

rpi444 · September 5, 2024 at 8:54 PM New

Quote from jojohannes

Bei beiden geht ARP durch und ICMP nicht.

Dann liegt es evtl. an deinem Router (oder gleichwertig).

EDIT:

Kann es evtl. sein, dass Du ein arp-proxy in deiner Konstellation benutzt?

Bot · Vor einem Moment

jojohannes · September 6, 2024 at 10:37 AM New

Quote from rpi444

Dann liegt es evtl. an deinem Router (oder gleichwertig).

Warum sollte das am Router liegen? Wo kommt der zum Einsatz?

So verstehe ich das (korrigiere mich wenn ich falsch liege):

Der Raspi möchte zu einem Host per ICMP pingen im gleichen Netz, was ohne "allowedips=[eigenes Netz]"ganz normal funktioniert.

MIT "allowedips=[eigenes Netz]" funktioniert arping nach meinem Verständnis deswegen, weil das auf OSI-Schicht 2 läuft, wireguard läuft auf OSI-Schicht 3.

Wireguard schickt alles (ab Schicht 3, also auch ICMP) was zu "AllowedIps" will über den Tunnel, dort gibt es das netz nicht.

Quote from rpi444

Kann es evtl. sein, dass Du ein arp-proxy in deiner Konstellation benutzt?

Tatsächlich ist die Option aktiviert im Lancom, ist mir neu.

rpi444 · September 6, 2024 at 11:08 AM New

Quote from jojohannes

So verstehe ich das ...

Solche Tests funktionieren m. E. nur dann richtig, wenn die Kommunikation richtig funktioniert und das ist in diesem Thread nicht der Fall.

jojohannes · September 6, 2024 at 2:32 PM New

Ich habe jetzt im Lancom den Proxy-ARP deaktiviert und am Raspi den ARP-Cache gelöscht, ändert aber nichts.

Immernoch "ping: sendmsg: Es ist eine Zieladresse notwendig" beim ICMP-Ping.

Bot · Vor einem Moment

Bei WireGuard (PiVPN) NAT deaktivieren

Participate now!

Users Viewing This Thread