Devices via VPN ins Lokale Netzwerk brücken

mat6937 · Beitrag von **mat6937** » 11.03.2020 00:20:00

Knogle hat geschrieben:
10.03.2020 23:28:39
Code: Alles auswählen
The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, ...
Das habe ich auch mal probiert, liegt aber irgendwie wohl an dem OpenWRT device.
Code: Alles auswählen
ip route add 192.168.2.0/24 via 10.0.0.1

Versuch mal zusätzlich mit:

Code: Alles auswählen

ip route add 192.168.2.0/24 via 10.0.0.1 dev wg0

, wenn Wireguard sämtlichen Traffic durchlassen kann.

Knogle · Beitrag von **Knogle** » 11.03.2020 01:52:47

Danke dir, leider tut es das auch nicht.
Scheinbar gibt es irgendwie Probleme mit der Netzwerkbrücke auf der OpenWRT Seite, und das scheint zumindest laut den ersten Forenbeiträgen nicht so einfach möglich zu sein den Traffic durch das wg Interface zu schicken.
Wird dann wohl eher ein Fall für einen neuen Thread.

Wie soll ich die traceroute Ergebnisse beurteilen vom LAN client aus? Ist da doch ne Verbindung?

Code: Alles auswählen

chairman@workstation:~$ traceroute 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.2 (10.0.0.2)  0.350 ms  0.429 ms  0.516 ms
chairman@workstation:~$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.401 ms  0.503 ms  0.598 ms
 2  10.0.0.1 (10.0.0.1)  1092.023 ms  1092.321 ms  1093.039 ms
chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.430 ms  0.491 ms  0.550 ms
 2  OpenWrt.lan (192.168.1.1)  3142.422 ms !H  3142.460 ms !H  3142.507 ms !H

Habe die Route mal statt auf das eth0 device, auf das WLAN device gebindet, jetzt kommt das.

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.47
traceroute to 192.168.2.47 (192.168.2.47), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.408 ms  0.456 ms  0.528 ms
 2  192.168.43.133 (192.168.43.133)  3144.898 ms !H  3144.902 ms !H  3144.975 ms !H

Jetzt mal auf die bridge LAN--> WLAN br0 gebindet.

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.47
traceroute to 192.168.2.47 (192.168.2.47), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.370 ms  0.447 ms  0.506 ms
 2  * * 192.168.43.1 (192.168.43.1)  10.383 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Auf wg0 gebindet.

Code: Alles auswählen

traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.321 ms  0.426 ms  0.483 ms
 2  10.0.0.1 (10.0.0.1)  1534.243 ms  1543.417 ms  1544.590 ms
 3  192.168.2.1 (192.168.2.1)  1543.647 ms  1544.013 ms  1545.247 ms

Knogle · Beitrag von **Knogle** » 11.03.2020 02:47:18

Problem soweit gelöst.
Man musste die statische Route auf das Interface "wg0" binden als unicast. Nun klappt das schonmal, und ich kann auf die Adressen innerhalb meines Heimnetzes zugreifen.
Wie mache ich das nun mit dem Telefon?
Da muss man erstmal drauf kommen.. ohne Traceroute echt schwierig.
Die Performance scheint garnicht so schlecht zu sein.

EDIT: Aus irgendeinem Grund hat sich das ganze wieder selbst abgeschossen.
Ist jetzt wieder so.

Code: Alles auswählen

traceroute 192.168.2.47
traceroute to 192.168.2.47 (192.168.2.47), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.370 ms  0.447 ms  0.506 ms
 2  * * 192.168.43.1 (192.168.43.1)  10.383 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

bluestar · Beitrag von **bluestar** » 11.03.2020 07:41:57

Knogle hat geschrieben:
11.03.2020 02:47:18
Wie mache ich das nun mit dem Telefon?

Wie hast du dein Telefon aktuell konfiguriert? DHCP? SIP-Server?

Knogle hat geschrieben:
11.03.2020 02:47:18
Die Performance scheint garnicht so schlecht zu sein.

Einen Vergleich findest du bei Wireguard selbst: https://www.wireguard.com/performance/

debianoli · Beitrag von **debianoli** » 11.03.2020 08:01:58

Wenn im Telefon die Sip-Daten des Anbieters eingetragen sind, braucht man gar nichts machen. Nicht einmal eine VPN Verbindung ist nötig bei NetCologne.

bluestar · Beitrag von **bluestar** » 11.03.2020 08:14:49

debianoli hat geschrieben:
11.03.2020 08:01:58
Wenn im Telefon die Sip-Daten des Anbieters eingetragen sind, braucht man gar nichts machen. Nicht einmal eine VPN Verbindung ist nötig bei NetCologne.

Du beteiligst dich doch an den Thread, dann lies auch einfach mal was Knogle dazu bereits geschrieben hat:

Knogle hat geschrieben:
05.03.2020 14:40:00
Von meinem Anbieter netcologne habe ich in der Fritzbox bei den Rufnummern eigentlich alle Daten, bis auf das Kennwort. Da sind nur Sternchen.

debianoli · Beitrag von **debianoli** » 11.03.2020 08:38:59

bluestar hat geschrieben:
11.03.2020 08:14:49
Du beteiligst dich doch an den Thread, dann lies auch einfach mal was Knogle dazu bereits geschrieben hat:

Knogle hat geschrieben:
05.03.2020 14:40:00
Von meinem Anbieter netcologne habe ich in der Fritzbox bei den Rufnummern eigentlich alle Daten, bis auf das Kennwort. Da sind nur Sternchen.

Ja und? Dann soll er sich mal ins Kundenmenue von netcologne einloggen, dort findet er das Kennwort. Die entsprechenden Links hab ich oben bereits gepostet, Netcologne unterstützt nomadische Nutzung. Er muss entscheiden, ob er sein VOIp-Telefon die SIP-Verbindung herstellen lässt oder immer über die Fritzbox geht.

Knogle · Beitrag von **Knogle** » 11.03.2020 12:50:52

Momentan habe ich das Problem dass die Route irgendwie nach einigen MInuten nicht mehr funktioniert, darum werde ich mich wohl als erstes kümmern müssen.

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.317 ms  0.381 ms  0.443 ms
 2  10.0.0.1 (10.0.0.1)  448.333 ms  449.055 ms  466.175 ms
 3  192.168.2.1 (192.168.2.1)  466.933 ms  470.350 ms  470.513 ms

Paar Minuten später

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.343 ms  0.353 ms  0.393 ms
 2  192.168.43.1 (192.168.43.1)  3.177 ms  5.129 ms  5.226 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *

Nach Neustart des Routers geht es erstmal wieder.

Router gestartet, muss man kurze Zeit warten, dann gehts wieder

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.644 ms  0.637 ms  0.960 ms
 2  192.168.43.1 (192.168.43.1)  8.291 ms  8.554 ms  8.593 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * 192.168.2.1 (192.168.2.1)  3960.416 ms  3960.536 ms

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.444 ms  0.402 ms  0.440 ms
 2  10.0.0.1 (10.0.0.1)  306.123 ms  311.153 ms  311.155 ms
 3  192.168.2.1 (192.168.2.1)  327.855 ms  330.761 ms  330.908 ms

mat6937 · Beitrag von **mat6937** » 11.03.2020 13:19:34

Knogle hat geschrieben:

11.03.2020 12:50:52

Momentan habe ich das Problem dass die Route irgendwie nach einigen MInuten nicht mehr funktioniert, ...

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.317 ms  0.381 ms  0.443 ms
 2  10.0.0.1 (10.0.0.1)  448.333 ms  449.055 ms  466.175 ms
 3  192.168.2.1 (192.168.2.1)  466.933 ms  470.350 ms  470.513 ms

Paar Minuten später

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.343 ms  0.353 ms  0.393 ms
 2  192.168.43.1 (192.168.43.1)  3.177 ms  5.129 ms  5.226 ms
 9  * * *

Paar Minuten später ist der 2. hop, ja auch nicht mehr die IP-Adresse 10.0.0.1.
Ist diese IP-Adresse per ping noch erreichbar?

Code: Alles auswählen

ping -c 3 10.0.0.1
route -n
wg
ip a

?

Knogle · Beitrag von **Knogle** » 11.03.2020 13:24:05

mat6937 hat geschrieben:
11.03.2020 13:19:34
Knogle hat geschrieben:
11.03.2020 12:50:52
Momentan habe ich das Problem dass die Route irgendwie nach einigen MInuten nicht mehr funktioniert, ...
Code: Alles auswählen
chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.317 ms  0.381 ms  0.443 ms
 2  10.0.0.1 (10.0.0.1)  448.333 ms  449.055 ms  466.175 ms
 3  192.168.2.1 (192.168.2.1)  466.933 ms  470.350 ms  470.513 ms
Paar Minuten später
Code: Alles auswählen
chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.343 ms  0.353 ms  0.393 ms
 2  192.168.43.1 (192.168.43.1)  3.177 ms  5.129 ms  5.226 ms
 9  * * *
Paar Minuten später ist der 2. hop, ja auch nicht mehr die IP-Adresse 10.0.0.1.
Ist diese IP-Adresse per ping noch erreichbar?
Code: Alles auswählen
ping -c 3 10.0.0.1
route -n
wg
ip a
?

Pingbar vom Router aus schon, von den LAN devices aus kann ich garnicht pingen. Aber paar Minuten lang kann ich 192.168.2.X Adressen abrufen, irgendwann nicht mehr.

Code: Alles auswählen

64 bytes from 10.0.0.1: seq=65 ttl=64 time=445.897 ms
64 bytes from 10.0.0.1: seq=66 ttl=64 time=264.233 ms
64 bytes from 10.0.0.1: seq=67 ttl=64 time=386.125 ms
64 bytes from 10.0.0.1: seq=68 ttl=64 time=650.909 ms
64 bytes from 10.0.0.1: seq=69 ttl=64 time=3126.402 ms
64 bytes from 10.0.0.1: seq=70 ttl=64 time=2127.421 ms
64 bytes from 10.0.0.1: seq=71 ttl=64 time=1127.328 ms
64 bytes from 10.0.0.1: seq=72 ttl=64 time=437.845 ms

Lasse PIng aktuell auf beiden Seiten durchgehend laufen.

route -n

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.43.1    0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
85.197.43.22    192.168.43.1    255.255.255.255 UGH   0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.43.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

wg

Code: Alles auswählen

  public key: xxxxxx
  private key: (hidden)
  listening port: 5555

peer: yyyyyy
  endpoint: 85.197.43.22:5555
  allowed ips: 10.0.0.1/32, 192.168.2.0/24
  latest handshake: 19 seconds ago
  transfer: 11.68 KiB received, 13.64 KiB sent
  persistent keepalive: every 30 seconds

ip -a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:07:0a:02:25:50 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7:aff:fe02:2550/64 scope link 
       valid_lft forever preferred_lft forever
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:07:0a:02:25:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd1b:c1e2:8857::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::7:aff:fe02:2550/64 scope link 
       valid_lft forever preferred_lft forever
6: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
    link/ether 02:07:0a:02:25:50 brd ff:ff:ff:ff:ff:ff
7: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:07:0a:02:25:50 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7:aff:fe02:2550/64 scope link 
       valid_lft forever preferred_lft forever
8: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.2/24 brd 10.0.0.255 scope global wg0
       valid_lft forever preferred_lft forever
9: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 10:a4:be:6b:18:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.43.133/24 brd 192.168.43.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::12a4:beff:fe6b:18c8/64 scope link 
       valid_lft forever preferred_lft forever

Habe jetzt schon ne Weile lang keinen "Absturz" mehr. Aber das VoIP Telefon habe ich diesmal nicht angeschlossen, nur meinen Laptop.
Mir kommt es so vor als wenn die Netzwerkinitialisierung vom Telefon durch ist, dann geht das irgendwie nicht mehr. Werde das mal jetzt probieren.

EDIT:

Tatsache, sobald die Initialisierung vom Netzwerk beim VoIP Telefon durch ist, sind die 192.168.2.X Adressen nicht mehr erreichbar.

mat6937 · Beitrag von **mat6937** » 11.03.2020 13:34:43

Knogle hat geschrieben:
11.03.2020 13:24:05
Tatsache, sobald die Initialisierung vom Netzwerk beim VoIP Telefon durch ist, sind die 192.168.2.X Adressen nicht mehr erreichbar.

Wie ist jetzt, nach der Initialisierung vom Netzwerk beim VoIP Telefon, das Routing?

Code: Alles auswählen

route -n

?

BTW: Der Ping im Wireguard-Tunnel ist auch ziemlich hoch.

EDIT:

Mit tcpdump und dem geeigneten Filter kannst Du auf einem _nicht_ wireguard-Interface prüfen, ob dort wireguard-Traffic z. Zt. statt findet. Z. B.:

Code: Alles auswählen

tcpdump -c 20 -vvveni <Interface> 'udp[8:4] >= 0x1000000 and udp[8:4] <= 0x4000000'

(Interface anpassen und ohne spitze Klammern).

Knogle · Beitrag von **Knogle** » 11.03.2020 13:45:51

mat6937 hat geschrieben:
11.03.2020 13:34:43

Knogle hat geschrieben:
11.03.2020 13:24:05
Tatsache, sobald die Initialisierung vom Netzwerk beim VoIP Telefon durch ist, sind die 192.168.2.X Adressen nicht mehr erreichbar.
Wie ist jetzt, nach der Initialisierung vom Netzwerk beim VoIP Telefon, das Routing?
Code: Alles auswählen
route -n
?

BTW: Der Ping im Wireguard-Tunnel ist auch ziemlich hoch.

Nachher ist die Ausgabe die gleiche irgendwie.
Kann das ganze mit dem hohen Ping zusammenhaengen? Ich habe hier via Mobilfunk momentan nur Edge.
War wohl eher Zufall gerade mit dem Telefon dass es dann nicht mehr ging, bspw. jetzt ist das Telefon wohl verbunden, und noch habe ich Verbindung zum 192.168.2.X
Reagiert der Wireguard Tunnel empflindlich auf Verbindungsabbrueche?

Telefonieren kann ich nun schonmal!!! Zumindest laut Telefon. Dieser Piepton kommt beim Waehlen jedoch nicht.

mat6937 · Beitrag von **mat6937** » 11.03.2020 13:48:25

Knogle hat geschrieben:
11.03.2020 13:45:51
Reagiert der Wireguard Tunnel empflindlich auf Verbindungsabbrueche?

Kannst ja mal testen, mit tcpdump (siehe EDIT, oben).

Knogle · Beitrag von **Knogle** » 11.03.2020 14:02:49

mat6937 hat geschrieben:
11.03.2020 13:48:25

Knogle hat geschrieben:
11.03.2020 13:45:51
Reagiert der Wireguard Tunnel empflindlich auf Verbindungsabbrueche?
Kannst ja mal testen, mit tcpdump (siehe EDIT, oben).

Danke dir, ich lass es mal laufen.
Bisher läuft alles prima!
Hat jemand eventuell noch ne Idee warum ich keinen Ton reinkriege?
Ich checke vielleicht mal die Route in die Gegenrichtung

mat6937 · Beitrag von **mat6937** » 11.03.2020 14:05:46

Knogle hat geschrieben:
11.03.2020 14:02:49
Bisher läuft alles prima!

Eigentlich sollte Wireguard mit kurzen Unterbrechungen in der Verbindung, kein Problem haben, schon wegen dem "Built-in Roaming":

Built-in Roaming

The client configuration contains an initial endpoint of its single peer (the server), so that it knows where to send encrypted data before it has received encrypted data. The server configuration doesn't have any initial endpoints of its peers (the clients). This is because the server discovers the endpoint of its peers by examining from where correctly authenticated data originates. If the server itself changes its own endpoint, and sends data to the clients, the clients will discover the new server endpoint and update the configuration just the same. Both client and server send encrypted data to the most recent IP endpoint for which they authentically decrypted data. Thus, there is full IP roaming on both ends.

Quelle: https://www.wireguard.com/#built-in-roaming

EDIT:

Versuch mal mit einer einheitlichen MTU (z. B. 1392) auf beiden Seiten (Server/Client):

Code: Alles auswählen

ip link set dev wg0 mtu 1392 multicast on

Knogle · Beitrag von **Knogle** » 11.03.2020 14:09:33

mat6937 hat geschrieben:
11.03.2020 14:05:46

Knogle hat geschrieben:
11.03.2020 14:02:49
Bisher läuft alles prima!
Eigentlich sollte Wireguard mit kurzen Unterbrechungen in der Verbindung, kein Problem haben, schon wegen dem "Built-in Roaming":
Built-in Roaming

The client configuration contains an initial endpoint of its single peer (the server), so that it knows where to send encrypted data before it has received encrypted data. The server configuration doesn't have any initial endpoints of its peers (the clients). This is because the server discovers the endpoint of its peers by examining from where correctly authenticated data originates. If the server itself changes its own endpoint, and sends data to the clients, the clients will discover the new server endpoint and update the configuration just the same. Both client and server send encrypted data to the most recent IP endpoint for which they authentically decrypted data. Thus, there is full IP roaming on both ends.
Quelle: https://www.wireguard.com/#built-in-roaming

Bisher läuft auch irgendwie alles stabil, seitdem sich der Ping hier halbwegs stabilisiert hat.

Von der 192.168.1.X Seite merke ich gerade, das Anpingen klappt nicht so.
Jemand hat meinen Anruf angekommen, habe aber nix davon mitgekriegt.

Code: Alles auswählen

[chairman@millenium-fbe48 ~]$ traceroute 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops max, 60 byte packets
 1  fritz.box (192.168.2.1)  0.533 ms  0.478 ms  3.317 ms
 2  fritz.box (192.168.2.1)  3000.928 ms !H  3000.958 ms !H  3000.980 ms !H
[chairman@millenium-fbe48 ~]$ ping 192.168.1.183
PING 192.168.1.183 (192.168.1.183) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 2.2.168.192)
From 192.168.2.1 icmp_seq=2 Redirect Host(New nexthop: 2.2.168.192)
From 192.168.2.1 icmp_seq=3 Redirect Host(New nexthop: 2.2.168.192)
From 192.168.2.1 icmp_seq=4 Destination Host Unreachable
From 192.168.2.1 icmp_seq=7 Destination Host Unreachable
From 192.168.2.1 icmp_seq=10 Destination Host Unreachable
^C
--- 192.168.1.183 ping statistics ---
13 packets transmitted, 0 received, +6 errors, 100% packet loss, time 12304ms
pipe 3
[chairman@millenium-fbe48 ~]$ traceroute 192.168.1.183
traceroute to 192.168.1.183 (192.168.1.183), 30 hops max, 60 byte packets
 1  fritz.box (192.168.2.1)  0.519 ms  2.875 ms  2.853 ms
 2  fritz.box (192.168.2.1)  2993.526 ms !H  2993.565 ms !H  2993.605 ms !H
[chairman@millenium-fbe48 ~]$

Die Route von 192.168.1.X aus in der Fritte sieht so aus.

Ziel Subnetzmaske Gateway

192.168.1.0 255.255.255.0 192.168.2.2

Wobei die 192.168.2.2 für mich keinen Sinn macht.
Habe erstmal die 192.168.2.2 auf 192.168.2.57 angepasst, der IP meines wireguard servers.
Route klappt jetzt auch.

mat6937 · Beitrag von **mat6937** » 11.03.2020 14:12:04

Knogle hat geschrieben:
11.03.2020 14:09:33
Bisher läuft auch irgendwie alles stabil, seitdem sich der Ping hier halbwegs stabilisiert hat.

Versuch mal mit einer einheitlichen MTU (z. B. 1392 für das wireguard-Interface) auf beiden Seiten (Server _und_ Client):

Code: Alles auswählen

ip link set dev wg0 mtu 1392 multicast on

Knogle · Beitrag von **Knogle** » 11.03.2020 14:18:11

mat6937 hat geschrieben:
11.03.2020 14:12:04

Knogle hat geschrieben:
11.03.2020 14:09:33
Bisher läuft auch irgendwie alles stabil, seitdem sich der Ping hier halbwegs stabilisiert hat.
Versuch mal mit einer einheitlichen MTU (z. B. 1392 für das wireguard-Interface) auf beiden Seiten (Server _und_ Client):
Code: Alles auswählen
ip link set dev wg0 mtu 1392 multicast on

Habe ich mal gemacht, bisher keinen Abbruch mehr.
Folgendes Problem habe ich noch.
Die Rückroute läuft, dadurch höre ich die Leute jetzt, aber keine hört mich, da evtl. eine Idee?

mat6937 · Beitrag von **mat6937** » 11.03.2020 14:22:25

Knogle hat geschrieben:
11.03.2020 14:18:11
Die Rückroute läuft, dadurch höre ich die Leute jetzt, aber keine hört mich, da evtl. eine Idee?

Evtl. zeigst Du hier das aktuelle Routing, auf beiden Seiten.

Knogle · Beitrag von **Knogle** » 11.03.2020 14:26:44

mat6937 hat geschrieben:
11.03.2020 14:22:25

Knogle hat geschrieben:
11.03.2020 14:18:11
Die Rückroute läuft, dadurch höre ich die Leute jetzt, aber keine hört mich, da evtl. eine Idee?
Evtl. zeigst Du hier das aktuelle Routing, auf beiden Seiten.

Ich kann auch angerufen werden, jedoch kann ich wie ein irrer reinbruellen,und keiner hoert mich.
Hoffe dass der Hoerer nicht kaputt ist, so oft wie der runtergefallen ist.
Teste gerade mal mit einem anderen Hoerer, da leider auch das gleiche.

ip route show

Standort Other:

Code: Alles auswählen

default via 192.168.43.1 dev wlan0 proto static src 192.168.43.133 
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.2 
10.0.0.1 dev wg0 proto static scope link 
85.197.43.22 via 192.168.43.1 dev wlan0 proto static 
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1 
192.168.2.0/24 dev wg0 proto static scope link 
192.168.43.0/24 dev wlan0 proto kernel scope link src 192.168.43.133

Standort DE (Vom Wireguard pc aus)

Code: Alles auswählen

default via 192.168.2.1 dev enp1s0 
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.1 
192.168.1.0/24 dev wg0 scope link 
192.168.2.0/24 dev enp1s0 proto kernel scope link src 192.168.2.57

mat6937 · Beitrag von **mat6937** » 11.03.2020 14:35:07

Knogle hat geschrieben:
11.03.2020 14:26:44
Ich kann auch angerufen werden, jedoch kann ich wie ein irrer reinbruellen,und keiner hoert mich.

Du könntest (auf beiden Seiten) mit tcpdump auf dem wireguard-Interface testen, ob der ausgehende und der eingehende Traffic (hier als Ping/icmp), durch dieses Interface geht bzw. geroutet wird. Z. B.:

Code: Alles auswählen

tcpdump -c 100 -vvveni wg0 icmp

BTW: Statt icmp-Traffic, könntest Du den Filter auch für TCP bzw. einen gerade benutzten TCP-Port gestalten.

Knogle · Beitrag von **Knogle** » 11.03.2020 14:43:23

Hier mal OpenWRT Seite.
Wenn hier nichts zu sehen ist, dann ist das wohl erstmal hier erledigt, da werde ich wohl mal in entsprechende Cisco Foren schauen, und mal etwas an den Telefoneinstellungen spielen.
Spreche schonmal meinen Dank aus, und am liebsten würde ich euren Aufwand auch gerne entschädigen, aber das ist wohl nicht im Sinne des Forums.

Code: Alles auswählen

tcpdump: listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
13:41:45.411639 ip: (tos 0x0, ttl 63, id 18510, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16412 unreachable, length 36
	(tos 0xc0, ttl 62, id 51293, offset 0, flags [DF], proto UDP (17), length 120, bad cksum 0 (->a6f7)!)
    10.0.0.1.7082 > 192.168.1.183.16412: [no cksum] UDP, length 92
13:41:45.433646 ip: (tos 0x0, ttl 63, id 18511, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16412 unreachable, length 36
	(tos 0xc0, ttl 62, id 51295, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a6a5)!)
    10.0.0.1.7082 > 192.168.1.183.16412: [no cksum] UDP, length 172
13:41:45.452160 ip: (tos 0x0, ttl 63, id 18512, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16412 unreachable, length 36
	(tos 0xc0, ttl 62, id 51297, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a6a3)!)
    10.0.0.1.7082 > 192.168.1.183.16412: [no cksum] UDP, length 172
13:41:46.488824 ip: (tos 0xd8, ttl 63, id 55929, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18535, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
13:41:46.657696 ip: (tos 0xd8, ttl 63, id 55935, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18538, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
13:41:46.660886 ip: (tos 0xd8, ttl 63, id 55937, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18539, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
13:41:46.661999 ip: (tos 0xd8, ttl 63, id 55940, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18540, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
13:41:46.667667 ip: (tos 0xd8, ttl 63, id 55941, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18541, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
13:41:53.880194 ip: (tos 0x0, ttl 63, id 18553, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51913, offset 0, flags [DF], proto UDP (17), length 120, bad cksum 0 (->a48b)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 92
13:41:53.897543 ip: (tos 0x0, ttl 63, id 18554, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51914, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a43a)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:41:53.899892 ip: (tos 0x0, ttl 63, id 18555, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51915, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a439)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:41:53.924085 ip: (tos 0x0, ttl 63, id 18556, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51916, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a438)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:41:53.939980 ip: (tos 0x0, ttl 63, id 18557, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51918, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a436)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:41:56.328205 ip: (tos 0x0, ttl 63, id 18636, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 52102, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->e48a)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
13:42:02.111602 ip: (tos 0x0, ttl 63, id 18830, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 52542, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->e2d2)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
13:42:09.286616 ip: (tos 0x0, ttl 63, id 19070, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 53054, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->e0d2)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
13:42:15.759568 ip: (tos 0x0, ttl 63, id 19287, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53554, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dd2)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.784721 ip: (tos 0x0, ttl 63, id 19288, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53556, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dd0)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.799718 ip: (tos 0x0, ttl 63, id 19289, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53558, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dce)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.819628 ip: (tos 0x0, ttl 63, id 19290, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53559, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dcd)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.851856 ip: (tos 0x0, ttl 63, id 19291, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53560, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dcc)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.859473 ip: (tos 0x0, ttl 63, id 19292, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53561, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dcb)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.879687 ip: (tos 0x0, ttl 63, id 19293, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53563, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc9)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.899770 ip: (tos 0x0, ttl 63, id 19294, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53564, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc8)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.919577 ip: (tos 0x0, ttl 63, id 19295, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53565, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc7)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.941709 ip: (tos 0x0, ttl 63, id 19296, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53566, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc6)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.959601 ip: (tos 0x0, ttl 63, id 19297, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53567, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc5)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:15.979606 ip: (tos 0x0, ttl 63, id 19298, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53569, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc3)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:16.004412 ip: (tos 0x0, ttl 63, id 19299, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 53570, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->dece)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
13:42:16.004972 ip: (tos 0x0, ttl 63, id 19300, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53571, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc1)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:16.019794 ip: (tos 0x0, ttl 63, id 19301, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53573, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbf)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:16.042047 ip: (tos 0x0, ttl 63, id 19302, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53574, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbe)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:16.061597 ip: (tos 0x0, ttl 63, id 19303, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53576, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbc)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
13:42:16.081593 ip: (tos 0x0, ttl 63, id 19304, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53577, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbb)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172

Code: Alles auswählen

tcpdump -c 100 -vvveni wg0 icmp
tcpdump: listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
09:41:45.440458 ip: (tos 0x0, ttl 63, id 18510, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16412 unreachable, length 36
	(tos 0xc0, ttl 62, id 51293, offset 0, flags [DF], proto UDP (17), length 120, bad cksum 0 (->a6f7)!)
    10.0.0.1.7082 > 192.168.1.183.16412: [no cksum] UDP, length 92
09:41:45.478440 ip: (tos 0x0, ttl 63, id 18511, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16412 unreachable, length 36
	(tos 0xc0, ttl 62, id 51295, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a6a5)!)
    10.0.0.1.7082 > 192.168.1.183.16412: [no cksum] UDP, length 172
09:41:45.482594 ip: (tos 0x0, ttl 63, id 18512, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16412 unreachable, length 36
	(tos 0xc0, ttl 62, id 51297, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a6a3)!)
    10.0.0.1.7082 > 192.168.1.183.16412: [no cksum] UDP, length 172
09:41:46.241056 ip: (tos 0xd8, ttl 63, id 55929, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18535, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
09:41:46.282874 ip: (tos 0xd8, ttl 63, id 55932, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18537, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
09:41:46.310913 ip: (tos 0xd8, ttl 63, id 55935, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18538, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
09:41:46.340918 ip: (tos 0xd8, ttl 63, id 55937, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18539, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
09:41:46.393200 ip: (tos 0xd8, ttl 63, id 55940, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18540, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
09:41:46.403482 ip: (tos 0xd8, ttl 63, id 55941, offset 0, flags [none], proto ICMP (1), length 308)
    192.168.2.1 > 192.168.1.183: ICMP 192.168.2.1 udp port 7082 unreachable, length 288
	(tos 0xb8, ttl 62, id 18541, offset 0, flags [none], proto UDP (17), length 280)
    192.168.1.183.16412 > 192.168.2.1.7082: [udp sum ok] UDP, length 252
09:41:53.920821 ip: (tos 0x0, ttl 63, id 18553, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51913, offset 0, flags [DF], proto UDP (17), length 120, bad cksum 0 (->a48b)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 92
09:41:53.941311 ip: (tos 0x0, ttl 63, id 18554, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51914, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a43a)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:41:53.941340 ip: (tos 0x0, ttl 63, id 18555, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51915, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a439)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:41:53.960644 ip: (tos 0x0, ttl 63, id 18556, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51916, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a438)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:41:53.980653 ip: (tos 0x0, ttl 63, id 18557, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 51918, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->a436)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:41:56.361550 ip: (tos 0x0, ttl 63, id 18636, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 52102, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->e48a)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
09:42:02.191771 ip: (tos 0x0, ttl 63, id 18830, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 52542, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->e2d2)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
09:42:09.321929 ip: (tos 0x0, ttl 63, id 19070, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 53054, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->e0d2)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
09:42:15.841743 ip: (tos 0x0, ttl 63, id 19287, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53554, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dd2)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.841868 ip: (tos 0x0, ttl 63, id 19288, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53556, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dd0)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.850748 ip: (tos 0x0, ttl 63, id 19289, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53558, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dce)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.860562 ip: (tos 0x0, ttl 63, id 19290, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53559, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dcd)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.890602 ip: (tos 0x0, ttl 63, id 19291, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53560, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dcc)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.890634 ip: (tos 0x0, ttl 63, id 19292, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53561, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dcb)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.930892 ip: (tos 0x0, ttl 63, id 19293, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53563, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc9)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.950681 ip: (tos 0x0, ttl 63, id 19294, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53564, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc8)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.960451 ip: (tos 0x0, ttl 63, id 19295, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53565, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc7)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:15.990529 ip: (tos 0x0, ttl 63, id 19296, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53566, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc6)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.010715 ip: (tos 0x0, ttl 63, id 19297, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53567, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc5)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.030666 ip: (tos 0x0, ttl 63, id 19298, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53569, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc3)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.050893 ip: (tos 0x0, ttl 63, id 19299, offset 0, flags [none], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16415 unreachable, length 36
	(tos 0x0, ttl 62, id 53570, offset 0, flags [none], proto UDP (17), length 124, bad cksum 0 (->dece)!)
    10.0.0.1.7091 > 192.168.1.183.16415: [no cksum] UDP, length 96
09:42:16.051023 ip: (tos 0x0, ttl 63, id 19300, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53571, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dc1)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.060789 ip: (tos 0x0, ttl 63, id 19301, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53573, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbf)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.091647 ip: (tos 0x0, ttl 63, id 19302, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53574, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbe)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.110847 ip: (tos 0x0, ttl 63, id 19303, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53576, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbc)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172
09:42:16.130555 ip: (tos 0x0, ttl 63, id 19304, offset 0, flags [DF], proto ICMP (1), length 56)
    192.168.1.183 > 10.0.0.1: ICMP 192.168.1.183 udp port 16414 unreachable, length 36
	(tos 0xc0, ttl 62, id 53577, offset 0, flags [DF], proto UDP (17), length 200, bad cksum 0 (->9dbb)!)
    10.0.0.1.7090 > 192.168.1.183.16414: [no cksum] UDP, length 172

mat6937 · Beitrag von **mat6937** » 11.03.2020 14:56:13

Knogle hat geschrieben:
11.03.2020 14:43:23
Wenn hier nichts zu sehen ist, dann ist das wohl erstmal hier erledigt, ...

Diese Ausgaben sind nutzlos. Wenn, dann solltest Du schon auch den benutzten tcpdump-Filter zeigen und beschreiben welchen Traffic Du (evtl. absichtlich) produziert hast und mit dem tcpdump sniffen wollen.

BTW: Der Zähler (-c 100) habe ich nur so auf 100 gesetzt, sonst hört der ja nie auf zu sniffen. Das heißt jetzt aber nicht, dass Du zwingend 100 Datenpakete sniffen und zeigen musst. Wenn tcpdump das aufgezeichnet (oder auch nicht aufgezeichnet) hat, was Du sehen wolltest, kannst Du mit "strg C" abbrechen.

Knogle · Beitrag von **Knogle** » 11.03.2020 15:03:07

mat6937 hat geschrieben:
11.03.2020 14:56:13

Knogle hat geschrieben:
11.03.2020 14:43:23
Wenn hier nichts zu sehen ist, dann ist das wohl erstmal hier erledigt, ...
Diese Ausgaben sind nutzlos. Wenn, dann solltest Du schon auch den benutzten tcpdump-Filter zeigen und beschreiben welchen Traffic Du (evtl. absichtlich) produziert hast und mit dem tcpdump sniffen wollen.

BTW: Der Zähler (-c 100) habe ich nur so auf 100 gesetzt, sonst hört der ja nie auf zu sniffen. Das heißt jetzt aber nicht, dass Du zwingend 100 Datenpakete sniffen und zeigen musst. Wenn tcpdump das aufgezeichnet (oder auch nicht aufgezeichnet) hat, was Du sehen wolltest, kannst Du mit "strg C" abbrechen.

Danke dir, deine Variante probiere ich auch mal.
Ich versuche jetzt mal nebenbei speziell den VoIP traffic zu checken.

Code: Alles auswählen

tcpdump -vvveni wg0 udp port 5060 or udp portrange 10500-11652 -s 0

EDIT: Leider nichts aufälliges. Auf beiden Seiten so ziemlich das gleiche was ein und ausgeht.
Laut den Cisco Foren scheint das jedoch in 99% der Fälle wieder ein Routing Problem zu sein.

Hier mal der tcpdump von beiden Seiten.

Standort Other

Code: Alles auswählen

listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
15:06:34.229542 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:34.728356 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:35.728354 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:36.463722 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 401 Unauthorized
15:06:36.464296 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 401 Unauthorized
15:06:36.465945 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 401 Unauthorized
15:06:36.468504 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: ACK sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:36.472879 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:36.476279 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: ACK sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:36.479448 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: ACK sip:telefonnummer@192.168.2.1 SIP/2.0
15:06:36.934870 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 100 Trying
15:06:36.959671 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 183 Session Progress
15:06:37.803671 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 200 OK
15:06:37.826273 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: ACK sip:xxxxxxxxxxxxxxxxxzzzzzzzzzz@192.168.2.1 SIP/2.0
15:07:08.972729 IP SEPECE1A9CD116D.lan.5060 > 192.168.2.1.5060: SIP: BYE sip:xxxxxxxxxxxxxxxxxzzzzzzzzzz@192.168.2.1 SIP/2.0
15:07:09.333853 IP 192.168.2.1.5060 > SEPECE1A9CD116D.lan.5060: SIP: SIP/2.0 200 OK

Standort DE

Code: Alles auswählen

listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
11:06:36.083301 IP 192.168.1.183.sip > fritz.box.sip: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.089773 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 401 Unauthorized
11:06:36.102514 IP 192.168.1.183.sip > fritz.box.sip: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.107979 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 401 Unauthorized
11:06:36.121145 IP 192.168.1.183.sip > fritz.box.sip: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.124303 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 401 Unauthorized
11:06:36.581422 IP 192.168.1.183.sip > fritz.box.sip: SIP: ACK sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.601549 IP 192.168.1.183.sip > fritz.box.sip: SIP: INVITE sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.611700 IP 192.168.1.183.sip > fritz.box.sip: SIP: ACK sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.620352 IP 192.168.1.183.sip > fritz.box.sip: SIP: ACK sip:telefonnummer@192.168.2.1 SIP/2.0
11:06:36.623741 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 100 Trying
11:06:36.673106 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 183 Session Progress
11:06:37.528229 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 200 OK
11:06:37.881288 IP 192.168.1.183.sip > fritz.box.sip: SIP: ACK sip:xxxxxxxxxxxxxxxxxzzzzzzzzzz@192.168.2.1 SIP/2.0
11:07:09.041273 IP 192.168.1.183.sip > fritz.box.sip: SIP: BYE sip:xxxxxxxxxxxxxxxxxzzzzzzzzzz@192.168.2.1 SIP/2.0
11:07:09.049840 IP fritz.box.sip > 192.168.1.183.sip: SIP: SIP/2.0 200 OK

Knogle · Beitrag von **Knogle** » 11.03.2020 22:24:58

Bin leider wieder einen Schritt zurück.
Geht wieder darum dass die Route auf Standort Other Seite mal geht, mal nicht, nun kriege ich sie wieder nicht zum laufen.
Während auf der Standort DE Seite die Route wunderbar in die andere Richtung funktioniert, also der VPN Tunnel läuft.

Gibts da vielleicht noch eine Methode das irgendwie hinzukriegen?

Mich wundert dass in diesem fall traceroute dann bei 192.168.43.1 landet (WLAN Interface).

Vom OpenWRT Device aus (192.168.1.1)

Code: Alles auswählen

root@OpenWrt:~# traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 38 byte packets
 1  10.0.0.1 (10.0.0.1)  324.644 ms  308.101 ms  372.550 ms
 2  *  192.168.2.1 (192.168.2.1)  286.249 ms  316.863 ms

Hier LAN Seite, 192.168.1.187

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.343 ms  0.344 ms  0.445 ms
 2  192.168.43.1 (192.168.43.1)  4.972 ms  5.080 ms  5.364 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Selbst mit

Code: Alles auswählen

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

route -n

route -n

Code: Alles auswählen

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.43.1    0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 wg0
85.197.57.32    192.168.43.1    255.255.255.255 UGH   0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.43.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

EDIT:
Ich denke ich habe es vorerst wieder hingekriegt.

Ich habe der LAN Bridge br-lan als ipv4 Gateway nun knallhart 10.0.0.1 zugewiesen, und jetzt klappt traceroute, und zugriff wieder.

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.448 ms  0.505 ms  0.594 ms
 2  10.0.0.1 (10.0.0.1)  434.965 ms  435.268 ms  435.247 ms
 3  * * 192.168.2.1 (192.168.2.1)  446.648 ms

Hmm, ein Reboot hat trotz gleichem Gateway wieder zur Auslangslage gefuehrt.

debianforum.de

Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken