OpenVPN - 2 Netze miteinander verbinden

dougi

Neuer User
Mitglied seit
14 Nov 2006
Beiträge
116
Punkte für Reaktionen
0
Punkte
0
Guten Abend Zusammen,

ich habe ein kleines Problem mit openVPN und würde mich freuen wenn der eine oder andere Pro sich mal nachfolgende config anschauen könnte.

Zunächst die Situation:

Es soll ein gemeinsames Netz inkl. Broadcast über das Internet realisiert werden.

Netz 1:
Router mit openVPN: 10.0.0.1
VPN-IP: 192.168.200.1
DHCP-Range 10.0.0.20 - 10.0.0.99

Netz 2:
Router mit openVPN: 10.0.0.201
VPN-IP: 192.168.200.2
Clients mit statischen IP: 10.0.0.202 - 10.0.0.205

Auf beiden Routern ist ein entsprechnder tap0 Device in der ar7.cfg integriert.

Soweit so gut.

Die Konfiguration läuft über Client-Zertifikate und funktioniert, theoretisch.

Praktisch tritt folgendes mir unerklärliches Problem auf:
Eine Verbindung aus Netz 2 in Netz 1 ist möglich, solange kein Client im Netz 1 angemeldet ist. Ist in Netz 1 ein Client aktiv, führt das zum sofortigen Reboot des Routers von Netz 1. Eine Ausnahme bilden die IPTV-Clients. Diese funktionieren parallel zur VPN-Verbindung, haben allerdings auch IP-Adressen aus dem T-Home-Adress-Pool.

Hier mal die über die WebGui generierten Configfiles:

Netz 1 (Server):
# OpenVPN 2.1 Config, Mon Mar 23 19:25:31 CET 2009
proto tcp-server
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1194
ifconfig 192.168.200.1 255.255.255.0
mode server
client-config-dir /var/tmp/clients_openvpn
topology subnet
max-clients 5
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
max-clients 5
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher AES-256-CBC
float
keepalive 10 120


Clientconfig (/var/tmp/clients_openvpn):
ifconfig-push 192.168.200.2 255.255.255.0
push "topology subnet"


Netz 2 (Client):
# OpenVPN 2.1 Config, Mon Mar 23 19:28:43 CET 2009
proto tcp-client
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
tls-client
ns-cert-type server
tls-auth /tmp/flash/static.key 1
remote meinserver.logisch.oder.dyndns.org
nobind
pull
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
daemon
cipher AES-256-CBC
float
keepalive 10 120
resolv-retry infinite


Wie gesagt, für mich absolut unergründlich warum diese Reboots kommen.

Vielleicht hat ja einer von Euch den entscheidenden Hinweis parat :).

Viele Grüße,

Dougi
 
Hi,
könnte es sein dass das mit dem WLAN-bezogenen "tap-bug" zusammenhängt, der hier beschrieben ist?


Jörg
 
Denke auch, dass das miteinander zu tun hat. Hat eigentlich inzwischen irgendwer nen Plan, was avm da verunstaltet hat damit sich das mit dem WLan beisst?
 
Hi,
könnte es sein dass das mit dem WLAN-bezogenen "tap-bug" zusammenhängt, der hier beschrieben ist?


Jörg

Ja in diesem Post finde ich mich (leider) wieder. Ein funktionstüchtiges Work-Around dazu gibt es noch nicht oder?

Viele Grüße,

Dougi

PS: Server-Reboot (Netz 1) kommt auch, wenn sich im Netz 2 ein Client per WLAN anmeldet
 
Workaround: tun nutzen oder kein Wlan :D Alles andere tut es aktuell nicht.
 
Workaround: tun nutzen oder kein Wlan :D Alles andere tut es aktuell nicht.

Dann wohl auf WLAN verzichten :spocht:^^

Ne Spass beiseite. Wenn ich das nachher auf tun umfriemel, muss ich dann

1. die beiden tap-Devices aus den Configfiles nehmen?
2. getrennte IP-Netze bei Client und Server verwenden oder kann die die bestehende IP-Wahl bleiben?

Grüße,

Dougi
 
Zuletzt bearbeitet:
/push wegen Änderung im Vor-Post

^
|
|
 
1. die beiden tap-Devices aus den Configfiles nehmen?
2. getrennte IP-Netze bei Client und Server verwenden oder kann die die bestehende IP-Wahl bleiben?

1. Die tap-Devices sind entfernt
2. Die Ip-Netze 10.0.0.0 und 10.0.1.0 sind eingesetzt.

Jetzt kann ich zwar immer den gegenüberliegenden Router erreichen, allerdings keine Client <-> Router <-> Wolke <-> Router <-> Client Verbindung aufbauen.

Ich google zwischenzeitlich mal weiter ...

Grüße
 
Und, wie weit bist du?
Um die Geräte auf der jeweils anderen Seite zu erreichen müssen zum einen die Boxen jeweils in ihrem Netz das Defaultgateway sein und zum anderen muss eine Route zu dem Netz auf der anderen Seite eingetragen sein (z.B. so beim Server):

route <Netz auf der Cient-Seite>
push "route <Netz auf der Server-Seite>"


Jörg
 
Die Verbindung habe ich auf anhieb hinbekommen.

Bin dann allerdings jetzt doch auf die AVM Lösung umgestiegen und warte darauf, das es mit dem Bridging vielleicht doch in näherer Zeit wieder funktioniert.

Grüße
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
246,273
Beiträge
2,249,292
Mitglieder
373,862
Neuestes Mitglied
904lte
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.