hat bei mir den Eindruck hinterlassen, dass dies grundsätzlich möglich sein sollte.
Bei mir in x-fachen Ausführungen in Betrieb 
.
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Müsste ich auf dem Raspi nicht auch noch eine ip route addieren, damit dieser weiss, wo er die Adressen des VPN-Clients findet? Habe ein paar Sachen ausprobiert, aber die Pakete versanden immer 
Vielen Dank für einen heissen Tipp!
Hi @Frafeffeu86
Müsste ich auf dem Raspi nicht auch noch eine ip route addieren, damit dieser weiss, wo er die Adressen des VPN-Clients findet? Habe ein paar Sachen ausprobiert, aber die Pakete versanden immer
Was sagen denn folgende Befehle auf dem Raspi?
ip route
cat /proc/sys/net/ipv4/ip_forward
Da das VPN-Interface dem Raspberry Pi anliegt, sollte zumindest dorthin eine Route sein. Falls du auf ein zusätzliches Netz zugreifen willst, musst du natürlich sicherstellen, dass jeder Hop dazwischen eine Route dorthin hat.
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Hier die Reaktionen:
root@DietPi:~# ip route
default via 192.168.1.1 dev eth0
10.198.101.0/24 dev tun0 proto kernel scope link src 10.198.101.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.135
[root@DietPi:~#](mailto:root@DietPi:~)
root@DietPi:~# cat /proc/sys/net/ipv4/ip_forward
1
[root@DietPi:~#](mailto:root@DietPi:~)
Ein Traceroute von einem lokalen PC aus in Richtung Remote-Netzwerk ergibt folgendes Resultat:
C:\sers\ritz>tracert 192.168.2.1
Routenverfolgung zu 192.168.2.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms internetbox.home [192.168.1.1]
2 1 ms <1 ms * dietpi.home [192.168.1.135]
3 1 ms * * internetbox.home [192.168.1.1]
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 C
C:\sers\ritz>
Offensichtlich schickt der Raspi das Päckli wieder an seinen Standard Gateway zurück, weil er nicht weiss was anfangen damit.
Der VPN-Status beim Server zeigt folgendes:
root@DietPi:~# pivpn -c
: NOTE: The output below is NOT real-time!
:: It may be off by a few minutes.
::: Client Status List:::
Name Remote IP Virtual IP Bytes Received Bytes Sent Connected Since
BodmeliNP 178.197.206.91:43610 10.198.101.2 13KiB 11KiB 07:35:49 1693546549 0 UNDEF
root@DietPi:~#
Bäh! Die Tabulatoren sind auf der Strecke geblieben, aber ich denke, dein Kennerblick kann es trotzdem entziffern 
Hi @Frafeffeu86
Wie von dir vermutet, fehlt da die Route rüber .
Du kannst diese mit dem ip command hinzufügen:
ip route add 192.168.2.0/24 via 10.198.101.<vpn-tunnel-ip-des-lte-routers>
Wie oben erwähnt: Denk daran, dass du auf dem LTE Router anschliessend ebenfalls eine Route retour setzen musst. (192.168.1.0/24 via 10.198.101.1)
Kleiner Hinweis: Routen, die mit ip route add hinzugefügt werden, sind nicht persistent (=sie verschwinden beim reboot). Damit die Route bleibt, musst du diese noch persistieren:
Im File /lib/dhcpcd/dhcpcd-hooks/40-route:
ip route add 192.168.2.0/24 via 10.198.101.<vpn-tunnel-ip-des-lte-routers>
hinzufügen. (Siehe hier)
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Die Pakete versanden immer noch
Bin langsam etwas ratlos….. 
Routen auf dem Raspi:
root@DietPi:~# ip route
default via 192.168.1.1 dev eth0
10.198.101.0/24 dev tun0 proto kernel scope link src 10.198.101.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.135
192.168.2.0/24 via 10.198.101.2 dev tun0 # habe ich manuell erstellt
[root@DietPi:~#](mailto:root@DietPi:~)
Routen auf dem LTE-Router (wurden alle automatisch erstellt):
root@RUT956:~# ip route
0.0.0.0/1 via 10.198.101.1 dev tun_c_Bodmeli
default dev wwan0 proto static scope link src 10.30.81.91 metric 4
10.30.81.91 dev wwan0 proto static scope link metric 4
10.198.101.0/24 dev tun_c_Bodmeli proto kernel scope link src 10.198.101.2
92.107.60.66 dev wwan0
128.0.0.0/1 via 10.198.101.1 dev tun_c_Bodmeli
192.168.1.0/24 via 10.198.101.1 dev tun_c_Bodmeli
192.168.2.0/24 dev br-lan proto static scope link metric 1
root@RUT956:~#
Finde den Fehler
Die Pakete versanden immer noch
Bin langsam etwas ratlos…..
Bei Ratlosigkeit hilft oft traceroute mit einer Prise TCPDUMP .
- was sagt denn traceroute nun wo es hingeht?
- siehst du mit “sudo tcpdump -i eth0” den Traffic das Raspi erreichen?
- siehst du mit “sudo tcpdump -i tun0” den Traffic ins VPN verschwinden?
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Erst mal gewaltigen Dank für deine schnellen Rückmeldungen!
Also……
Traceroute:
C:\sers\ritz>tracert 192.168.2.1
Routenverfolgung zu 192.168.2.1 über maximal 30 Hops
1 <1 ms <1 ms <1 ms internetbox.home [192.168.1.1]
2 1 ms <1 ms <1 ms dietpi.home [192.168.1.135]
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
Früher ging das Päckli zurüch an dir IB2, jetzt irgendwie nicht mehr….?
tcpdump scheint nicht seins zu sein…. kann das sein weil der Pi auf diät ist?
root@DietPi:~# tcpdump -i eth0
-bash: tcpdump: command not found
root@DietPi:~# sudo tcpdump -i eth0
sudo: tcpdump: command not found
root@DietPi:~# sudo tcpdump -i tun0
sudo: tcpdump: command not found
[root@DietPi:~#](mailto:root@DietPi:~)
Der Ratlose
Aha! Musste tcpdump erst noch draufmachen….. 🙂
Habe während dem Dump einen PING auf 192.168.2.1 laufen lassen mit folgendem Ergebnis:
root@DietPi:~# tcpdump -i eth0
tcpdump: ausführliche Ausgabe unterdrückt, verwenden Sie -v[v]… für die vollständige Protokolldekodierung
Abhören von eth0, Verbindungstyp EN10 MB (Ethernet), Snapshot-Länge 262144 Bytes
11:00:50.705157 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 4144579784:4144579992, ack 3954830836, win 501, Länge 208
11:00:50.753638 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 208, Win 1025, Länge 0
11:00:50.758044 IP dietpi.home.59294 > internetbox.home.domain: 13783+ PTR? 135.1.168.192.in-addr.arpa. (44)
11:00:50.759806 IP internetbox.home.domain > dietpi.home.59294: 13783* 1/0/0 PTR dietpi.home. (69)
11:00:50.760316 IP dietpi.home.52421 > internetbox.home.domain: 46307+ PTR? 111.1.168.192.in-addr.arpa. (44)
11:00:50.760987 IP internetbox.home.domain > dietpi.home.52421: 46307* 1/0/0 PTR lenovo-desktop.home. (77)
11:00:50.761793 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 208:512, ack 1, win 501, Länge 304
11:00:50.769531 IP internetbox.home.mdns > 224.0.0.251.mdns: 0 [8a] PTR (QM)? _services._dns-sd._udp.local. (230)
11:00:50.815647 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 512, Win 1024, Länge 0
11:00:50.867088 IP dietpi.home.33279 > internetbox.home.domain: 38210+ PTR? 1.1.168.192.in-addr.arpa. (42)
11:00:50.869765 IP internetbox.home.domain > dietpi.home.33279: 38210* 1/0/0 PTR internetbox.home. (72)
11:00:50.870619 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 512:672, ack 1, win 501, Länge 160
11:00:50.870928 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 672:944, ack 1, win 501, Länge 272
11:00:50.871205 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 944:1232, ack 1, win 501, Länge 288
11:00:50.871247 IP dietpi.home.38193 > internetbox.home.domain: 14202+ PTR? 251.0.0.224.in-addr.arpa. (42)
11:00:50.871479 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 944, Win 1022, Länge 0
11:00:50.874976 IP internetbox.home.domain > dietpi.home.38193: 14202 NXDomain 0/1/0 (99)
11:00:50.875697 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1232:1408, ack 1, win 501, Länge 176
11:00:50.875934 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1408:1568, ack 1, win 501, Länge 160
11:00:50.876264 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 1408, win 1026, Länge 0
11:00:50.923812 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 1568, win 1025, Länge 0
11:00:50.977175 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1568:1728, ack 1, win 501, Länge 160
11:00:50.977457 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1728:2000, ack 1, win 501, Länge 272
11:00:50.977724 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 2000:2288, ack 1, win 501, Länge 288
11:00:50.978058 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 2000, win 1024, Länge 0
11:00:50.978123 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 2288:2656, ack 1, win 501, Länge 368
11:00:50.978450 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 2656:3168, ack 1, win 501, length 512
11:00:50.978740 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 2656, Win 1021, Länge 0
11:00:50.991415 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [P.], seq 1:161, ack 3168, win 1026, Länge 160
11:00:50.991954 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3168:3216, ack 161, win 501, Länge 48
11:00:51.003468 IP doorcam.home.33546 > 255.255.255.255.6667: UDP, Länge 188
11:00:51.033446 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 3216, win 1026, Länge 0
11:00:51.087327 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3216:3504, ack 161, win 501, Länge 288
11:00:51.087727 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3504:3904, ack 161, win 501, Länge 400
11:00:51.087975 IP dietpi.home.40248 > internetbox.home.domain: 20673+ PTR? 96.1.168.192.in-addr.arpa. (43)
11:00:51.088033 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3904:4432, ack 161, win 501, Länge 528
11:00:51.088223 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 3904, win 1023, Länge 0
11:00:51.089788 IP internetbox.home.domain > dietpi.home.40248: 20673* 1/0/0 PTR doorcam.home. (69)
11:00:51.090409 IP dietpi.home.48822 > internetbox.home.domain: 44024+ PTR? 255.255.255.255.in-addr.arpa. (46)
11:00:51.109777 IP internetbox.home.domain > dietpi.home.48822: 44024 NXDomain* 0/0/0 (46)
11:00:51.110454 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 4432:4576, ack 161, win 501, Länge 144
11:00:51.110698 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 4576:4736, ack 161, win 501, length 160
11:00:51.111290 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 4736, win 1026, Länge 0
11:00:51.197423 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 4736:5040, ack 161, win 501, length 304
11:00:51.197940 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 5040:5440, ack 161, win 501, Länge 400
11:00:51.198315 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 5440:6048, ack 161, win 501, length 608
11:00:51.198534 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 6048:6208, ack 161, win 501, length 160
11:00:51.198543 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 5440, Win 1023, Länge 0
11:00:51.199078 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 6208, Win 1026, Länge 0
11:00:51.253302 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 245, Länge 40
11:00:51.307342 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 6208:6512, ack 161, win 501, length 304
11:00:51.307671 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 6512:7024, ack 161, win 501, length 512
11:00:51.307719 IP dietpi.home.50011 > internetbox.home.domain: 38738+ PTR? 1.2.168.192.in-addr.arpa. (42)
11:00:51.308246 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 7024, win 1023, Länge 0
11:00:51.308540 IP internetbox.home.domain > dietpi.home.50011: 38738 NXDomain* 0/0/0 (42)
11:00:51.309274 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7024:7184, ack 161, win 501, length 160
11:00:51.361577 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 7184, Win 1022, Länge 0
11:00:51.417332 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7184:7488, ack 161, win 501, Länge 304
11:00:51.417690 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7488:7856, ack 161, win 501, Länge 368
11:00:51.417928 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7856:8144, ack 161, win 501, Länge 288
11:00:51.418266 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 7856, win 1026, Länge 0
11:00:51.454638 IP lenovo-desktop.home.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/2 PTR Lenovo-Desktop._dosvc._tcp.local. (253)
11:00:51.454688 IP6 fe80::6fee:addf:1b5a:fd3a.mdns > ff02::fb.mdns: 0*- [0q] 1/0/2 PTR Lenovo-Desktop._dosvc._tcp .lokal. (253)
11:00:51.455082 IP lenovo-desktop.home.mdns > 224.0.0.251.mdns: 0 ANY (QM)? Lenovo-Desktop._dosvc._tcp.local. (50)
11:00:51.455115 IP6 fe80::6fee:addf:1b5a:fd3a.mdns > ff02::fb.mdns: 0 ANY (QM)? Lenovo-Desktop._dosvc._tcp.local. (50)
11:00:51.460296 ARP, Anfrage, wer internetbox.home hat, sag pavicam.home, Länge 50
11:00:51.469548 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 8144, Win 1025, Länge 0
11:00:51.527305 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 8144:8448, ack 161, win 501, length 304
11:00:51.527621 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 8448:8848, ack 161, win 501, length 400
11:00:51.527742 IP dietpi.home.34878 > internetbox.home.domain: 20402+ PTR? a.3.d.f.a.5.b.1.f.d.d.a.e.e.f.6.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90)
11:00:51.528178 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], Ack 8848, Win 1022, Länge 0
11:00:51.529073 IP internetbox.home.domain > dietpi.home.34878: 20402 NXDomain* 0/0/0 (90)
11:00:51.529646 IP dietpi.home.38424 > internetbox.home.domain: 27030+ PTR? b.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
11:00:51.534657 IP internetbox.home.domain > dietpi.home.38424: 27030 NXDomain 0/1/0 (154)
11:00:51.535487 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 8848:9040, ack 161, win 501, length 192
11:00:51.535698 IP dietpi.home.59475 > internetbox.home.domain: 17833+ PTR? 99.1.168.192.in-addr.arpa. (43)
11:00:51.535770 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 9040:9328, ack 161, win 501, Länge 288
11:00:51.536233 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 9328, win 1026, Länge 0
11:00:51.536783 IP internetbox.home.domain > dietpi.home.59475: 17833* 1/0/0 PTR pavicam.home. (69)
11:00:51.537431 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 9328:9472, ack 161, win 501, length 144
11:00:51.537664 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 9472:9632, ack 161, win 501, length 160
11:00:51.538090 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 9632, win 1025, Länge 0
11:00:51.579065 IP lenovo-desktop.home.mdns > 224.0.0.251.mdns: 0 PTR (QM)? _microsoft_mcc._tcp.local. (43)
11:00:51.579110 IP6 fe80::6fee:addf:1b5a:fd3a.mdns > ff02::fb.mdns: 0 PTR (QM)? _microsoft_mcc._tcp.local. (43)
11:00:51.637292 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 9632:9936, ack 161, win 501, length 304
11:00:51.637777 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 9936:10256, ack 161, win 501, Länge 320
11:00:51.638173 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 10256:10768, ack 161, win 501, length 512
11:00:51.638382 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 10256, win 1022, Länge 0
11:00:51.638481 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 10768:11264, ack 161, win 501, length 496
11:00:51.638807 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 11264:11440, ack 161, win 501, Länge 176
11:00:51.639058 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 11264, win 1026, Länge 0
11:00:51.639082 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 11440:11952, ack 161, win 501, length 512
11:00:51.639667 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 11952, win 1023, Länge 0
11:00:51.719062 IP lenovo-desktop.home.mdns > 224.0.0.251.mdns: 0 ANY (QM)? Lenovo-Desktop._dosvc._tcp.local. (50)
11:00:51.719112 IP6 fe80::6fee:addf:1b5a:fd3a.mdns > ff02::fb.mdns: 0 ANY (QM)? Lenovo-Desktop._dosvc._tcp.local. (50)
11:00:51.747139 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 11952:12256, ack 161, win 501, Länge 304
11:00:51.747418 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 12256:12544, ack 161, win 501, Länge 288
11:00:51.747702 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 12544:12960, ack 161, win 501, Länge 416
11:00:51.747957 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 12960:13248, ack 161, win 501, Länge 288
11:00:51.748098 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 12544, win 1021, Länge 0
11:00:51.748189 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 13248:13536, ack 161, win 501, Länge 288
11:00:51.748479 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 13248, win 1026, Länge 0
11:00:51.795899 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 13536, win 1025, Länge 0
root@DietPi:~# tcpdump -i tun0
tcpdump: ausführliche Ausgabe unterdrückt, verwenden Sie -v[v]… für die vollständige Protokolldekodierung
Listening auf tun0, Link-Typ RAW (Raw IP), Snapshot-Länge 262144 Bytes
11:02:21.243328 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 263, Länge 40
11:02:26.246441 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 264, Länge 40
11:02:31.268297 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 265, Länge 40
11:02:36.260015 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 266, Länge 40
11:02:41.256720 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 267, Länge 40
11:02:46.289228 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 268, Länge 40
11:02:51.264517 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 269, Länge 40
11:02:56.256849 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 270, Länge 40
11:03:00.905069 IP 10.198.101.2.54956 > dns.google.domain: 63802+ A? rms.teltonika-networks.com. (44)
11:03:00.920742 IP dns.google.domain > 10.198.101.2.54956: 63802 1/0/0 A 18.196.62.30 (60)
11:03:00.959815 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [S], seq 2326203959, win 64240, Optionen [mss 1358,sackOK,TS val 2647402884 ecr 0,nop,wscale 4], Länge 0
11:03:00.971046 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [S.], seq 3499186849, ack 2326203960, gewinnen 65084, Optionen [mss 1240,sackOK,TS val 4136062913 ecr 2647402884,nop,wscale 7], Länge 0
11:03:01.001794 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], ack 1, win 4015, Optionen [nop,nop,TS val 2647402925 ecr 4136062913], Länge 0
11:03:01.009856 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [P.], seq 1:294, ack 1, Win 4015, Optionen [nop,nop,TS val 2647402933 ecr 4136062913], Länge 293
11:03:01.020583 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [.], Ack 294, Win 507, Optionen [nop,nop,TS val 4136062962 ecr 2647402933], Länge 0
11:03:01.038295 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [P.], seq 1:97, ack 294, Sieg 507, Optionen [nop,nop,TS val 4136062980 ecr 2647402933], Länge 96
11:03:01.038363 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [.], seq 97:1325, ack 294 , Win 507, Optionen [nop,nop,TS val 4136062980 ecr 2647402933], Länge 1228
11:03:01.081858 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], Ack 97, Win 4009, Optionen [nop,nop,TS val 2647402992 ecr 4136062980], Länge 0
11:03:01.089611 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], Ack 1325, Win 4006, Optionen [nop,nop,TS val 2647402996 ecr 4136062980], Länge 0
11:03:01.092431 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [P.], seq 1325:1927, ack 294, Sieg 507, Optionen [nop,nop,TS val 4136063034 ecr 2647402992], Länge 602
11:03:01.121753 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], Ack 1927, Win 4006, Optionen [nop,nop,TS val 2647403047 ecr 4136063034], Länge 0
11:03:01.249384 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 271, Länge 40
11:03:01.351339 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], seq 294:1522, ack 1927 , Win 4006, Optionen [nop,nop,TS val 2647403267 ecr 4136063034], Länge 1228
11:03:01.351758 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [P.], seq 1522:2705, ack 1927, Sieg 4006, Optionen [nop,nop,TS val 2647403267 ecr 4136063034], Länge 1183
11:03:01.383401 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [.], Ack 2705, Win 503, Optionen [nop,nop,TS val 4136063325 ecr 2647403267], Länge 0
11:03:01.392066 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [P.], seq 1927:1933, ack 2705, Win 503, Optionen [nop,nop,TS val 4136063334 ecr 2647403267], Länge 6
11:03:01.411829 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], Ack 1933, Win 4006, Optionen [nop,nop,TS val 2647403345 ecr 4136063334], Länge 0
11:03:01.422331 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [P.], seq 1933:1970, ack 2705, Win 503, Optionen [nop,nop,TS val 4136063364 ecr 2647403345], Länge 37
11:03:01.459809 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], Ack 1970, Win 4006, Optionen [nop,nop,TS val 2647403375 ecr 4136063364], Länge 0
11:03:01.460067 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [P.], seq 2705:2864, ack 1970, Win 4006, Optionen [nop,nop,TS val 2647403377 ecr 4136063364], Länge 159
11:03:01.482281 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [P.], seq 1970:2008, ack 2864, Win 503, Optionen [nop,nop,TS val 4136063424 ecr 2647403377], Länge 38
11:03:01.506423 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [FP.], seq 2008:2031, ack 2864, Win 503, Optionen [nop,nop,TS val 4136063448 ecr 2647403377], Länge 23
11:03:01.511717 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [.], Ack 2008, Win 4006, Optionen [nop,nop,TS val 2647403435 ecr 4136063424], Länge 0
11:03:01.519839 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [P.], seq 2864:2887, ack 2008, Win 4006, Optionen [nop,nop,TS val 2647403442 ecr 4136063424], Länge 23
11:03:01.520068 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [F.], seq 2887, ack 2008, Win 4006, Optionen [nop,nop,TS val 2647403442 ecr 4136063424], Länge 0
11:03:01.530557 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [R], seq 3499188857, win 0, Länge 0
11:03:01.531145 IP ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009 > 10.198.101.2.47582: Flags [R], seq 3499188857, win 0, Länge 0
11:03:01.531750 IP 10.198.101.2.47582 > ec2-18-196-62-30.eu-central-1.compute.amazonaws.com.15009: Flags [R], seq 2326206823, win 0, Länge 0
11:03:06.240010 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 272, Länge 40
11:03:11.258834 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 273, Länge 40
11:03:16.247681 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 274, Länge 40
Es sieht danach aus, dass der Ping im Tunnel verschwindet. (Auch dass er nicht an die SB2 zurückgeschickt wird wird darauf hingewiesen)
Außerdem scheint es beim LTE-Router zu haken 😒
Hier nochmal die Routen im LTE Router:
root@RUT956:~# IP-Route
0.0.0.0/1 über 10.198.101.1 dev tun_c_Bodmeli
default dev wwan0 proto staticscope link src 10.30.81.91 metric 4 # das ist die private IP des Routers
10.30.81.91 Dev Wwan0 Proto Static Scope Link Metrik 4
10.198.101.0/24 dev tun_c_Bodmeli Proto Kernel Scope Link SRC 10.198.101.2
92.107.60.66 dev wwan0 # das ist die öffentliche IP der IB2
128.0.0.0/1 über 10.198.101.1 dev tun_c_Bodmeli
192.168.1.0/24 über 10.198.101.1 dev tun_c_Bodmeli
192.168.2.0/24 dev br-lan proto statischer Scope-Link-Metrik 1
[root@RUT956:~#](mailto:root@RUT956:~)
Habe leider noch nicht so ein geschultes 👁️ um das Problem von Weitem zu sehen
5 Tage später
Ups, habe ich den Bogen jetzt überspannt? 
Hallo @Frafeffeu86
Ups, habe ich den Bogen jetzt überspannt? 🫤
Nein, habe nicht gesehen, dass du geantwortet hast 😅
root@DietPi:~# tcpdump -i tun0
tcpdump: Ausführliche Ausgabe unterdrückt, verwenden Sie -v[v]… für die vollständige Protokolldekodierung
Listen auf tun0, Link-Typ RAW (Raw IP), Snapshot-Länge 262144 Bytes
11:02:21.243328 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 263, Länge 40
11:02:26.246441 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 264, Länge 40
11:02:31.268297 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 265, Länge 40
11:02:36.260015 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 266, Länge 40
11:02:41.256720 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 267, Länge 40
11:02:46.289228 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 268, Länge 40
11:02:51.264517 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 269, Länge 40
11:02:56.256849 IP lenovo-desktop.home > 192.168.2.1: ICMP-Echo-Anfrage, ID 1, Seq 270, Länge 40
Die Pings gehen via Tunnel raus, wunderschön 😊
Allerdings fehlen mir da die Antworten auf die Pings 🤔. Ich würde aktuell auf den LTE-Router tippen.
192.168.2.1 ist ja auch der LTE-Router - richtig? Hat eine Firewall? Kann sein, dass du da noch den Verkehr zulassen musst. Gemäss Dokumentation sollte dein Router ebenfalls tcpdumpen können. Dann kannst du dich mal dort draufsetzen und schauen was passiert.
Tipp: Mit dem Filter „not port 22“ kannst du deinen eigenen SSH Traffic herausfiltern – dann siehts schon viel weniger wild aus. Wir sehen aktuell die Echo-Anfragen und suchen Echo-Antworten 😉
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Das ist ein echter Kampf!
Versuche noch die Route persistent zu machen.
Die Anleitung von die bezieht sich auf irgend ein anderes UNIX-Derivat. Auf meinem DietPi sieht das etwas anders aus.
Habe mal versucht den Eintrag im /etc/network/interfaces zu machen, mit dem Effekt, dass das Ethernet Port des Pi nicht mehr reagiert 
Muss nun wohl einen Bildschirm und ein Keyboard anstecken und schauen, ob ich die Misere so beseitigen kann.
Hast du mir einen Tipp wo ich auf dem DietPi (Debian) die Routen persistieren kann?
Mittlerweile habe ich die Problematik auch bei der TELTONIKA-Community eingebracht.
Anfrage:
The tunnel works so far as it is supposed to do.
Now I am struggeling to make the tunnel work symmetrically, i.e. that I can not only see the server-subnet from the client, but also the client-subnet from the server. I added the necessary route on the server side and I can see (using tcpdump) that the packets addressed to the client network are sent into the tunnel, but nothing is coming back.
This is how the routing table on the RUT looks like:
root@RUT956:~# ip route
0.0.0.0/1 via 10.198.101.1 dev tun_c_Bodmeli
*default dev wwan0 proto static scope link src 10.30.81.91 metric 4
10.30.81.91 dev wwan0 proto static scope link metric 4
10.198.101.0/24 dev tun_c_Bodmeli proto kernel scope link src 10.198.101.2
*92.107.60.66 dev wwan0
128.0.0.0/1 via 10.198.101.1 dev tun_c_Bodmeli
192.168.1.0/24 via 10.198.101.1 dev tun_c_Bodmeli
192.168.2.0/24 dev br-lan proto static scope link metric 1
root@RUT956:~#
These are the original routes generated automatically by the RUT.
My questions:
- Do I need to add something more?
- Can I install tcpdump on the RUT to troubleshoot or could this mess up something on the RUT?
Thanks for your support!
Fritz
Hier die Antwort:
Add the following to the server config:
client-config-dir /etc/openvpn/ccd
This tells the server where the client configurations are located.
Within the directory (In this example /etc/openvpn/ccd), create a file named after the client’s Common Name (CN) from their certificate. For example, if a client’s CN is client1, then you would create a file named client1 inside the ccd directory. In this file, you can specify options for this specific client. To associate a client with a specific network, you can use the iroute option:
iroute 192.168.10.0 255.255.255.0
This tells the server to associate the network 192.168.10.0/24 with client1. Basically, this means that the server will route traffic destined to 192.168.10.0/24 network via client1.
Kind Regards,
Was hältst du davon? Könnte da was dran sein?
LG Fritz
Der iroute-Tipp von Teltonika war tatsächlich das letzte Steinchen, das noch gefehlt hat.
Viele Dank an euch für eure Tipps und Hinweise! Ohne die wäre ich gar nie soweit gekommen. 
Jetzt muss ich noch ein bisschen “Finetuning” machen….
So wie es aussieht, würgt der LTE-Router sämtlichen Traffic durch den Tunnel, was nicht wirklich sein müsste.
LG Fritz
So, jetzt läuft die Sache fast so wie gewünscht.
Musste noch ein paar push-Befehle auskommentieren auf der Serverseite, damit der Client nicht den ganzen traffic durch den Tunnel jagt.
Jetzt habe ich noch ein letztes Problem:
Ich habe es bis jetzt nicht geschafft, die notwendig statische Route persistent zu machen.
Habe bei Google verschiedene Rezepte gefunden, aber nichts hat geholfen!
Im DietPi-Forum hat einer genau diese Frage gestellt, aber interessanterweise keine Antwort bekommen…. 
Es muss doch irgend eine Möglichkeit geben,
ip route add 192.168.2.0/24 via 10.198.101.2
persistent zu machen!
Kann mir einer von euch den allesentscheidenden Tipp geben?
Bitte lasst mich nicht im Stich
LG Fritz
Hi @Frafeffeu86
Sorry für die späte Antwort.
Aalso - mittels iroute wird ja die Route gesetzt, sobald das VPN läuft. Oder?
Dann musst du nach einem Reboot ja nur noch sicherstellen, dass der Tunnel automatisch ready ist - weder mein Pi, noch ich sind auf Diät, darum muss ich jetzt ein wenig raten, aber ich würde behaupten, dass das eigentlich jetzt so passen müsste.
Ist denn die Route weg nach einem Neustart des Pis? Versucht sich der Router automatisch wieder mit dem VPN zu verbinden?
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Also, was ich festgestellt habe ist, dass es sowohl den iroute-Eintrag beim Server als auch die statische Route beim Pi braucht, damit es funktioniert.
Der Tunnel wird nach einem Neustart problemlos wieder aufgebaut (ohne Risse in der Decke ), aber der symmetrische Betrieb tut erst wieder nachdem ich die statische Route erneut eingekratzt habe. Das heisst, ich suche immer noch nach einem Weg die Route beim DietPi persistent zu machen.
Jetzt habe ich aber noch eine weitere Problemzone entdeckt:
Vom Servernetzwerk aus habe ich Verbindung zum LTE-Router und kann mich dort einloggen etc.
Ich bin dann naiverweise davon ausgegangen, dass ich dann auch Zugriff auf das ganze Subnetz des LTE-Routers habe - bis ich es getestet habe . Die PINGs kommen zwar beim Endgerät im Client-Netzwerk an (gecheckt mit WireShark), aber es kommt nichts retour .
Ich habe diesen Umstand mal beim Teltonika-Support deponiert, mal gucken ob da was kommt.
Oder hast du noch eine zündende Idee?
LG Fritz
…..Hi @Frafeffeu86
Hingegen werden noch gerne sachdienliche Hinweise zur Persistierung von statischen Routen auf einem DietPi entgegengenommen.
Dann muss wohl einer meiner Pis auf Diät.. Melde mich sobald ich mehr weiss
lg
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Hi @Frafeffeu86
Wieder mal etwas gelernt, DietPi ist ein Pi auf Diät, oder ein gut gefüttertes Debian - je nachdem aus welcher Perspektive 
So funktioniert es bei mir (Die via Adresse natürlich ersetzen):
Datei /etc/network/interfaces
# Location: /etc/network/interfaces
# Please modify network settings via: dietpi-config
# Or create your own drop-ins in: /etc/network/interfaces.d/# Drop-in configs
source interfaces.d/*# Ethernet
allow-hotplug eth0
iface eth0 inet dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9 149.112.112.112
up ip route add 192.168.2.0/24 via 10.20.10.2
down ip route delete 192.168.2.0/24 via 10.20.10.2# WiFi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9 149.112.112.112
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Anwenden kannst du das ganze mittels systemctl restart networking. Wenn du mutig bist, via SSH, sonst direkt pi an einen Monitor und Tastatur anschliessen. Es kann eine Weile dauern, bis der Pi wieder online ist, so nach 30 Sekunden spätestens sollte er wieder da sein.
Mit _systemctl status networkin_g und journalctl -xefu networking kannst du troubleshooten, falls was in die Hose geht. Nicht verzweifeln, an diesem File sind schon Generationen von Informatiklernenden verzweifelt
Falls du WiFi verwendest, muss die Config natürlich unters wlan0.
LG
r00t
4b 65 69 6e 65 20 4d 61 63 68 74 20 64 65 72 20 6c 65 67 61 63 79 20 49 50 21
Diesen Eintrag hatte ich schon einmal versucht, hat bei mir aber nicht funktioniert und funktioniert immer noch nicht. Nach einem Reboot ist die Route wieder weg 
der systemctl status networking nach dem Reboot zeigt folgendes:
root@DietPi:~# systemctl status networking
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; preset: enabled)
Active: active (exited) since Thu 2023-09-14 22:11:06 CEST; 1min 1s ago
Docs: man:interfaces(5)
Process: 309 ExecStart=/sbin/ifup -a –read-environment (code=exited, status=0/SUCCESS)
Process: 374 ExecStart=/bin/sh -c if [ -f /run/network/restart-hotplug ]; then /sbin/ifup -a –read-environment –allow=hotplug; fi (code=exited, status=0/SUCCESS)
Main PID: 374 (code=exited, status=0/SUCCESS)
CPU: 265ms
Sep 14 22:11:05 DietPi systemd[1]: Starting networking.service - Raise network interfaces…
Sep 14 22:11:06 DietPi systemd[1]: Finished networking.service - Raise network interfaces.
[root@DietPi:~#](mailto:root@DietPi:~)
Warum immer ich??? 