OpenVPN - 2 Netze miteinander verbinden

[dougi]

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

 

[MaxMuster]

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


Jörg

 

[Silent-Tears]

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?

 

[dougi]

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

 

[Silent-Tears]

Workaround: tun nutzen oder kein Wlan Alles andere tut es aktuell nicht.

 

[dougi]

Workaround: tun nutzen oder kein Wlan 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

 

[dougi]

/push wegen Änderung im Vor-Post

^
|
|

 

[dougi]

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

 

[MaxMuster]

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

 

[dougi]

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