Layer 3: Probleme mit wireguard wenn nur IPv4 am WAN vorhanden #286

New Issue

ChristianD · 2023-04-16T16:35:07+02:00

ChristianD commented

2023-04-16 16:35:07 +02:00

Wenn an einem Router am WAN nur IPv4 vorhanden ist und man schon einen wireguard offen hat der mit dem Freifunknetz funktioniert wo sowohl v4 als auch v6 konfiguriert ist, man anschließend einen 2. Wireguard konfiguriert mit DNS der sowohl A als auch AAAA hat, dann versucht wireguard dies mit IPv6 (zu sehen wenn man wg eingibt). Dank Blackhole Rule schlägt das zwar fehl so das zumindest der Tunnel nicht durchs Freifunk aufgebaut wird, funktionieren tut er aber natürlich nicht.

fbl added the

bug

layer3

labels 2023-04-16 20:49:10 +02:00

fbl commented

2023-04-16 20:55:02 +02:00

Das Problem besteht schon seit Anfang an. Problematisch ist hier, dass für Wireguard nur eine einzelne Adresse für den Peer festgelegt werden kann. Das Auflösen von DNS nach Adresse macht der OpenWrt netifd (afaik) direkt beim Starten des Tunnelinterfaces. Ist zum Zeitpunkt der Namensauflösung eine IPv6 default-Route (?) verfügbar, dann wird AAAA aufgelöst, andernfalls A.

Da eine IPv6 Default Route verfügbar ist sobald wir mit dem Freifunk-Netz verbunden sind, wird ab dann auch immer AAAA aufgelöst, auch wenn der WAN-Anschluss eigentlich gar kein IPv6 verfügbar hat.

Die Problematik des Verhaltens hält sich in Grenzen, da das ganze nur ein Problem ist, wenn nachträglich Tunnel hinzugefügt werden. Wird der Tunnel bereits vor der Verbindung mit dem Freifunk-Franken Netz gestartet, dann ist keine IPv6 Default-Route verfügbar und es wird der A Record aufgelöst.

Das Problem sollte sich zumindest zum Teil mit der Implementierung von #270 lösen, denn dann sind die Freifunk-Routen nicht mehr für den WAN VRF sichtbar.

Damit wir mit wirklich jedem Fall umgehen können, müssten eigentlich regelmäßig beide IP-Protokolle und ggf. mehrere vorhandene Records ausprobiert werden, solange die Wireguard-Verbindung inaktiv ist. Das ist allerdings nicht so einfach, da ein Wireguard keinen Verbindungszustand hat.

Das Problem besteht schon seit Anfang an. Problematisch ist hier, dass für Wireguard nur eine einzelne Adresse für den Peer festgelegt werden kann. Das Auflösen von DNS nach Adresse macht der OpenWrt netifd (afaik) direkt beim Starten des Tunnelinterfaces. Ist zum Zeitpunkt der Namensauflösung eine IPv6 default-Route (?) verfügbar, dann wird AAAA aufgelöst, andernfalls A. Da eine IPv6 Default Route verfügbar ist sobald wir mit dem Freifunk-Netz verbunden sind, wird ab dann auch immer AAAA aufgelöst, auch wenn der WAN-Anschluss eigentlich gar kein IPv6 verfügbar hat. Die Problematik des Verhaltens hält sich in Grenzen, da das ganze nur ein Problem ist, wenn nachträglich Tunnel hinzugefügt werden. Wird der Tunnel bereits vor der Verbindung mit dem Freifunk-Franken Netz gestartet, dann ist keine IPv6 Default-Route verfügbar und es wird der A Record aufgelöst. Das Problem sollte sich zumindest zum Teil mit der Implementierung von #270 lösen, denn dann sind die Freifunk-Routen nicht mehr für den WAN VRF sichtbar. Damit wir mit wirklich jedem Fall umgehen können, müssten eigentlich regelmäßig beide IP-Protokolle und ggf. mehrere vorhandene Records ausprobiert werden, solange die Wireguard-Verbindung inaktiv ist. Das ist allerdings nicht so einfach, da ein Wireguard keinen Verbindungszustand hat.

Sign in to join this conversation.