@Frafeffeu86

The packages are still shipping

I’m starting to feel a bit at a loss….. 🤔

If you are at a loss, traceroute with a pinch of TCPDUMP often helps 😉.

- what does traceroute say where it’s going?

- Do you see the traffic reaching the Raspi with “sudo tcpdump -i eth0”?

- Do you see the traffic disappearing into the VPN with “sudo tcpdump -i tun0”?

LG

r00t

Show original language (German)

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

@r00t

First of all, thank you very much for your quick feedback!

So……

Trace route:

C:\sers\ritz>tracert 192.168.2.1

Route tracking to 192.168.2.1 over a maximum of 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 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.

The package used to go back to you IB2, but now somehow not anymore….?

tcpdump doesn’t seem to be his thing… could that be because the Pi is on a diet?

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:~)

The perplexed one

Show original language (German)

@r00t

Aha! Musste tcpdump erst noch draufmachen….. 🙂

Habe während dem Dump einen PING auf 192.168.2.1 laufen lassen mit folgendem Resultat:

root@DietPi:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:00:50.705157 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 4144579784:4144579992, ack 3954830836, win 501, length 208
11:00:50.753638 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 208, win 1025, length 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, length 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, length 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, length 160
11:00:50.870928 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 672:944, ack 1, win 501, length 272
11:00:50.871205 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 944:1232, ack 1, win 501, length 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, length 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, length 176
11:00:50.875934 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1408:1568, ack 1, win 501, length 160
11:00:50.876264 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 1408, win 1026, length 0
11:00:50.923812 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 1568, win 1025, length 0
11:00:50.977175 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1568:1728, ack 1, win 501, length 160
11:00:50.977457 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 1728:2000, ack 1, win 501, length 272
11:00:50.977724 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 2000:2288, ack 1, win 501, length 288
11:00:50.978058 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 2000, win 1024, length 0
11:00:50.978123 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 2288:2656, ack 1, win 501, length 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, length 0
11:00:50.991415 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [P.], seq 1:161, ack 3168, win 1026, length 160
11:00:50.991954 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3168:3216, ack 161, win 501, length 48
11:00:51.003468 IP doorcam.home.33546 > 255.255.255.255.6667: UDP, length 188
11:00:51.033446 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 3216, win 1026, length 0
11:00:51.087327 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3216:3504, ack 161, win 501, length 288
11:00:51.087727 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 3504:3904, ack 161, win 501, length 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, length 528
11:00:51.088223 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 3904, win 1023, length 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, length 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, length 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, length 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, length 0
11:00:51.199078 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 6208, win 1026, length 0
11:00:51.253302 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 245, length 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, length 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, length 0
11:00:51.417332 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7184:7488, ack 161, win 501, length 304
11:00:51.417690 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7488:7856, ack 161, win 501, length 368
11:00:51.417928 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 7856:8144, ack 161, win 501, length 288
11:00:51.418266 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 7856, win 1026, length 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.local. (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, Request who-has internetbox.home tell pavicam.home, length 50
11:00:51.469548 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 8144, win 1025, length 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, length 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, length 288
11:00:51.536233 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 9328, win 1026, length 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, length 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, length 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, length 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, length 176
11:00:51.639058 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 11264, win 1026, length 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, length 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, length 304
11:00:51.747418 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 12256:12544, ack 161, win 501, length 288
11:00:51.747702 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 12544:12960, ack 161, win 501, length 416
11:00:51.747957 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 12960:13248, ack 161, win 501, length 288
11:00:51.748098 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 12544, win 1021, length 0
11:00:51.748189 IP dietpi.home.ssh > lenovo-desktop.home.50735: Flags [P.], seq 13248:13536, ack 161, win 501, length 288
11:00:51.748479 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 13248, win 1026, length 0
11:00:51.795899 IP lenovo-desktop.home.50735 > dietpi.home.ssh: Flags [.], ack 13536, win 1025, length 0

root@DietPi:~# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
11:02:21.243328 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 263, length 40
11:02:26.246441 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 264, length 40
11:02:31.268297 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 265, length 40
11:02:36.260015 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 266, length 40
11:02:41.256720 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 267, length 40
11:02:46.289228 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 268, length 40
11:02:51.264517 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 269, length 40
11:02:56.256849 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 270, length 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, options [mss 1358,sackOK,TS val 2647402884 ecr 0,nop,wscale 4], length 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, win 65084, options [mss 1240,sackOK,TS val 4136062913 ecr 2647402884,nop,wscale 7], length 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, options [nop,nop,TS val 2647402925 ecr 4136062913], length 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, options [nop,nop,TS val 2647402933 ecr 4136062913], length 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, options [nop,nop,TS val 4136062962 ecr 2647402933], length 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, win 507, options [nop,nop,TS val 4136062980 ecr 2647402933], length 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, options [nop,nop,TS val 4136062980 ecr 2647402933], length 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, options [nop,nop,TS val 2647402992 ecr 4136062980], length 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, options [nop,nop,TS val 2647402996 ecr 4136062980], length 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, win 507, options [nop,nop,TS val 4136063034 ecr 2647402992], length 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, options [nop,nop,TS val 2647403047 ecr 4136063034], length 0
11:03:01.249384 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 271, length 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, options [nop,nop,TS val 2647403267 ecr 4136063034], length 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, win 4006, options [nop,nop,TS val 2647403267 ecr 4136063034], length 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, options [nop,nop,TS val 4136063325 ecr 2647403267], length 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, options [nop,nop,TS val 4136063334 ecr 2647403267], length 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, options [nop,nop,TS val 2647403345 ecr 4136063334], length 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, options [nop,nop,TS val 4136063364 ecr 2647403345], length 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, options [nop,nop,TS val 2647403375 ecr 4136063364], length 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, options [nop,nop,TS val 2647403377 ecr 4136063364], length 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, options [nop,nop,TS val 4136063424 ecr 2647403377], length 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, options [nop,nop,TS val 4136063448 ecr 2647403377], length 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, options [nop,nop,TS val 2647403435 ecr 4136063424], length 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, options [nop,nop,TS val 2647403442 ecr 4136063424], length 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, options [nop,nop,TS val 2647403442 ecr 4136063424], length 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, length 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, length 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, length 0
11:03:06.240010 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 272, length 40
11:03:11.258834 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 273, length 40
11:03:16.247681 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 274, length 40

Es sieht danach aus, dass der Ping im Tunnel verschwindet. (Auch dass er nicht an die SB2 zurückgeschickt wird deutet ja darauf hin)

Also scheint es beim LTE Router zu haken 😒

Hier nochmal die Routen in LTE Router:

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 # das ist die private IP des Routers
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 # das ist die Public IP der IB2
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:~#](mailto:root@RUT956:~)

Habe leider noch nicht so ein geschultes 👁️ um das Problem von Weitem zu sehen

5 days later

Hi @Frafeffeu86

Ups, habe ich den Bogen jetzt überspannt? 🫤

Nein, habe nicht gesehen, dass du geantwortet hast 😅

root@DietPi:~# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
11:02:21.243328 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 263, length 40
11:02:26.246441 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 264, length 40
11:02:31.268297 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 265, length 40
11:02:36.260015 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 266, length 40
11:02:41.256720 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 267, length 40
11:02:46.289228 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 268, length 40
11:02:51.264517 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 269, length 40
11:02:56.256849 IP lenovo-desktop.home > 192.168.2.1: ICMP echo request, id 1, seq 270, length 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 ebenfalls der LTE Router - richtig? Hat der eine Firewall? Kann sein, dass du da noch den Traffic erlauben musst. Gemäss Dokumentation sollte dein Router ebenfalls tcpdumpen können. Dann kannst du dich mal dort drauf setzen 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 requests, und suchen echo replies 😉

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

This is a real fight!

Try to make the route persistent.

The instructions from die refer to any other UNIX derivative. Things look a little different on my DietPi.

I tried making the entry in /etc/network/interfaces, with the result that the Ethernet port on the Pi no longer responds 😒 I guess I’ll have to plug in a screen and a keyboard and see if I can fix the problem.

Do you have a tip for me where I can persist the routes on the DietPi (Debian)?

I have now also brought the problem to the TELTONIKA community.

Inquiry:

The tunnel works as far as it is supposed to do.
Now I am struggling 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:

  1. Do I need to add something more?
  2. Can I install tcpdump on the RUT to troubleshoot or could this mess up something on the RUT?

Thanks for your support!
Fritz

Here is the answer:

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,

What do you think of it? Could there be something to it?

LG Fritz

Show original language (German)

@r00t @DomiP

The iroute tip from Teltonika was actually the last piece that was missing.

Many thanks to you for your tips and advice! Without them I would never have gotten this far. 👍👍👍

Now I have to do a bit of fine tuning…

It looks like the LTE router is strangling all traffic through the tunnel, which doesn’t really have to be the case.

LG Fritz

Show original language (German)

@r00t @DomiP

So now things are going almost as planned.

Had to comment out a few push commands on the server side so that the client doesn’t chase all the traffic through the tunnel.

Now I have one last problem:

I haven’t managed to make the necessary static route persistent yet.

I found various recipes on Google, but nothing helped! 😕

Someone asked exactly this question in the DietPi forum, but interestingly enough, they didn’t get an answer…. 😵‍💫

There has to be some way

ip route add 192.168.2.0/24 via 10.198.101.2

to make it persistent!

Can one of you give me the all-important tip?

Please don’t let me down

LG Fritz

Show original language (German)

Hi @Frafeffeu86

Sorry for the late reply.

Well - using iroute the route is set as soon as the VPN is running. Or?

Then after a reboot you just have to make sure that the tunnel is automatically ready - neither my Pi nor I are on a diet, so I have to guess a little now, but I would say that it should actually be fine now.

Is the route gone after restarting the Pi? Does the router automatically try to reconnect to the VPN?

LG

r00t

Show original language (German)

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

@r00t

So what I found is that it needs both the iroute entry on the server and the static route on the Pi for it to work.

The tunnel is rebuilt without any problems after a restart (without cracks in the ceiling 😉), but symmetrical operation only works again after I scratched the static route again. That means I’m still looking for a way to make the route persistent on DietPi.

But now I have discovered another problem area:

From the server network I have a connection to the LTE router and can log in there etc.

I then naively assumed that I would then have access to the entire subnet of the LTE router - until I tested it 😕. The PINGs arrive at the device in the client network (checked with WireShark), but nothing is returned 😒.

I’ve reported this fact to Teltonika support, we’ll see if anything comes up.

Or do you still have a brilliant idea?

LG Fritz

Show original language (German)

@r00t @DomiP

The problem area with the PING has been resolved. It was a firewall setting issue. Luckily I figured it out myself 😳…..

On the other hand, relevant advice on persisting static routes on a DietPi is still welcome.

LG Fritz

Show original language (German)

Hi @Frafeffeu86

On the other hand, relevant tips on persisting static routes on a DietPi are still welcome.

Then one of my Pis must be on a diet. I’ll let you know as soon as I know more

lg

r00t

Show original language (German)

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

Learned something again, DietPi is a Pi on a diet, or a well-fed Debian - depending on which perspective 😄

This is how it works for me (replace the via address of course):

File /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

You can do this using systemctl restart networking. If you’re brave, via SSH, otherwise connect the pi directly to a monitor and keyboard. It can take a while until the Pi is online again, but it should be back after 30 seconds at the latest.

With _systemctl status networkin_g and journalctl -xefu networking you can troubleshoot if something goes wrong. Don’t despair, generations of computer science students have despaired of this file 😉

If you use WiFi, the config must of course be under wlan0.

LG

r00t

Show original language (German)

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

I tried this entry before, but it didn’t work for me and it still doesn’t work. After a reboot the route is gone again 😣

The systemctl status networking after the reboot shows the following:

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:~)

Why always me??? 😥

Show original language (German)

Hi @Frafeffeu86

oh of course - it’s a different interface. aaalso - since openvpn manages the tun0 interface, we have to let openvpn do this..

1. Return /etc/network/interfaces to its original state.

2. in /etc/openvpn/server.conf:

route 192.168.2.0 255.255.255.0 10.198.101.2

add.

3. Restart the openvpn server with systemctl restart openvpn.

4. Fingers crossed 😉

LG

r00t

Show original language (German)

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

@r00t 👌👌👌👍👍👍🕺📣🥳🎉

Yipeeee!! It works! You are a genius!

Thank you very much for your help!

One last question: Where are the address settings for the Ethernet port?

Apparently he doesn’t care about the entries in /etc/network/interfaces…

LG Fritz

Show original language (German)
  • r00t has responded to this post.

    Hi Frafeffeu86

    It doesn’t matter - it’s on DHCP by default, the addresses below are intended as a “fall-back” in case DHCP goes wrong.

    DietPi even offers you a tutu for this 😉

    dietpi-config

    7: Network Options: Adapters > Ethernet: Available | [On] | Connected

    Then set mode to [STATIC], adjust address and GW, then click Apply.

    r00t_0-1694762343675.png

    LG

    r00t

    Show original language (German)

    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