1. OpenVPN erfordert für das eigene Kompilieren der Programme vielleicht Freetz, aber nicht für den Betrieb auf der Box.
2. Das AVM-VPN braucht tatsächlich den Router-Mode, weil es ein WAN-Interface benötigt. Bei OpenVPN ist das anders, nichts weiter wollte ich zum Ausdruck bringen. Ob, wie und wo der TE bereits OpenVPN einsetzt, spielt für diesen Aspekt (eine FRITZ!Box im "IP-Client-Mode" kann trotzdem als OpenVPN-Gateway dienen) gar keine Rolle, das war rein die Erwähnung einer anderen Möglichkeit, ein VPN zu verwenden und der Widerspruch dagegen, daß dafür unbedingt der "Router-Modus" der FRITZ!Box aktiv sein müsse. Das bezieht sich auch nur auf das, was hier im Normalfall als "Router-Mode" betrachtet wird, da ist nicht das reine IPv4-Forwarding mit gemeint und genau das funktioniert eben mit passender Konfiguration auch bei einer FRITZ!Box, solange sie mind. zwei Interfaces hat (das kann auch ein virtuelles wie TUN/TAP sein), zwischen denen ein Forwarding möglich oder notwendig ist. Die Frage, welche Änderungen an einer FRITZ!Box dafür notwendig wären, steht auf einem anderen Blatt.
3. In dem vom TE in #6 geschilderten Szenario hilft auch eine FRITZ!Box im Router-Modus erst einmal gar nichts. Wenn die Clients direkt hinter dem Comcast-Router hängen und da ist die FRITZ!Box ebenfalls als Client (im Router-Modus und mit ihrem WAN-Interface, also als kaskadierter Router) eingebunden wird, dann kann sie nicht gleichzeitig in demselben LAN mit ihrem eigenen LAN-Interface präsent sein - sie kann ja nicht auf dem WAN- und dem LAN-Interface dieselbe Konfiguration verwenden. Da fehlen dann also mindestens mal weitere Details, wie Du Dir das vorstellen würdest (komme ich später noch mal drauf zurück).
4. Auch bei Verwendung eines zweiten (logischen) Netzwerks auf derselben L2-Struktur ist eine "manuelle Umschaltung" des Gateways für einen einzelnen Client nur mit einer anderen Interface-Konfiguration für einen Client verbunden - bei Linux (oder anderen Systemen mit passender Unterstützung) wäre das sogar mit "network namespaces" zu lösen, daß nur Pakete für bestimmte Ziele an das eine Gateway gehen und andere wieder an ein zweites (sogar eine Lastverteilung wäre denkbar). Alternativ oder für andere Systeme (ich nehme mal solche aus, wo der Besitzer gar keine "händische" IP-Konfiguration im erforderlichen Umfang vornehmen kann, aber selbst für Windows funktioniert das) läßt sich das mit zwei IP-Adressen auf demselben Interface und passenden Einträgen in der Routing-Tabelle (bei der Angabe "next hop") auch ohne "namespaces" so konfigurieren, daß sie für bestimmte Ziele (eines davon ist die Standard-Route, auch die kann man bekanntlich ändern, selbst wenn man eine Konfiguration per DHCP erhalten haben sollte (was hier noch nicht einmal als Bedingung angegeben ist)) verschiedene Gateways benutzen. Das setzt aber tatsächlich eine (ggf. umfangreiche) Anpassung der Netzwerk-Konfiguration jedes einzelnen Gerätes im LAN voraus, welches ein anderes Gateway benutzen soll. Aber das sind eigentlich getrennte Aspekte ... die Verwendung eines abweichenden Gateways oder eines zweiten logischen Netzes (solange "Abhörsicherheit" zwischen diesen Netzen im LAN kein Thema ist) hat ja erst einmal nichts damit zu tun, ob eines dieser Gateways den Traffic im Anschluß über ein VPN sendet oder nicht.
5. Nach #6 wäre eine Möglichkeit tatsächlich eine FRITZ!Box (oder besser noch ein zusätzlicher RasPi wg. der Leistung, wobei das vom Traffic-Aufkommen abhängig ist), wo das System aus dem LAN eingehende Pakete mit einer Ziel-IP, die nicht der eigenen entspricht (für die sie also als "gateway" fungieren soll, sonst würden die ja gar nicht bei ihr landen), über OpenVPN einpackt und diesen VPN-Traffic dann über die Internetverbindung des Comcast-Routers zur Endian-Firewall weiterleitet. Warum sollte das nicht funktionieren? Bitte einfach eine "technische" Erklärung, was aus Netzwerksicht dagegen spricht (im Kontext von #6 wohlgemerkt).
6. Will man unbedingt das AVM-VPN (IPSec mit IKEv1) verwenden, könnte man den Weg nach 4. nehmen ... bei einer Gegenstelle, die auch andere Möglichkeiten bietet, ist das aber vielleicht die zweitbeste Lösung.
6. Was willst Du mir (oder uns) mit
HabNeFritzbox schrieb:
Und als IP Client gibt es im WebIF keine Firewall, Routen oder VPN, da die FB als Switch mit Extras läuft.
sagen?
Ich habe nie behauptet, daß es im IP-Client-Mode der FRITZ!Box keine Einschränkungen gäbe oder (wie Du in #8), daß eine FRITZ!Box im Router-Modus für den TE (weil Du darauf solchen Wert legst am Beginn von #8) eine Lösung beim Szenario nach #6 wäre. Ich habe in #2 geschrieben, daß es im IP-Client-Mode kein AVM-VPN gibt - period (steht immer noch oben) - und daß mangels WAN-Interface das (AVM-)VPN auch nicht funktionieren kann oder wird, selbst wenn man irgendwie die Dienste starten könnte.
Dabei meinte ich tatsächlich das fehlende zweite Interface - ohne ein solches wird gar keine (herkömmliche) VPN-Lösung funktionieren, denn irgendwo muß der unverschlüsselte ja vom verschlüsselten Traffic unterschieden werden. Da die beliebteste VPN-Lösung mit "virtuellen" Interfaces (das sind die TUN/TAP-Devices) nun mal OpenVPN ist, habe ich das als Beispiel angeführt und das Anlegen eines TUN/TAP-Interfaces funktioniert auch auf einer FRITZ!Box im IP-Client-Mode ... aber natürlich nicht über das GUI, das war aber auch keine Bedingung seitens des TE und die reine Erwähnung, daß man auf einer FRITZ!Box auch andere VPN-Lösungen als das AVM-VPN benutzen könnte, kann auch kaum OT oder verboten sein. Die "Eingangsfrage" war also nach der Antwort in #2 eigentlich "durch". Wenn ich dann auf Deine Nachfrage antworte und OpenVPN als Beispiel für eine VPN-Lösung anführe, die auch ohne "Router-Mode" funktioniert, nachdem Du den als Voraussetzung postuliert hast (so habe ich jedenfalls Dein
HabNeFritzbox schrieb:
Statt "Interface" passt wohl Routing besser bei dir [...]
verstanden), gilt das nicht mehr direkt der Frage des TE.
Die Auskunft, daß es mit einer Box im Client-Mode nicht funktionieren kann, hat der TE seit #2, die Auskunft in #8 (m.E. bei Berücksichtigung der Angaben in #6 wenig zielführend, solange sie so lapidar erfolgt), daß das AVM-VPN im Router-Modus funktionieren würde, hat er nun auch. Auf der Suche nach einer Lösung (#6) hat er auch noch Alternativen genannt bekommen.
Warum ein VPN-Gateway nun unbedingt noch eine eigene Firewall haben oder gar NAT benutzen muß (#5), müßte man vielleicht mal begründen ... solange die Gegenstelle (hier die Endian-Firewall) ihrerseits nur "erlaubte" Daten in den VPN-Tunnel steckt, braucht das Gateway auf der anderen Seite sich um eine Filterung (für ingress) keine Gedanken zu machen und für egress (a la Kindersicherung in der FRITZ!Box) machen das auch nur die wenigsten Consumer-Router (und es war hier auch nicht Teil der Aufgabenstellung).
