OpenVPN-Server mit privater IP im Heimnetz verfügbar?

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
A

arnuschky

Neuer User
Mitglied seit
8 Jan 2006
Beiträge
36
Punkte für Reaktionen
0
Punkte
0
Hey,

wir haben einen Server im Internet stehen auf den ich gerne von zu Hause aus so zugreifen würde, als würde er bei uns daheim stehen. Das ganze funktioniert schon von meinem Laptop aus wenn ich unterwegs bin, der Tunnel wird auch von Freetz 2.0 einwandfrei aufgebaut und ich kann den Server pingen. Nur vom Heimnetz aus gehts leider nicht.

Details:

Code: 
                   lan                        vpn
[   Desktop   ] ---------- [    Freetz    ] --------- [  Server    ]
 192.168.23.25              192.168.23.254             192.168.23.1

Lokales Netz: 192.168.23.0/24
VPN Netz: 10.8.0.0/24

Ich würde gerne den Server mit einer IP im 23er Netz sehen (zB. 192.168.23.1). Ich habe das bisher mit einem Alias auf eth0:1 und einer pushroute (push "route 192.168.23.1 255.255.255.255") hinbekommen.

Verbinde ich mich mit meinem Laptop an den VPN server, kann ich auf 192.168.23.1 zugreifen. Von Freetz aus funktioniert das auch. Vom Desktop aus leider nicht, auch wenn ich eine Hostroute setze (route add -host 192.168.23.1 gw 192.168.23.254).

Was läuft da falsch?

Mein OpenVPN-Konfig ist derzeit TUN mit Zertifikaten, nix spezielles ausser der Pushroute.

Frohes Neues,
Arnuschky
 
arnuschky schrieb:
Vom Desktop aus leider nicht, auch wenn ich eine Hostroute setze (route add -host 192.168.23.1 gw 192.168.23.254).
Zum Vergrößern anklicken....
Wie sind von der FritzBox (Freetz) die Ausgaben von:
Code: 
route -n
Code: 
iptables -nvx -L POSTROUTING -t nat
und vom Desktop die Ausgaben von:
Code: 
route -n
Code: 
ping -c 4 -I 192.168.23.25 192.168.23.1
?
 
sf3978 schrieb:
Wie sind von der FritzBox (Freetz) die Ausgaben von:
Code: 
route -n
Zum Vergrößern anklicken....

Code: 
root@fritz:/var/mod/root# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.23.1    10.8.0.9        255.255.255.255 UGH   0      0        0 tun0
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
10.8.0.9        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.23.0    0.0.0.0         255.255.255.0   U     0      0        0 lan
10.8.0.0        10.8.0.9        255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

sf3978 schrieb:
Code: 
iptables -nvx -L POSTROUTING -t nat
Zum Vergrößern anklicken....

Code: 
-sh: iptables: not found

Upps. Das sollte wohl nicht so sein. Ich hab mal nachgeschaut, ich kann keine Option zu iptables in meiner Freetz-config finden. Was läuft da falsch? Ich hab übrigens ne 7050, wir da evtl. was automatisch disabled?

sf3978 schrieb:
und vom Desktop die Ausgaben von:
Code: 
route -n
Zum Vergrößern anklicken....

Code: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.23.254  0.0.0.0         UG    0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.23.0    0.0.0.0         255.255.255.0   U     2      0        0 wlan0

Standard halt. Hab in dem Fall die Hostroute auch noch nicht gesetzt. Sollte ja wohl, oder? Kann man das über den Freetz-DHCP machen?

sf3978 schrieb:
Code: 
ping -c 4 -I 192.168.23.25 192.168.23.1
Zum Vergrößern anklicken....

Code: 
PING 192.168.23.1 (192.168.23.1) from 192.168.23.22 : 56(84) bytes of data.
From 192.168.23.22 icmp_seq=1 Destination Host Unreachable

Danke schonmal für die Antwort!
 
Code: 
eth0      Link encap:Ethernet  HWaddr 00:1f:16:25:a1:7d  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:15146 errors:0 dropped:213 overruns:0 frame:0
          TX packets:20010 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2794184 (2.7 MB)  TX bytes:9375666 (9.3 MB)
          Interrupt:20 Memory:f2700000-f2720000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:87677 errors:0 dropped:0 overruns:0 frame:0
          TX packets:87677 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:280750407 (280.7 MB)  TX bytes:280750407 (280.7 MB)

wlan0     Link encap:Ethernet  HWaddr 00:21:6a:c2:17:8e  
          inet addr:192.168.23.22  Bcast:192.168.23.255  Mask:255.255.255.0
          inet6 addr: fe80::221:6aff:fec2:178e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2127859 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1603512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2228238713 (2.2 GB)  TX bytes:506176276 (506.1 MB)

Sorry, hatte vergessen dazuzuschreiben dass ich inzwischen auf der .22 sitze. Hatte dementsprechend oben auch "ping -c 4 -I 192.168.23.22 192.168.23.1" ausgeführt.
 
arnuschky schrieb:
Code: 
[CODE]
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.23.254  0.0.0.0         UG    0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.23.0    0.0.0.0         255.255.255.0   U     2      0        0 wlan0

Standard halt. Hab in dem Fall die Hostroute auch noch nicht gesetzt. Sollte ja wohl, oder? Kann man das über den Freetz-DHCP machen?


Code: 
PING 192.168.23.1 (192.168.23.1) from 192.168.23.22 : 56(84) bytes of data.
From 192.168.23.22 icmp_seq=1 Destination Host Unreachable
Zum Vergrößern anklicken....

Hallo,
das kann so nicht funktionieren.
Grund ist, dass dein Desktop gar nicht das Default-Gateway benutzt, da er meint, er könne den Server direkt erreichen.
Beim Ping sieht man das sehr gut: Destination Host Unreachable.
Der Desktop versucht, da die Rechner im selben Subnetz liegen, per ARP die Mac-Adresse des Servers zu ermitteln.
Da aber der ARP-Broadcast den Server nie erreicht, kann dieser nicht antworten.
Zudem würde deinem Desktop die Antwort nichts nützen, da Server und Desktop nicht im selben (physikalischen/logischen) Netz liegen.

Zwei Lösungen:

1. Richte VPN mit tap-Devices ein und erstelle auf der FritzBox eine Bridge über das tap-Interface und das lokale. Bei FritzBoxen exisitiert bereits die bridge 'lan'. Dort sollte dann das tap-Device hinzugefügt werden.
- Vorteil: echtes Netzwerk (ARP, Broadcast ...)
- Nachteil: Overhead durch Ethernetframes und unnötigen Broadcasts (unbedingt in der Fritzbox SSDP und anderen Müll filtern lassen, sonst verballerst du viel Traffic).

2. Setze auf dem Desktop und allen Rechnern im Netzwerk die Route: Dst: $SERVERIP GW: $FRITZBOXIP.
Auf dem Server dann Dst: $NETZWERK/24 GW: $FRITZBOXIP
auf allen Rechnern sollte schon automatisch der eintrag: dDst: $FRITZBOXIP device: $LANINTERFACE exisiteren.
-Vorteil: kaum Overhead, Broadcastdomains, gewisser, wenn auch geringer, Schutz des Netzwerks.
-Nachteil: erheblicher administrationsaufwand, unflexibel, keine Broadcasts-> NetBIOS Auflösung funktioniert nicht. u.U. müssen auf den Rechnern manuelle einträge in die hosts-Datei oder Zentral am router erfolgen.

Viele Grüße,
Vin
 
Hey, danke für die lange und ausführliche Antwort!

vinni10 schrieb:
2. Setze auf dem Desktop und allen Rechnern im Netzwerk die Route: Dst: $SERVERIP GW: $FRITZBOXIP.
Auf dem Server dann Dst: $NETZWERK/24 GW: $FRITZBOXIP
auf allen Rechnern sollte schon automatisch der eintrag: dDst: $FRITZBOXIP device: $LANINTERFACE exisiteren.
Zum Vergrößern anklicken....

Das hab ich wie gesagt schon versucht (hatte eben angenommen dass ich auf dem Desktop ne Hostroute setzen muss).

Code: 
$ route add -host 192.168.23.1 gw 192.168.23.254
$ ping -c 4 -I 192.168.23.22 192.168.23.1
PING 192.168.23.1 (192.168.23.1) from 192.168.23.22 : 56(84) bytes of data.

--- 192.168.23.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms

Irgendwie scheinen die Pakete an der Fritzbox "verloren" zu gehen. Warum?

Hat jemand ne gute Anleitung zu tap (oder reicht es von tun auf tap umzustellen?) Hab das gestern im schnellversuch gemacht aber hat nicht funktioniert...
 
Hallo,

muss der Server unbedingt eine 192er addresse haben?
Der Zugriff auf die VPN Adresse (10.8.0.9) sollte schon Out-of-the-Box funktionieren, sofern auch die entsprechende Route auf dem Server exisitiert (normalerweise durch push).
 
arnuschky schrieb:
Code: 
$ route add -host 192.168.23.1 gw 192.168.23.254
$ ping -c 4 -I 192.168.23.22 192.168.23.1
PING 192.168.23.1 (192.168.23.1) from 192.168.23.22 : 56(84) bytes of data.
--- 192.168.23.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms
Irgendwie scheinen die Pakete an der Fritzbox "verloren" zu gehen. Warum?
Zum Vergrößern anklicken....
Wie ist auf dem Desktop, die Ausgabe von:
Code: 
tracepath 192.168.23.1

EDIT:

Schau mal auf dem Server nach, ob der Ping dort angekommen ist.
 
Zuletzt bearbeitet:
sf3978 schrieb:
Wie ist auf dem Desktop, die Ausgabe von:
Code: 
tracepath 192.168.23.1
Zum Vergrößern anklicken....

Code: 
tracepath 192.168.23.1
 1:  192.168.23.22                                         0.125ms pmtu 1500
 1:  192.168.23.254                                      6.749ms 
 1:  192.168.23.254                                      3.526ms 
 2:  no reply
 3:  no reply

sf3978 schrieb:
Schau mal auf dem Server nach, ob der Ping dort angekommen ist.
Zum Vergrößern anklicken....

Hm. Doofe Frage: wie mach ich das? Ich hab mal ins dmesg geschaut aber da ist nix gelistet. Ich hab auf dem Server übrigens ne Firewall laufen (shorewall), aber es ändert nix wenn ich die an oder abstelle.

Übrigens: ping von Server and Freetz funktioniert auch nicht, daher vermute ich eher dass das Problem an Freetz liegt...
 
vinni10 schrieb:
muss der Server unbedingt eine 192er addresse haben?
Zum Vergrößern anklicken....

Nicht unbedingt, aber es hat einige Vorteile. Vor allem weil der Server vorher bei uns direkt im LAN war unter der 192.168.23.1. Jetzt wo der Server ins RZ verlagert wurde würde ich gerne den Zugriff darauf transparent gestalten.

Aber inzwischen isses auch noch mein Ehrgeiz der mich motiviert. :) Nach meinem Verständnis sollte es funktionieren und ich versteh nicht warum es nicht geht.

vinni10 schrieb:
Der Zugriff auf die VPN Adresse (10.8.0.9) sollte schon Out-of-the-Box funktionieren, sofern auch die entsprechende Route auf dem Server exisitiert (normalerweise durch push).
Zum Vergrößern anklicken....

Was meinst du mit Server? Wir müssten doch nur ne entsprechende Hostroute auf dem Desktop setzen, oder? Ich hab's wie folgt probiert, geht aber auch nicht:
Code: 
$ route add -host 10.8.0.1 gw 192.168.23.254
$ ping 10.8.0.1
 
arnuschky schrieb:
... wie mach ich das?
Zum Vergrößern anklicken....
Z. B. mit iptables, in der INPUT chain und dem target LOG.
arnuschky schrieb:
Übrigens: ping von Server and Freetz funktioniert auch nicht, daher vermute ich eher dass das Problem an Freetz liegt...
Zum Vergrößern anklicken....
Sollte aber funktionieren.

EDIT:

arnuschky schrieb:
Nicht unbedingt, aber es hat einige Vorteile. Vor allem weil der Server vorher bei uns direkt im LAN war unter der 192.168.23.1.
Zum Vergrößern anklicken....
Du könntest ja für die FritzBox (Freetz) und den Desktop, z. B. 192.168.24.0/24 benutzen und für den Server die 192.168.23.0/24 behalten.
 
Zuletzt bearbeitet:
Hey,

sorry für die späte Antwort, ich hatte die letzten zwei Tage keine Zeit dran zu arbeiten.

Ich hab jetzt einfach mal das 24er Netz für den VPN tunnel genommen um die Sache zu vereinfachen. Als Bild:

Code: 
       desktop                 freetz                            server
  192.168.23.22/wlan0 ------- 192.168.23.254/lan 
                               192.168.24.6/tun0 ----------- 192.168.24.1/tun0

Ich habe nun folgende Routen.

Code: 
Server:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         xxx.xxx.xxx.254   0.0.0.0         UG    100    0        0 eth0
xxx.xxx.xxx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.23.0    192.168.24.6    255.255.255.0   UG    0      0        0 tun0
192.168.24.0    192.168.24.2    255.255.255.0   UG    0      0        0 tun0
192.168.24.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.24.6    0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Freetz:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.24.5    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.23.0    0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.24.0    192.168.24.5    255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

Desktop:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.23.254  0.0.0.0         UG    0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.23.0    0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.24.0    192.168.23.254  255.255.255.0   UG    0      0        0 wlan0

Ich kann Freetz<->Desktop und Freetz<->Server einwandfrei pingen. Desktop<->Server geht aber nicht. Ich kann noch nicht mal vom Server das 23er-Bein von Freetz pingen (ping 192.168.23.254).

Ich hab das Gefühl da läuft was auf der Freetzbox schief... Evtl sollte ich mal iptables installieren. Die AVM-Firewall läuft ja ausschliesslich auf dem dsl Inteface und sollte uns ja nicht dazwischenfunken, oder?
 
Zuletzt bearbeitet:
arnuschky schrieb:
Code: 
Server:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         164.15.10.254   0.0.0.0         UG    100    0        0 eth0
164.15.10.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.23.0    192.168.24.6    255.255.255.0   UG    0      0        0 tun0
192.168.24.0    192.168.24.2    255.255.255.0   UG    0      0        0 tun0
192.168.24.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.24.6    0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Freetz:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.24.5    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.23.0    0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.24.0    192.168.24.5    255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl
Ich kann noch nicht mal vom Server das 23er-Bein von Freetz pingen (ping 192.168.23.254).
Evtl sollte ich mal iptables installieren.
Zum Vergrößern anklicken....
Versuch mal mit tun0 auf Server und Freetz, in einem Zwischennetz (... als gateways). iptables ist gut für S-NAT, auf Server und Freetz.
 
sf3978 schrieb:
Versuch mal mit tun0 auf Server und Freetz, in einem Zwischennetz (... als gateways). iptables ist gut für S-NAT, auf Server und Freetz.
Zum Vergrößern anklicken....

Sorry, aber das hab ich leider nicht verstanden. Was soll ich wo versuchen?
 
Ich hab jetzt in mehreren Anläufen iptables installiert (sehr ärgerlich dass man die Module und die Libaries einzeln anwählen muss.

Die Pings kommen bei der Box interessanter Weise nicht an. Hab folgendes Kommando benutzt:
Code: 
iptables -A INPUT -p icmp -j LOG

Übrigens hab ich folgendes im Log gesehen
Code: 
Jan  5 13:02:01 fritz user.warn kernel: Call Trace:
Jan  5 13:02:01 fritz user.warn kernel:  [<94029ee0>] local_bh_enable+0x4c/0x98
Jan  5 13:02:01 fritz user.warn kernel:  [<c008b4a4>] destroy_conntrack+0x114/0x170 [ip_conntrack]
Jan  5 13:02:01 fritz user.warn kernel:  [<941150d4>] __kfree_skb+0x140/0x15c
Jan  5 13:02:01 fritz user.warn kernel:  [<94114f78>] kfree_skbmem+0x14/0x30
Jan  5 13:02:01 fritz user.warn kernel:  [<c0285748>] wlan_memMngrFreeMSDU+0xf8/0x1c4 [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<c0285724>] wlan_memMngrFreeMSDU+0xd4/0x1c4 [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<c0281638>] whal_HostQueue_freeMsdu+0xcc/0x314 [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<c0280024>] whal_ParamsGetWepDefaultKey+0x28/0x48 [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<c0283d28>] whal_txQueue_Free+0x3bc/0x43c [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<c025203c>] wdrv_dbFindStaIndex+0x5c/0xe8 [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<9403610c>] worker_thread+0x0/0x2c4
Jan  5 13:02:01 fritz user.warn kernel:  [<c028340c>] whal_txClean+0xd0/0xec [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<9404e2dc>] slab_destroy+0xbc/0x100
Jan  5 13:02:01 fritz user.warn kernel:  [<9403621c>] worker_thread+0x110/0x2c4
Jan  5 13:02:01 fritz user.warn kernel:  [<c026d518>] wdrv_txCheckWaitPckts+0x88/0x19c [tiap]
Jan  5 13:02:01 fritz user.warn kernel:  [<9403610c>] worker_thread+0x0/0x2c4
Jan  5 13:02:01 fritz user.warn kernel:  [<94036318>] worker_thread+0x20c/0x2c4
Jan  5 13:02:01 fritz user.warn kernel:  [<94005dc8>] syscall_exit+0x0/0x34
Jan  5 13:02:01 fritz user.warn kernel:  [<940209b4>] default_wake_function+0x0/0x20
Jan  5 13:02:01 fritz user.warn kernel:  [<9403610c>] worker_thread+0x0/0x2c4
Jan  5 13:02:01 fritz user.warn kernel:  [<9403b330>] kthread+0xe8/0x130
Jan  5 13:02:01 fritz user.warn kernel:  [<940076ac>] kernel_thread_helper+0x10/0x18
Jan  5 13:02:01 fritz user.warn kernel:  [<9400769c>] kernel_thread_helper+0x0/0x18

Ist das normal?
 
arnuschky schrieb:
... das hab ich leider nicht verstanden.
Zum Vergrößern anklicken....
Beispiel für ein routing mit Zwischennetz:
Code: 
:~$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
10.3.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     2      0        0 eth0
192.168.188.0   10.3.0.1        255.255.255.0   UG    0      0        0 tun0
Code: 
root@fritz:/var/mod/root# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.3.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
##.###.###.###  0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.0.0     10.3.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.188.0   0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.188.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

EDIT:
S-NAT:
Code: 
:~$ sudo iptables -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 1009 packets, 60426 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       3      180 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0
 
Zuletzt bearbeitet:
Geht leider immer noch nicht. Irgendwas liegt da im argen. Es findet einfach kein forwarding zwischen lan und tun0 auf der Freetzbox statt, unabhängig von der Konfiguration die ich verwende. Das Zwischennetz ist jetzt die 3. Konfig die nach meinem Verständis laufen sollte. Ich vermute es gibt eine generelles Problem auf der Freetzbox, unabhändig von der verwendeten Konfig.

Code: 
Server:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         xxx.xxx.xxx.254 0.0.0.0         UG    100    0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
xxx.xxx.xxx.0     0.0.0.0       255.255.255.0   U     0      0        0 eth0
192.168.23.0    10.8.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.24.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Freetz:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.180.1   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.180.2   0.0.0.0         255.255.255.255 UH    2      0        0 dsl
192.168.23.0    0.0.0.0         255.255.255.0   U     0      0        0 lan
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.24.0    10.8.0.5        255.255.255.0   UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         0.0.0.0         0.0.0.0         U     2      0        0 dsl

Desktop:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.23.254  0.0.0.0         UG    0      0        0 wlan0
10.8.0.1        192.168.23.254  255.255.255.255 UGH   0      0        0 wlan0
10.8.0.6        192.168.23.254  255.255.255.255 UGH   0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.23.0    0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.24.1    192.168.23.254  255.255.255.255 UGH   0      0        0 wlan0

Ich kann pingen:
Server<->Freetz (10.8.0.1 <-> 10.8.0.6)
Desktop<->Freetz (192.168.23.22 <-> 10.8.0.6)
Desktop<->Freetz (192.168.23.22 <-> 192.168.23.254)

Vielleicht liegts ja an meiner OpenVPN-Konfig? Ich hab eigentlich nur
Code: 
dev tun
server 10.8.0.0 255.255.255.0
 
Zuletzt bearbeitet:
Was ist das auf dem Desktop
arnuschky schrieb:
Code: 
Desktop:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        192.168.23.254  255.255.255.255 UGH   0      0        0 wlan0
10.8.0.6        192.168.23.254  255.255.255.255 UGH   0      0        0 wlan0
Zum Vergrößern anklicken....
?
 
arnuschky schrieb:
Vielleicht liegts ja an meiner OpenVPN-Konfig?
Zum Vergrößern anklicken....
Jo, denke ich auch, sofern die Aussage aus #1 zusätzlich noch stimmt "...TUN mit Zertifikaten...".
"server 10.8.0.0 255.255.255.0" ist ja nur eine Abkürzung, und entscheidend ist, dass du damit eine "Multi-Client"-Konfiguration baust ("mode server" ist mit drin).
Damit reicht ein "route"-Befehl in der Config nicht mehr aus, der sorgt nur dafür, dass der Kernel die Pakete zum OpenVPN schickt. Das weiß dann aber nicht, zu welchem der möglichen Clients es das Netz schicken soll. Du musst ein "client-config-dir" anlegen mit einer Datei pro Zertifikats-Namen. Darin muss dann mindestens ein "iroute"-Befehl für das Netz sein, was bei diesem Client ist.

Ich vermute, dein Server wird eine Menge dieser Fehler anzeigen: "MULTI: bad source address from client [a.b.c.d] , packet dropped"
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 735 (Mitglieder: 26, Gäste: 709)

Neueste Beiträge

Statistik des Forums

Themen
244,881
Beiträge
2,220,059
Mitglieder
371,606
Neuestes Mitglied
Hobbie
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück