auf meiner fritzbox habe ich einen openvpn server installiert, samt tap device ( auf der box ). das verbinden ist kein problem. das habe ich hin bekommen, samt zertifikaten. es können sich also ohne weiteres mehrere clients gleichzeitig per openvpn an die box anmelden.
mein problem ist einfach nur ( an dem ich bald zerbreche ), das sich die clients einfach nicht pingen oder erreichen können. die ganze sache sieht so aus:

das openvpn netzwerk vergibt adressen von 192.168.11.1 bis 192.168.11.254. das kann ich ja auch ohne probleme bei meinen clients sehen per ifconfig.
mein heimnetz von der fritzbox ist 192.168.10.1 bis 192.168.10.254 ( 192.168.10.1 ist natürlich das gateway ).

nun dachte ich mir einfach, das der openvpn server das schon einfach unter sich vernünftig routet. das ich untereinander pingen kann. das geht leider nicht und ich weiß einfach nicht wieso. ich bin leider kein netzwerk-crack.

zum beispiel bekommt ein client die ip adresse 192.168.11.2 ( von meinem openvpn server ). ein rechner, der in meinem heimnetzwerk steht, hat die adresse 192.168.10.4. nun dachte ich eben, man kann ja dann ohne probleme sich untereinander pingen. aber leider nein.

weiß da jemand was?
The Hit-Man schrieb zum beispiel bekommt ein client die ip adresse 192.168.11.2 ( von meinem openvpn server ). ein rechner, der in meinem heimnetzwerk steht, hat die adresse 192.168.10.4. nun dachte ich eben, man kann ja dann ohne probleme sich untereinander pingen. aber leider nein.
Ich bin mit VPNs und openvpn jetzt nicht so fit, aber erstmal ist das Verhalten IMHO richtig so. Ein VPN-Server stellt ja erstmal "nur" sicher, daß der Verkehr zwischen dem VPN-Client und dem Server hoch abgesichert ist - unabhängig vom momentan genutzten Transportweg der Pakete.
Was du willst, ist, daß der VPN-Server auch als VPN-Gateway(Stichwort) ins lokale Netzwerk agiert.

Sind deine jeweilige Netzwerkinterfaces (tap0,eth0,usw.) als Bridge konfiguriert oder als Single-NICs?
Wenn es das OS auf deiner fritzbox erlaubt, zeig doch mal:
ip a (oder ifconfig -a)
ip r (oder route -n)
Hast du dort eine Firewall konfiguriert? Wenn ja, wären die Regeln auch interessant/wichtig (iptables -L z.B.)

Bei deiner Pingerei zwischen 192.168.10 und 192.168.11: Es kann durchaus sein, daß eine Anfrage aus .11. sogar an das .10.er Netz(LAN) geroutet/weitergeleitet wird, das Ping-Antwortpaket kann aber mangels passender Routingregel nicht zurück ins .10.er(tap0). Das Antwortpaket wird dann evtl. ans Default-Gateway (da mangels Regel es kein Interface anehmen will) geschickt, also wahrscheinlich ins "Internet" - Bei deinem VPN-Client kommt die Antwort auf jedenfall nicht an.
Ohne Bridge müssen Routingregeln existieren, die:
a) Pakete aus .10. für .11. von tap0 an eth0 routen/forwarden (statt sie mangels Zuständigkeit an das DefaultGW zu übergeben)
b) und umgekehrt Pakete aus .11. für .10. eben von eth0 an tap0 routen (anstatt DefaultGW).
Ohne diese Regeln ist ja jedes Interface erstmal nur für Pakete von/an sein eigenes Segment(.10. oder .11.) zuständig.

Weiterhin muß fürs Routing im Kernel/Netzwerkstack das Routen/Forwarden von Paketen zwischen verschiedenen Netzwerkkarten/Interfaces erlaubt sein. Stichwort wäre hier "IP Forwarding". Prüfe ggf. mal mit:
sysctl net.ipv4.ip_forward (oder: cat /proc/sys/net/ipv4/ip_forward)
Zwei Links aus der OpenVPN-FAQ:
https://community.openvpn.net/openvpn/wiki/263-openvpn-can-ping-both-peers-but-i-cant-reach-any-of-the-other-machines-on-the-remote-subnet
https://community.openvpn.net/openvpn/wiki/265-how-do-i-enable-ip-forwarding
Etwas spezifischer:
https://community.openvpn.net/openvpn/wiki/BridgingAndRouting
Vielleicht helfen dir diese Wiki-Beiträge ja schon weiter bzw. du findest darüber Stichworte für weitergehende Suche (openvpn Handbücher o.ä.).
oha, sehr kompliziert ... du scheinst da mehr ahnung von zu haben ...

der openvpn server rennt auf der fritzbox ( freetz ). die clients sind alle linux rechner und nein, keine firewall an. habe zwar auf der fritzbox iptables installiert aber keine regeln gesetzt. iptable --list, zeigt nix an.

ich habe auch keine bridge-config installiert auch wenn das freetz-frontend es zu läßt. hatte das auch mal probiert, macht leider keinen unterschied, also bei mir ...

ich kann dir diesen link geben:
https://freetz.github.io/wiki/packages/openvpn

so habe ich das gemacht, vielleicht ist es mit screenshots besser. ich habe die tap variante genutzt.
und ich weiß nicht ob es wichtig ist... habe den server als UPD eingerichtet. so weit ich das gelesen habe, wäre das nicht weiter schlimm. hatte ihn aber auch mal als TCP laufen, machte aber auch keinen unterschied.


ip a

root@fritz:/var/mod/root# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: tunl0: <NOARP> mtu 1480 qdisc noop
link/ipip 0.0.0.0 brd 0.0.0.0
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP300> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 34:31:c4:e7:e8:27 brd ff:ff:ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 34:31:c4:e7:e8:29 brd ff:ff:ff:ff:ff:ff
6: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP200> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 34:31:c4:e7:e8:2f brd ff:ff:ff:ff:ff:ff
7: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP200> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 34:31:c4:e7:e8:30 brd ff:ff:ff:ff:ff:ff
8: ptm_vr9: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qdisc tbf qlen 1000
link/ether 34:31:c4:e7:e8:2d brd ff:ff:ff:ff:ff:ff
9: adsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast qlen 32
link/[19]
10: lan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
link/ether 34:31:c4:e7:e8:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 brd 192.168.10.255 scope global lan
inet 169.254.1.1/16 brd 169.254.255.255 scope global lan:0
inet6 fe80::3631:c4ff:fee7:e827/64 scope link
valid_lft forever preferred_lft forever
11: guest: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
link/ether 34:31:c4:e7:e8:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.181.1/24 brd 192.168.181.255 scope global guest
inet6 fe80::3631:c4ff:fee7:e827/64 scope link
valid_lft forever preferred_lft forever
12: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 100
link/ppp
inet 192.168.10.1/32 scope global dsl
13: wifi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 511
link/ieee802.11 34:31:c4:e7:e8:2b brd ff:ff:ff:ff:ff:ff
14: ath0: <BROADCAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
link/ether 34:31:c4:e7:e8:2b brd ff:ff:ff:ff:ff:ff
48: tap1: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 32:a2:1e:b1:d3:33 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.1/24 brd 192.168.11.255 scope global tap1
root@fritz:/var/mod/root#

ip r
root@fritz:/var/mod/root# ip r
8.8.4.4 dev dsl metric 2
185.55.75.158 dev dsl metric 2
192.168.180.1 dev dsl scope link metric 2
192.168.180.2 dev dsl scope link metric 2
8.8.8.8 dev dsl metric 2
192.168.181.0/24 dev guest scope link src 192.168.181.1
192.168.11.0/24 dev tap1 scope link src 192.168.11.1
192.168.10.0/24 dev lan scope link src 192.168.10.1
169.254.0.0/16 dev lan scope link src 169.254.1.1
default dev dsl scope link metric 2
root@fritz:/var/mod/root#
Und wie sieht es auf dem Client bei bestehender VPN-Verbindung aus?
Soweit ich sehe, ist das Routing auf dem VPNServer in Ordnung, ausreichend.

Folgendes bitte noch beantworten/testen:
a) Das angefragte IP-Forwarding in meinem letzten Post
Es kann schon ausreichen, das einfach mal anzuschalten (//Edit3: wenn es ausgestellt(0) ist) mit
echo 1 > /proc/sys/net/ipv4/ip_forward
oder per
sysctl -w net.ipv4.ip_forward=1
Das ist nur temporär bis zum nächsten Boot, sollte aber sofort wirken (evtl. den VPN-Serverdienst neu starten lassen)

b) In dem von dir angegebenen Link zu freetz:
Diesen Passus hast du gesehen/geprüft (->Fehlersuche)?
"Ein typisches Fehlerbild (ich tippe mal auf mindestens 20% aller Probleme ;-)): Die Verbindung wird aufgebaut, aber der Client und Server können sich nicht per Ping erreichen, es "geht nichts durch das VPN". Häufigste Ursache ist ein nur auf einer Seite aktiviertes "comp-lzo"

c) Kannst du von der fritzbox aus die verbundenen Clients in .10. und .11. anpingen? Und ggf. auch testen: Ping vom Client aus dem LAN(.10.) nach VPN-Client(.11.)
//Edit: Der VPN-Server selbst ist aber von den jeweiligen Clients per ping erreichbar? Also jeweils von Clients aus .10. (eigentlich selbstverständlich), aber auch von Clients aus .11. (per Internet verbunden)? Nur ClientToClient zwischen den Netzen bereitet Probleme?
//Edit2: Mit erreichbar von den VPN-Clients meine ich natürlich: nicht nur ein Ping von einem VPN-Client auf die öffentliche IP-Adresse der Fritbox, sondern ein ping auf die 192.168.11.1 über den VPN-Tunnel!

d) Wie testest du? Sind die VPN-Clients in dem Moment wirklich nur per Internet mit dem VPN-Server verbunden? Ich hatte (AFAIK auch mit OpenVPN) mal den Fehler gemacht, einen VPN-Client zum testen per LAN/WLAN mit ins pysikalische Netz zu hängen. Das funktioniert dann ohne bestimmte, aufwändige Änderungen am openvpn nicht. War also keine korrekte Umgebung zum Testen.

e) Wie sieht deine aktuelle openvpn-ServerConfig-Datei aus?
Müßte sich laut freetz-Doku in /mod/etc/ befinden, also:
cat /mod/etc/openvpn*.conf

f) Weiterhin: kannst du auch mal eine Client-openvpn-Configdatei Posten
Und von einem verbundenen Client auch mal die Routing-Tabelle, bei Linux also dessen
ip r oder route -n
(Andere Betriebssysteme müßtest du rausfinden wie du an die Routing-Tabelle kommst)

g) Ping (also ICMP-Protokoll) kann problematisch sein als Test-Tool, da u.U. Broadcast-Pakete erforderlich sind/anfallen. Diese werden zwischen zwei Netz-Interfaces/Netzen *nicht* geroutet (im Gegensatz zu einer Bridge). Das heißt nun nicht, daß Ping sinnlos ist, aber du könntest zusätzlich auch mal einen anderen Dienst testen.
z.B. per ssh einen VPN-Client(.11.) zu einem Client im LAN(.10.) versuchen zu verbinden. Auf dem LAN-Client muß der ssh-Server natürlich laufen und eingerichtet sein. Das wäre ein Zusatztest unm ggf Probleme mit Ping/Broadcasts auszuschließen.
Nochmal ein //Edit von mir, im Extra-Beitrag:
Zusätzlich zum teils von mir oben schon angeführten, kam mir vorhin noch ein Gedanke; eben daß Dr. Cux (Jehova!) in seinem kurzen, saloppen Beitrag wahrscheinlich sehr nahe "an des Pudels Kern" war.

Ein VPN-Client hat ja
a) sein eigenes lokales Netzinterface (bsp. 192.168.0.120) inkl. ein Routing für dieses Netz (.0.)
b) ein Default-GW zum eigenen Router (->Internet), diese Route ist für alles was bis jetzt nicht explizit eine Route hat.
Nun kommt per VPN-Verbindung noch ein Interface hinzu
c) das VPN-Interface welches von deinem VPN-Server eine IP aus 192.168.11.x bekommt, inkl. einer Route für dieses .11. Netz.

Wenn der Client nun
a) eine Gegenstelle im lokalen LAN anpingt (//Edit: dessen loaklen LAN) geht das über die Route 192.168.0.0/24.
b) deinen VPN-Server anpingt (11.1), dann geht das über die Route 192.168.11.0/24
c) Pakete/Pings für alle andere IP-Adressen werden ans Default-GW gereicht, also an den ISP (soll das Internet sehen wie es die Gegenstelle findet...)
Und hier liegt wohl die Crux (erneutes Wortspiel!):
Wenn dein VPN-Client via VPN nun einen LAN-Client anpingt (aus 192.168.10.0/24), dann gehen diese Pakete momentan auch über das Default-GW zum lokalen Router/ISP (und werden dort verworfen), da es eben **KEINE** Route für das .10.-Segment gibt. Der Client weiß einfach nicht wohin damit. Es müßte also eine Extra-Route geben, die da lautet: Wenn irgendwas nach 192.168.10.x geht dann muß das über das VPN-Interface/Route aus 192.168.11.x geschickt werden, also über den VPN-Tunnel zu deinem VPN_Server. Dieser muß sich dann um das Routing ins LAN (zu dem Client) kümmern (und auch um den Rückweg der Antwortpakete).

Beim OpenVPN (und auch in deinem Freez-Konfig) gibt es AFAIK dafür die sog. Push-Routen. Der VPN-Server teilt beim Verbindungsaushandeln mit dem Client diesem also nicht nur mit: alles für/von 192.168.11.x geht über die Tunnel-Route, sonder eben zusätzlich: Hier, da gibt es noch ein Netz 192.168.10.0/24, wenn du damit kommunizieren willst geht das auch über meinen Tunnel.
In der openvpn.conf auf dem Server gibt es dazu die Option/Eintrag:
push "route 192.168.10.0 255.255.255.0"
(Ebenfalls ggf. noch die Option Client
client-to-client
Diese Push-Route (soweit ich es verstanden habe) wird nun den Clients zusätzlich mitgegeben, eben um Pakete nach 192.168.10.x korrekt routen zu können.
In deiner freetz-Konfig gibt es dieses Eingabefeld für die Pushrouten ja auch, zumindest wie es die Abbildung:
https://freetz.github.io/wiki/packages/openvpn.html#Zertifikate
(runterscrollen bis zum Bild) abbildet:
Im Bild gibt es beim Punkt/Block "VPN IP-Adressen und Routung im VPN" unten bei Optional eine Eingabemaske für die Push-Route. Um bei dir also das zu nutzen solltest du testweise im Eingabefeld "Lokales Netz" mal dein LAN-Netz eintragen, also "192.168.10.0 255.255.255.0"
Danach (nach einem Neuaufbau der Verbindung) sollten(!) die Clients also eine neue, zusätzliche Netzroute eben für 192.168.10.0 in deren Tabelle haben.
Das könnte dann auch den Ping-Fehler beheben (ggf. zusätzlich mit anderen Punkten die ich im anderen Beitrag oben ansprach, z.B. IP_Forwarding). Zumindest von der Client-Seite wäre das dann IMHO sauber, also OK.

So, genug gelabert... ;-)
ich werde das montag mal testen und erstmal danke für eure hilfe !!! ich muß noch dazu sagen, das ich es vor einigen monaten mal halb wegs hin bekommen hatte und zwar per iptables auf der fritzbox ( die sind mit installiert ). allerdings war das ganze nen bischen mühseelig weil ich doch jeden einzelnen rechner ( ip adresse einfügen mußte ). ich habe leider die regeln vergessen 🙁 kann mich aber erinnern das es FORWARD regeln waren. das wäre dann vielleicht die zweite option. aber ich werden eure vorschläge morgen testen.

noch ein nachtrag: an meiner home box, sind schon 2 weitere fritzboxen mit ihrem eigenen VPN zu mir hin verbunden. das eine netz hate die 192.168.178.0 und das andere netz hat die 192.168.177.0. von meinem netz von zu hause aus, komme ich in beide netze per ping rein, kann also die clients hinter den routern ansprechen. allerdings von den netzen 192.168.178.0 und 192.168.177.0 ( mein zu hause hat ja die 192.168.10.0 ) komme ich nur in mein heimnetz rein. also untereinander nicht. da habe ich gesehen, das man in den fritzboxen ein statisches routen zuschalten kann. vielleicht geht es damit.
es soll einfach so sein, das sich alle rechner/clients über meine fritzbox erreichen lassen. der openVPN server läuft natürlich auch noch auf meiner fritzbox mit dem netz 192.168.11.0. dort sollen sich einzelne rechner einwählen können aber dann auch unter allen clients erreichbar sein.

so, jetzt auch genug geredet. ich berichte euch morgen weiter. und noch mal danke !
12 Tage später
so, ich wollte dann mal schnell bescheid geben. habe es wohl hin bekommen 😉 und zwar sieht das ganze so aus ( ich gehe jetzt von dem freetz webinterface aus ):

TAP interface nicht brücken

lokale ipadresse ist: 192.168.11.1 ( das ist die adresse von meinem tap interface in der box für mein OpenVPN )

lokales netz: 192.168.10.0 255.255.255.0 ( da mein lokales netz 192.168.10.1 - 192.168.10.225 geht ). natürlich ist die 192.168.10.1 meine fritzbox ( das gateway ins internet )

ip adressen für die OpenVPN clients habe ich selbst vergeben

client zu client habe ich aktiviert ( aber noch nicht testen können )

die push-route option, brauche ich gar nicht. ich glaube die ist wohl da wenn ich auf die nächste fritzbox ( habe 3 im netz ), drauf zugriff haben mag, von den OpenVPN clients aus.


die sache funtzt bis jetzt so. ich kann mich mit meinem OpenVPN laptop auf meine fritz anmelden und auf mein internes netz ( zu hause ) auch drauf zu greifen, sprich samba service oder meinen drucker.

so wollte ich das auch erstmal haben. der zweite schritt ist ( ich glaube das war nur eine iptables regel ), das keiner von meinen OpenVPN clients über meine fritzbox ins internet darf ( wegen der sicherheit ). die können ja einfach ihr eigenes gateway behalten. so habe ich es auch in den configs der clients eingestellt.
ABER jeder der jetzt bischen ahnung hat, kann in seiner client config, ein redirect gateway auf meiner fritzbox machen. und genau das, möchte ich vermeiden. ich hatte eine iptable regel gehabt, die genau das ausschalten konnte. irgendwas mit drop. ich hoffe, ich finde sie wieder. an sonsten würde ich mich freuen wennjemand von euch vielleicht etwas weiß.

ich sage erstmal vielen dank und werde mal weiter berichten.