[Frage] ARP-Anfragen an WireGuard-Clients mit der MAC-Adresse der FritzBox beantworten.

[BlueEclipse]

Hallo zusammen,

Derzeit habe ich dass Problem , dass meine WireGuard-Clients sich im selben Subnetz wie meine Heimnetzgeräte befinden aber von diesen nicht erreicht werden können . Der Grund ist, dass ARP-Anfragen an die WireGuard-Clients aufgrund des Layer-3-VPNs ins Leere laufen.

Beim integrierten IPsec-VPN der FritzBox antwortet die FritzBox auf ARP-Anfragen an die IPsec-Clients mit ihrer eigenen MAC-Adresse. Genau dieses Verhalten möchte ich auch für meine WireGuard-Clients erreichen.

Die Verknüpfung einer IP-Adresse mit einer MAC-Adresse ist ja prinzipiell kein Problem:

ip neigh add 192.168.189.101 lladdr e0:28:6d:46:38:44 dev lan

In der ARP-Tabelle der FritzBox erscheint dieser Eintrag dann, allerdings mit einem Fragezeichen davor, da die FritzBox kein Gerät mit dieser IP-Adresse kennt. Das sieht dann so aus:

? (192.168.189.101) at e0:28:6d:46:38:44 [ether] PERM on lan

Theoretisch sollte dass kein Problem sein , denn die IPsec-Clients tauchen ebenfalls nicht in der ARP-Tabelle auf (was auch Sinn ergibt, da sie nicht direkt im Layer-2-Netzwerk sind).

An dieser Stelle komme ich jedoch nicht weiter:
Hat jemand eine Idee, wie ich die FritzBox dazu bringen kann, auf ARP-Anfragen an die WireGuard-Geräte mit ihrer eigenen MAC-Adresse zu antworten?

 

[PeterPawn]

Da braucht man halt einen Daemon für Proxy-ARP (RFC 1027) auf der Box. Es gäbe verschiedene Implementierungen in C (z.B. parpd oder choparp), die sich auch mit der Cross-Compiler-Toolchain von Freetz-NG übersetzen lassen sollten, wenn Freetz-NG selbst kein passendes Paket bereithält (was ich nicht weiß, das originale Freetz hat(te) m.W. kein entsprechendes Paket).

Wie das mit dem Proxy-ARP beim FRITZ!OS funktioniert (und auch, daß es nur bei VPN-Verbindungen für einzelne Clients verwendet wird), ist hier im Board mehrfach thematisiert worden - man kann (oder sollte) sich aber vielleicht auch mal fragen, ob es tatsächlich erforderlich ist, die VPN-Clients mit IP-Adressen aus dem lokalen Segment zu betreiben. Macht man das nämlich nicht, hat jedes wgX-Interface sein eigenes Subnetz (Segment) und es reicht das "normale" Routing.

 

[BlueEclipse]

Es gäbe verschiedene Implementierungen in C (z.B. parpd oder choparp), die sich auch mit der Cross-Compiler-Toolchain von Freetz-NG übersetzen lassen sollten, wenn Freetz-NG selbst kein passendes Paket bereithält (was ich nicht weiß, das originale Freetz hat(te) m.W. kein entsprechendes Paket).

Leider enthält Freetz-NG kein Paket, das für Proxy-ARP verwendet werden könnte.

Ich habe mich aber jetzt für choparp entschieden und das Ganze bereits mit dem Userspace-Cross-Compiler von Freetz-NG gebaut.

Allerdings startet es momentan noch nicht auf der Box aufgrund eines 'not found'-Fehlers.

Ich vermute mal, dass ich einige statische Bibliotheken vergessen habe, in den Build mit reinzubauen ( da ich nicht weiß was aktuell schon auf der Box ist, versuche ich erstmal alles statisch zu bauen).

man kann (oder sollte) sich aber vielleicht auch mal fragen, ob es tatsächlich erforderlich ist, die VPN-Clients mit IP-Adressen aus dem lokalen Segment zu betreiben. Macht man das nämlich nicht, hat jedes wgX-Interface sein eigenes Subnetz (Segment) und es reicht das "normale" Routing.

Das eigene Subnetzt für jedes Wireguard Interface wäre definitiv die Lösung, die ich aufgrund der Einfachheit bevorzugen würde, aber leider kann ich das nicht, da ich von außerhalb per Telnet auf zwei Geräte zugreifen muss, die aber alle Telnet-Anfragen blockieren, die nicht aus ihrem Subnetz kommen.