Nun haben wir auch eine eindeutig Beurteilung und Lösung der Thematik.
Es freut mich für Dich, daß Du eine funktionierende Lösung für Deine Konfiguration gefunden hast.
Bei der o.a. Feststellung würde ich Dir aber nicht zustimmen wollen.
Wenn Du am OpenVPN-Server ein Subnet 192.168.179.1/31 für den tap-Adapter konfigurieren läßt, führt das nur dazu, daß er jede andere Adresse als 192.168.179.0 und 192.168.179.1 als "extern" ansieht und das Paket "ins Routing" geht, anstatt per ARP nach dem Empfänger zu fahnden.
Wenn Du dabei immer noch das tap-Device in die lan-Bridge integrieren läßt (bei 1.+2. schreibst Du explizit, daß die Bridge aktiviert ist, was für mich die Schlußfolgerung nahelegt, daß es bei 3.+4. nicht der Fall ist, bei den VPN-Einstellungen ist sie dann wieder aktiviert
), dann sehe ich da keine eindeutige Ursache, die andere (z.B. Herbie_2005) einfach genauso handhaben könnten, damit es bei ihnen ebenfalls funktioniert (wenn sie nicht im Prinzip ohnehin die gleiche Konfiguration verwenden).
Imho klappt das Ganze deshalb, weil der OpenVPN-Server selbst entscheidet, wann er als Proxy auf ARP-Requests (Layer2) antwortet (wobei nach dem Binden an die Bridge die reale IP-Adresse ohnhin wieder .1/24 ist) und er als Bestandteil der Bridge dann eben auch die dort auftauchenden Frames erhält, mit denen andere Clients (oder auch der Routing-Code auf der FRITZ!Box selbst) nach den Ethernet-Adressen für "lokale" IP-Adressen fragen (also für IP-Adressen, die im selben Segment liegen - wie es die 192.168.179.230 angeblich auch tun würde).
Dann schreit der OpenVPN-Server "hier" anstelle des entfernten Clients (mit der Ethernet-Adresse des tap-Devices) und erhält jetzt das Paket - an eben diese Ethernet-Adresse - für die weitere Verarbeitung. Dann packt er es ein und schickt es an die andere Seite. Bei ankommenden Paketen ist es ziemlich egal, was da als Adressierung drin steht, die werden ausgepackt und direkt "in das Routing gestopft".
Am Ende ist das nach meinem Verständnis eine klassische Ethernet-Bridge und damit bräuchte der OpenVPN-Server im Endeffekt wohl gar keine eigene IP-Adresse dabei für das tap-Interface (nicht mit der lan-Adresse verwechseln, da sind die anderen Dienste alle gebunden). In diesem Anwendungsfall ist es vollkommen ausreichend, wenn er genau weiß, welche Clients (mit welchen IP-Adressen) derzeit verbunden sind und für genau diese muß er dann stellvertretend im LAN antworten und den Traffic an den jeweils richtigen Client senden.
Oder da sind am Ende auch noch zusätzlich diverse Routen gesetzt, die alle auf das tap-Device zeigen und somit den Verkehr ebenfalls direkt (also ohne ARP-Requests) an das tap-Device übergeben, wo der OpenVPN-Server das dann wieder einpackt. Dann müßte es für das Routing eines Pakets an 192.168.179.230 aber schon eine Route mit einer deutlich differenzierteren Maske geben als für das LAN (das ja /24 verwendet) und diese müßte über "dev tap" und nicht "dev lan" gehen (das richtige "dev" ist dann das Äquivalent zu einer Layer2-Adressierung, nur eben schon auf dem Host selbst).
Das wäre dann am Ende ein fröhliches Sammelsurium von Bridge- und Routing-Einstellungen (Layer2+Layer3), wo das eine durchaus auch ohne das andere leben könnte. Spätestens wenn der OpenVPN-Server dann nicht das Standard-Gateway in dem Laden ist und ein "weiter hinten" untergebrachter Service will mit 192.168.179.230 "reden", wird es aber entscheidend, ob da nun per ARP oder per Routing-Table die Pakete für entfernte Standorte "ausgeleitet" werden.
Also bitte nicht falsch verstehen und ich freue mich auch für Dich, wenn es in Deinem Szenario jetzt funktioniert ... aber das ist nur eine (schon sehr spezielle) Lösung und nicht ohne weiteres (also ohne Verständnis, warum es so bei Dir funktioniert) auf andere Installationen übertragbar, besonders dann, wenn diese etwas andere Bedingungen haben sollten. Das Vermischen mehrerer unabhängiger Einstellungen bis es irgendwie funktioniert, ist für mich die Bedeutung von "Gefrickel" (ohne daß damit eine Wertung verbunden ist/sein soll, auch wenn es sich vielleicht auf den ersten Blick anders liest).
Oder ich habe etwas sehr gründlich mißverstanden und den Extrakt der Erkenntnisse nicht begriffen ... daß ich mit den OpenVPN-GUI-Einstellungen anstelle der Konfigurationsdatei "nicht kann", gebe ich ja im anderen Thread auch offen zu. Vielleicht gibt es ja "OpenVPN-Versteher", die die oben stehenden Überlegungen widerlegen / bestätigen können ... würde mich schon interessieren. Daß eine IP-Adresse (als Segment) mit einer /31-Maske eigentlich Unfug ist und im besten Falle nur nicht benutzt wird (wie ich es für Deine Konfiguration ja oben behaupte), wird Dir aber sicherlich jeder Netzwerk-Administrator mit IPv4-Kenntnissen auch bestätigen.
Die - für mich und eine grundsätzliche Lösung - entscheidende Frage, welches Kriterium den dsld nun zur Ablehnung einer Route oder Portweiterleitung bewegt, sehe ich auch nach wie vor unbeantwortet ... damit kann man dieses Kriterium eben nicht gezielt vermeiden. Wenn es bei Dir am Ende beim Hinzufügen des tap-Devices zur lan-Bridge geblieben ist, dann kann es ja eigentlich auch nicht an meiner Vermutung mit dem "unbekannten tap-Device" in der Bridge liegen, sondern eventuell dann wieder eher am Routing.
