Devices via VPN ins Lokale Netzwerk brücken

[bluestar]

Probiere mal nun ein bisschen mit den Regeln rum. "Forward" war angeblich auf DROP eingestellt. INPUT OUTPUT auf ACCEPT.

Nutzt du die WebGUI dafür ?

[Knogle]

Probiere mal nun ein bisschen mit den Regeln rum. "Forward" war angeblich auf DROP eingestellt. INPUT OUTPUT auf ACCEPT.

Nutzt du die WebGUI dafür ?

Genau, weil wenn ich das mit iptables mache sind nach kurzer Zeit die Einstellungen wieder überschrieben.
Sonst habe ich für meine Tests mit Wireguard immer vorher

Code: Alles auswählen

iptables -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

gemacht

[bluestar]

Nutzt du die WebGUI dafür ?

Genau, weil wenn ich das mit iptables mache sind nach kurzer Zeit die Einstellungen wieder überschrieben.
Sonst habe ich für meine Tests mit Wireguard immer vorher

Dann kann ich auf meinem Aquarium RasPi mal schauen, ob ich dir da die Regeln "zusammengeklickt" bekomme.

[Knogle]

Nutzt du die WebGUI dafür ?

Genau, weil wenn ich das mit iptables mache sind nach kurzer Zeit die Einstellungen wieder überschrieben.
Sonst habe ich für meine Tests mit Wireguard immer vorher

Dann kann ich auf meinem Aquarium RasPi mal schauen, ob ich dir da die Regeln "zusammengeklickt" bekomme.

Das würde mich freuen.
Das Pingen vom Laptop aus klappt doch, jedoch nur als root .
Muss aber schauen warum sich Wireguard verabschiedet hat, angeblich fehlt jetzt ein Public Key am Interface, obwohl ich daran nichts verändert habe.
Ich setze erstmal OpenWRT neu auf, ich denke ich habe die Konfig inzwischen ziemlich geschrottet

Folgende Besonderheit habe ich noch.

Damit ich eine Verbindung von den LAN Geräten über das WLAN Radio kriege, musste ich eine relayd bridge zwischen eth0 und wwan0 (wlan) erstellen, und einer im OpenWRT Forum meinte das klappt so auf keinen Fall, Grund wurde mir nicht genannt.
Finde ich auch eher unplausibel, da es ja immer bzw. manchmal irgendwie dann doch klappt, und gestern über 3 Stunden.

EDIT: Habe mal alle Firewall regeln rausgeschmissen so dass ich am ende nur noch

Code: Alles auswählen

 FORWARD ACCEPT OUTPUT ACCEPT INPUT ACCEPT

hatte, aber auch da klappt das eher sporadisch.

[Knogle]

Eine mögliche Fehlerquelle konnte ich schon rauswerfen, undzwar die relayd Brücke zwischen LAN und WLAN (192.168.43.1) war komplett überflüssig.
Nun probiere ich nochmal.

Kann das Remote wg0 schonmal anpingen, nur noch die Route eben basteln.
Im Webinterface kriege ich die Route momentan nicht hin.
Nur in der Konsole via

Code: Alles auswählen

ip route add 192.168.2.0/24 via 10.0.0.1

Die klappt dann auch bei allen LAN devices.Jetzt teste ich nochmal das Telefon.
Klappt. Bleibt erstmal nur noch das One-way-audio Problem.

Von der Gegenrichtung DE -- > Other sieht das Pingen so aus.

Code: Alles auswählen

[chairman@millenium-fbe48 ~]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 57.2.168.192)
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=315 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=313 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=313 ms

Fakt ist, nachdem ich die Route auf DE Seite richtung Other eingerichtet habe, hatte zumindest ich Ton.
Ist es da nicht naheliegend das evtl. andersrum, das Problem wieder auf OpenWRT Seite liegt?

Habe mal den traffic gesnifft nachdem die Verbindung beim Anruf hergestellt war, und ich reingebruellt habe, da kommen keine Pakete richtung 192.168.2.1. Erst wenn aufgelegt wird, kommt das BYE paket.

Mal die RTP Ports gecheckt, da kommt reichlich traffic in beide Richtungen.
Laut dem Web GUI des Telefons geht ebenfalls RTP Traffic raus. Wie findet man am besten raus wo der hängen bleibt?

EDIT:
Die Fritzbox hat zum Glueck eine tolle Uebersicht.
Angeblich geht auch ein Signal raus. Aber trotzdem hoert das gegenueber nix.
Ist die Frage ob man dem so trauen kann. Kann man bei tcpdump nach Ursprung filtern?

EDIT2:
Die Route nach 192.168.2.0 klappt nun auch, habe diese via Wireguard erstellen lassen.
Am Ende wenn alles klappt werde ich den ganzen Vorgang mal als Loesung zusammenfassen falls jemand den Thread hire ausgraben sollte.
Werde Wireguard aufjedenfall weiter propagieren, scheint ja trotz allem nochmal deutlich einfacher zu sein als mit OpenVPN.

EDIT3:
Scheint wohl irgendwie ein Einstellungsproblem mit dem Telefon zu sein.
Pakete gehen in beide Richtungen bei der Fritte

https://www.ip-phone-forum.de/attachmen ... ng.104628/

EDIT4:
Hat noch jemand einen Tipp wie ich meine Fritzbox als DNS Server nehmen kann, um die Hostnames auf 192.168.2.X aufzulösen?

EDIT5:
Nächster Schritt meiner Meinung nach wäre mal die RTP Pakete vom Telefon ausgehend zu speichern, und zu schauen was da alles gesagt wird (Hoffe RTP ist nicht verschlüsselt)

[mat6937]

EDIT4:
Hat noch jemand einen Tipp wie ich meine Fritzbox als DNS Server nehmen kann, um die Hostnames auf 192.168.2.X aufzulösen?

Wenn Du WireGuard mit wg-quick benutzt, dann kannst Du den DNS-Server in der [Interface]-Section der wg#.conf-Datei eintragen. Siehe z. B. die manage zu wg-quick:

DNS — a comma-separated list of IP (v4 or v6) addresses to be set as the interface's DNS servers. May be
specified multiple times. Upon bringing the interface up, this runs `resolvconf -a tun.INTERFACE -m 0
-x` and upon bringing it down, this runs `resolvconf -d tun.INTERFACE`. If these particular invocations
of resolvconf(8) are undesirable, the PostUp and PostDown keys below may be used instead.

[Knogle]

Danke dir werde ich mal probieren.
Aber auf welcher Seite muss ich das konfigurieren? Auf der Client oder auf der Serverseite?
Bei der Clientseite wird schwierig da ich das via GUI gemacht habe, und es da diese Option nicht gibt.
Habe gerade nochmal

Code: Alles auswählen

 tcpdump -i wg0 udp port 5060 or udp portrange 7078-7110 -s 0

gemacht um herausfzufinden warum der Ton nur in eine Richtung geht.
Dabei wird auf "Client" Seite gesagt dass 10 Pakete vom Kernel gedroppt wurden.
Wie finde ich raus was das genau ist?

[Knogle]

So ich bin nun weiter.
Habe das ganze nun im Cisco Forum gepostet, und es scheint wohl ein NAT Problem irgendwie zu geben, oder ein Bug, wie auch immer das zustandekommt.
https://community.cisco.com/t5/voice-sy ... lse#M55766

Die Pakete gehen Problemlos Richtung Router, aber in die Rückrichtung gehen die wohl nur zum VPN Server im jeweiligen Netzwerk, und das wars dann.
Hat jemand ein Tipp wie ich so ein NAT Problem ausfindig machen kann? Ich wüsste nähmlich nicht wo ich NAT aktiviert habe.

[unitra]

Der Lösungsansatz ist beschrieben, und das Problem ist da in dem Forum gelöst.

...It seems you have two LAN, both under your control, interconnected by VPN tunnel. Both LANs are using non overlapping IP network range, so they are routable. So whay you are using NAT on the path at all ? It should not be necessary. No NAT mean no NAT issues ...

Wenn ein vollgeroutetes Netz vorhanden ist zwischen beiden Sites dann ist ein NAT nicht notwendig.

Nachdem ich die Skizze im ciscoforum gesichtet habe, https://kxiwq67737.i.lithium.com/t5/ima ... 1.0&px=999 und verglichen habe mit der Skizze hier im Forum am Anfang des Beitrags gepostet ist, ich vermute das Problem liegt darin dass die Tunnelendpunkte (IPSec Terminatoren) und die statischen Routen auf verschiedenen Endgeräten liegen. Die Tunnel sollten zwischen beiden Routern aufgebaut werden, dann würde das funktionieren.
Erschwerend hinzu kommt noch dass da irgendowo Packetfilter/IPTables eingeschaltet ist.

An diesem Punkt ist es schwer hier etwas Hilfreiches zu antworten weil nicht bekannt ist welche Skizze stimmt, und aus der Skizze ist nicht ersichtlich welche Endgeräte die Tunnel aufbauen, und man kann nicht erkennen wo die statischen Routen gesetzt wurden.

[Knogle]

Der Lösungsansatz ist beschrieben, und das Problem ist da in dem Forum gelöst.

...It seems you have two LAN, both under your control, interconnected by VPN tunnel. Both LANs are using non overlapping IP network range, so they are routable. So whay you are using NAT on the path at all ? It should not be necessary. No NAT mean no NAT issues ...

Wenn ein vollgeroutetes Netz vorhanden ist zwischen beiden Sites dann ist ein NAT nicht notwendig.

Nachdem ich die Skizze im ciscoforum gesichtet habe, https://kxiwq67737.i.lithium.com/t5/ima ... 1.0&px=999 und verglichen habe mit der Skizze hier im Forum am Anfang des Beitrags gepostet ist, ich vermute das Problem liegt darin dass die Tunnelendpunkte (IPSec Terminatoren) und die statischen Routen auf verschiedenen Endgeräten liegen. Die Tunnel sollten zwischen beiden Routern aufgebaut werden, dann würde das funktionieren.
Erschwerend hinzu kommt noch dass da irgendowo Packetfilter/IPTables eingeschaltet ist.

An diesem Punkt ist es schwer hier etwas Hilfreiches zu antworten weil nicht bekannt ist welche Skizze stimmt, und aus der Skizze ist nicht ersichtlich welche Endgeräte die Tunnel aufbauen, und man kann nicht erkennen wo die statischen Routen gesetzt wurden.

Danke dir.
Die Skizze aus dem Cisco Forum ist nun die korrekte Variante.
In der Tatsache ist es tatsächlich so, dass die statische Route und der VPN Peer nicht auf dem selben Endgerät liegen.
Der VPN Peer ist ein eigenes Endgerät im Netzwerk 192.168.2.0, und hat die von der Fritzbox zugewiesene IP 192.168.2.57.
Die statische Route von der Fritzbox (192.168.2.1) auf 192.168.1.0 geht via 192.168.2.57.

Umgekehrt, beim OpenWRT Fall, liegt die statische Route 192.168.2.0 via 10.0.0.1 auf dem gleichen Device wie auch das VPN Ding (192.168.1.1).
iptables -P INPUT ACCEPT OUTPUT ACCEPT und FORWARD ACCEPT sind zum Testzeitpunkt auf dem OpenWRT Gerät, und dem Wireguard Gerät auf 192.168.2.57 aktiv.
Die Fritzbox ist ja leider eher ne Blackbox weil man da ja nicht wirklich viel machen kann.

[mat6937]

In der Tatsache ist es tatsächlich so, dass die statische Route und der VPN Peer nicht auf dem selben Endgerät liegen.
Der VPN Peer ist ein eigenes Endgerät im Netzwerk 192.168.2.0, und hat die von der Fritzbox zugewiesene IP 192.168.2.57.

BTW: Kannst Du mit deinen Geräten die _miteinander in einem VPN kommunizieren_ sollen, einen bestimmten "Endpoint" erreichen bzw. auf diesen Geräten den WireGuard installieren? Wenn ja, dann konfiguriere auf diesem "Endpoint" den WireGuard-Server und auf jedem anderen Gerät einen WireGuard-Client.

[Knogle]

In der Tatsache ist es tatsächlich so, dass die statische Route und der VPN Peer nicht auf dem selben Endgerät liegen.
Der VPN Peer ist ein eigenes Endgerät im Netzwerk 192.168.2.0, und hat die von der Fritzbox zugewiesene IP 192.168.2.57.

BTW: Kannst Du mit deinen Geräten die _miteinander in einem VPN kommunizieren_ sollen, einen bestimmten "Endpoint" erreichen bzw. auf diesen Geräten den WireGuard installieren? Wenn ja, dann konfiguriere auf diesem "Endpoint" den WireGuard-Server und auf jedem anderen Gerät einen WireGuard-Client.

Genau das ist das Problem. In dem Fall Fritzbox und VoIP Telefon, beides ist leider nicht möglich.

[mat6937]

Genau das ist das Problem. In dem Fall Fritzbox und VoIP Telefon, beides ist leider nicht möglich.

Wenn es deine eigene FritzBox ist (d. h. kein Zwangsrouter), dann sollte "WireGuard mit Freetz" für die FritzBox möglich sein. Siehe z. B.: https://github.com/Freetz/freetz/tree/m ... /wireguard

[Knogle]

Genau das ist das Problem. In dem Fall Fritzbox und VoIP Telefon, beides ist leider nicht möglich.

Wenn es deine eigene FritzBox ist (d. h. kein Zwangsrouter), dann sollte "WireGuard mit Freetz" für die FritzBox möglich sein. Siehe z. B.: https://github.com/Freetz/freetz/tree/m ... /wireguard

Leider kann ich das andere Netzwerk physisch erst in 4 Monaten wieder erreichen.
Da wäre es der Super-GAU wenn ich das Ding abschießen würde.

Klingt fast so als wäre Bridging wohl doch wieder die bessere Option.

[Knogle]

Problem gelöst!
Habe auf dem Wireguard Device alle NAT Regeln gelöscht, und nun klappt es prima, Sprachübertragung in beide Richtungen! Alles nun so wie es soll! Vielen Dank euch allen für die Mühe!
Wäre nur noch prima die Sache mit dem DNS, auf welchem Device muss ich das einrichten mit wg quick?

[mat6937]

Wäre nur noch prima die Sache mit dem DNS, auf welchem Device muss ich das einrichten mit wg quick?

DNS brauchst Du auf den WireGuard-Clients, weil dort in der [Peer]-Section u. a. auch:

Code: Alles auswählen

Endpoint = ...

konfiguriert ist und dafür evtl. eine Namensauflösung erforderlich ist.
Evtl. kannst Du auch die DNS-Server aus der /etc/resolv.conf, die via DHCP dort eingetragen/zugewiesen werden, benutzen. Wenn der Eintrag dort über resolvconf gemacht wird, dann kannst Du, falls erforderlich, in der [Interface]-Section statt "DNS = ...", auch:

Code: Alles auswählen

PreUp = /sbin/resolvconf -u

konfigurieren/eintragen.