OPEN VPN Verbindungsabbrüche

radi23

Neuer User
Mitglied seit
12 Mrz 2013
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
Das Thema ist aus diesem Thema entstanden, hat aber mit der eigentlich Fragestellung nichts mehr zu tun, also gehts hier weiter, damit auch andere mit dem Problem den Thread leichter finden.

Problem ist folgendes: ein openVPN ist zwischen einem openwrt Router (VPN Server) und einer Freetz-Box (VPN Client) aufgebaut. Das VPN läuft im Bridging (TAP) Modus. Die Clients hinter dem OpenWrt Server könenn die Clients hinter der Freetz Box pingen und umgekehrt. Andere Services, insbesondere http Verbindungen, funktionieren jedoch nicht; es erscheint im Browser die Nachricht "Verbindung unterbrochen".

Meine bisherige Suche zum Thema Verbindungsabbrüche hat mich auf Probleme mit der MTU aufmerksam gemacht. Ich habe daher bereits ausprobiert die openvpn Config (jeweils Server und clientseitig) mit folgenden Optionen zu tunen: "tun-mtu 1300", danach "link-mtu 1300", danach "fragment 1400" und dann alle drei in Kombination mit "mssfix". Der Fehler bleibt bestehen.

Aufgefallen ist, dass sich ein Windows Rechner, der hinter der Freetz-Box sitz, sich per openvpn-client direkt am Server anmelden kann und das Problem mit den Verbindungsabbrüchen dann nicht besteht.

Das Netzwerk sieht folgendermaßen aus:

Clients (192.168.3.x) --- OpenWRT Router Lan Port (192.168.3.92) Wan Port (192.168.1.93) --- Fritzbox als Internetgateway (192.168.1.1) --- Freetz-Box 192.168.1.25 --- (Clients 192.168.1.x)

Der Vollständigkeit halber noch die aktuellen OpenVPN configs und die routings der beiden Router:

VPN-Server: (sieht etwas anders aus bei OpenWRT)
Code:
    option enabled '1'
    option tls_server '1'
    option proto 'udp'
    option ca '/etc/openvpn/ca.crt'
    option cert '/etc/openvpn/server.crt'
    option key '/etc/openvpn/server.key'
    option dh '/etc/openvpn/dh2048.pem'
    option ifconfig_pool_persist '/tmp/ipp.txt'
    option keepalive '10 120'
    option persist_key '1'
    option persist_tun '1'
    option user 'nobody'
    option status '/tmp/openvpn-status.log'
    option verb '3'
    option port '1196'
    option comp_lzo 'adaptive'
    option dev 'tap_myvpn'
    option client_to_client '1'
    option server_bridge '192.168.3.92 255.255.255.0 192.168.3.228 192.168.3.250'
    option link_mtu '1400'
    option mssfix
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.3.0     *               255.255.255.0   U     0      0        0 br-lan

VPN-Client
Code:
client
dev tap
;dev tun
;dev-node MyTap
;proto tcp
proto udp
remote 192.168.1.93 1196
;remote my-server-2 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nobody
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
ca /var/tmp/flash/openvpn/ca.crt
cert /var/tmp/flash/openvpn/client1.crt
key /var/tmp/flash/openvpn/client1.key
;ns-cert-type server
;tls-auth ta.key 1
;cipher x
comp-lzo
log-append /var/tmp/debug_openvpn.out 
verb 3
;mute 20
link-mtu 1400
mssfix
remote-cert-tls server

Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.0     *               255.255.255.0   U     0      0        0 tap0
192.168.1.0     *               255.255.255.0   U     0      0        0 lan
192.168.189.0   *               255.255.255.0   U     0      0        0 guest
169.254.0.0     *               255.255.0.0     U     0      0        0 lan

- - - Aktualisiert - - -

MaxMuster hat (im alten Thema) dazu folgendes angemerkt:

Kann es trotzdem das Routing sein?
Oder andersrum: Sicher, dass du den Webserver auch wirklich intern erreichst?

Der "Windows-OpenVPN-Client" ist ja direkt mit einer VPN-IP am Server, Geräte hinter dem FB-VPN-Client, die geroutet werden, kommen ja mit ihrer LAN-IP.

Der VPN-Server muss dann neben den "route" auch "iroute" Einträge für den entsprechenden OpenVPN-Client mit diesem LAN haben.

Einfacher Test wäre:
Kannst du das Web-IF der Freetz-Box auf der LAN-IP erreichen?

Geht es "von Hand" mit deinem Server, also z.B. geht ein "telnet <dein interner Webserver> 80"
(ggf. danach testen mit :

Code:
GET / HTTP/1.1
HOST: <deinserver>
<RETURN>
<RETURN>
)

MaxMuster danke schonmal für deine erneute Hilfe; meinem Verständnis nach muss doch das routing grundsätzlich stimmen, sonst würde kein Ping funktionieren, oder ?

Ich kann mit clienten hinter dem openWRT das Webinterface der FreetzBox auf der Lan IP und auf der VPN IP erreichen.

Folgendes ergibt der von dir vorgeschlagene Test: (ausgeführt von einem client hinter FreetzBox gegen einen Server hinter dem openWRT)

Code:
# telnet 192.168.3.7 80
Trying 192.168.3.7 ...
Connected to 192.168.3.7
Escape Character is '^]'.
GET / HTTP/1.1
Connection closed by foreign host.

Führe ich den Test von einem Clienten aus der ebenfalls am openWRT hängt, so sieht es so aus:
Code:
telnet 192.168.3.7 80
Trying 192.168.3.7...
Connected to 192.168.3.7.
Escape character is '^]'.
GET / HTTP/1.1
HOST 192.168.3.7

HTTP/1.1 400 Bad Request
Date: Sun, 17 Apr 2016 13:44:36 GMT
Server: Apache
Vary: Accept-Encoding
Content-Length: 369
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Request header field is missing ':' separator.<br />
<pre>
HOST 192.168.3.7</pre>
</p>
<hr>
<address>Apache Server at 192.168.3.7 Port 80</address>
</body></html>
Connection closed by foreign host.
 
Zuletzt bearbeitet:
Wenn ich das richtig sehe, kann das nicht funktionieren:

Server-WAN (eth0): 192.168.1.0/24
VPN-LAN: 192.168.3.0/24

LAN der FB: 192.168.1.0/24 <-- genauso, wie das WAN beim VPN-Server

Jedes Gerät aus dem LAN der FB hat also eine IP aus dem Netz 192.168.1.0/24, die mit dem beim Server identisch ist.
Der Server wird also (wie es in seiner Routingtabelle steht) diese IPs auf "eth0" suchen/erwarten..

Zum einen müssten die Netze "unterschiedlich" sein, zum zweiten fehlt die "Rückroute" für das LAN bei der FB zum Client der FB.
Das "TAP" (die Brücke) geht ja nur "bis zur FB", alle Geräte dahinter müssen geroutet werden.


Ansonsten könntest du natürlich das LAN der FB mit dem des VPN (mit dem TAP-Device) brücken, dann müssen aber die Netze sicher verschiedene IPs nutzen, selbst wenn sie dann im gleichen IP-Netz sein sollten (z.B. 192.168.1.1-100 beim Server, 192.168.1.101-150 beim Client 1 usw.)
 
Ok, also ich habe auf deinen Hinweis folgendes gemacht:
Das Netzwerk sieht nun so aus:

Clients (192.168.3.x) --- OpenWRT Router Lan Port (192.168.3.92) Wan Port (192.168.1.93) --- Fritzbox als Internetgateway (192.168.1.1) --- Freetz-Box WAN per DHCP (192.168.1.105) LAN (192.168.4.25) --- (Clients 192.168.4.x)

Nach diesen Änderungen kann ich mit clients aus 192.168.4.x nicht mehr in das 192.168.3.x Netz pingen, mit der Freetzbox aber schon. Route der Freetzbox gab:
Code:
 Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     *               255.255.255.255 UH    2      0        0 dsl
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.4.128   *               255.255.255.255 UH    2      0        0 dsl
192.168.4.0     *               255.255.255.0   U     0      0        0 lan
192.168.3.0     *               255.255.255.0   U     0      0        0 tap0
192.168.1.0     *               255.255.255.0   U     2      0        0 dsl
192.168.189.0   *               255.255.255.0   U     0      0        0 guest
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

Dann habe ich eine bridge auf der freetzbox gebaut
Code:
# brctl show
bridge name    bridge id        STP enabled    interfaces
lan        8000.bc0543d7621a    no        eth1
guest        8000.bc0543d7621a    no
# brctl addif lan tap0
# brctl show
bridge name    bridge id        STP enabled    interfaces
lan        8000.bc0543d7621a    no        eth1
                            tap0
guest        8000.bc0543d7621a    no

Nun kann ich allerdings nichtmal mehr von der freetzbox aus ins 192.168.3.0 Netz pingen?


Kurze zusätzliche Verständnisfrage: Wieso wird die FreetzBox Wan IP, welche mir im AVM Webinterface angezeigt wird und ist auch ansprechbar ist, bei ifconfig auf keinem interface angezeigt? Hintergrund: Ich habe im WEB-IF keine Option zum einstellen der WAN IP gefunden und war mir auch unsicher welches Interface ich per ifconfig ansprechen muss.
Code:
ifconfig
adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dsl       Link encap:Point-to-Point Protocol  
          inet addr:192.168.4.26  P-t-P:192.168.4.26  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:673 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3335 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:99125 (96.8 KiB)  TX bytes:1203999 (1.1 MiB)

eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:4465 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:795741 (777.0 KiB)  TX bytes:1277891 (1.2 MiB)

eth1      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:133 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2790 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:11758 (11.4 KiB)  TX bytes:577233 (563.7 KiB)

guest     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          inet addr:192.168.189.1  Bcast:192.168.189.255  Mask:255.255.255.0
          inet6 addr: fe80::be05:43ff:fed7:621a%4851880/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:1472 (1.4 KiB)

lan       Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          inet addr:192.168.4.26  Bcast:192.168.4.255  Mask:255.255.255.0
          inet6 addr: fe80::be05:43ff:fed7:621a%4851592/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1326  Metric:1
          RX packets:1055 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2017 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:144685 (141.2 KiB)  TX bytes:438228 (427.9 KiB)

lan:0     Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1326  Metric:1

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1%4849864/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4018 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4018 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:687197 (671.0 KiB)  TX bytes:687197 (671.0 KiB)

tap0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX  
          inet addr:192.168.3.228  Bcast:192.168.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1326  Metric:1
          RX packets:960 errors:0 dropped:0 overruns:0 frame:0
          TX packets:657 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:151377 (147.8 KiB)  TX bytes:110860 (108.2 KiB)
 
Zuletzt bearbeitet:
Wenn es keine besondere Anforderung gibt, die eine Bridge zwingend erforderlich machen, würde ich eher zum TUN(nel) raten. Dann kann man sich das ganze Brücken sparen.

Zum "ersten Versuch": Das ist schonmal besser, aber wenn die PCs aus dem 192.168.4-er Netz (hinter der Freetzbox) das VPN erreichen sollen, muss das VPN (der VPN-Server) das Netz auch "zurückschicken" können, du benötigst also eine Route auf dem VPN-Server für 192.168.4.0/24 zum "Freetz-OpenVPN-Client".

Das wird vermutlich auch das Problem nach dem "Bridging" gewesen sein: Zwar hast du nun LAN und TAP "verbunden", die "LAN-IP" auf diesem Brücken-IF ist aber die 192.168.4.26.
Wenn also die Box ins VPN über "LAN" geht, wird sie diese IP nehmen. Für ein "echtes Bridging" müssten dann noch die LAN-Netze "hinter" der Freetz-Box und "hinter" dem VPN-Server identisch, aber mit zwingend verschiedenen IPs sein. Auch die Frage der "mehren" DHCP-Server in diesem Segment dürfte dann schwierig sein.

Daher wiederhole ich meinen Rat von oben: Gibt es keinen zwingenden Grund fürs Bridging, mache Routing. "Zur Not" führe die Brücke bis auf die Freetz-Box, aber route dann im VPN (wie geschrieben: Netz 192.168.4.0 zur IP des Freetz-VPN-Clients routen).
 
Warum hier TAP verwendet wird erschließt sich mir nicht.

Die Konfiguration einer "Site2Site OpenVPN Verbindung" ist ausreichend im Netz dokumentiert.

Tipp:
"Client Specific Overrides" sind eine feine Sache. Man muß ja nicht jede Client-Route in die Konfiguration der Servers packen und "pushen".

Viel Spaß mit OpenVPN wünscht der

grauGolz
 
@grauGolz: Sicher, dass es um "pfSense" geht?
"Client Specific Overrides" ist ja kein OpenVPN oder Freetz, sondern ein pfSense GUI Menüpunkt....
Ich vermute, der legt nur komfortabel Daten ins Client-Config-Dir?!?
 
Der Knoten ist geplatzt, danke MaxMustermann.

Vorab, wieso ich TAP nutze: Im Netzwerk befinden sich Multifunktionsdrucker, die übers Netzwerk angesprochen werden, zum drucken, scannen und faxen. Die Treiber/Software finden aber die Drucker nicht über TUN(nel) VPN, das Problem hatte ich bereits zuvor mit dem Fritzbox eigenen IPSec VPN. Daher wollte ich gern ein TAP VPN.

Sollte also noch jemand mit dem Problem kämpfen, dass ping in alle Richtungen, aber bspw. kein http oder smb funktioniert, dann kann das nicht nur an Problemen mit der MTU liegen, sondern auch an einem falschen Subnetz-Layout.


Bei mir funktioniert es nun mit folgendem Netzwerksetup:

Clients (192.168.3.[1-90]) --- OpenWRT Router Lan Port (192.168.3.92) Wan Port (192.168.1.93) --- Fritzbox als Internetgateway (192.168.1.1) --- Freetz-Box WAN per DHCP (192.168.1.105) LAN (192.168.3.101) --- (Clients 192.168.3.[110-200])

Dazu ist eine bridge auf dem openWRT Router und auf der Freetzbox jeweils über den TAP und den LAN Adapter notwendig. Ich hoffe das hilft anderen.

Wenn noch jemand von den Profis hier Lust hat mir auf die Sprünge zu helfen, bleibt noch die Verständnisfrage: Wieso kann ich die per DHCP erhaltene WAN IP auf der FreetzBox per ifconfig bei keinem der interfaces finden und wie könnte ich die Freetz Wan IP manuell einstellen (gibt es bspw. ein verstecktes Menü)?

Ps: Die beiden Interfaces der FreetzBox [7330] habe ich auf verschiedene Netzwerke gebracht indem ich per ifconfig das interface lan auf einen eigenes Subnetz eingestellt habe, das WAN Interface hat sich dann von alleine per DHCP konfiguriert.
 
Zuletzt bearbeitet:
@radi23: Warum die IP da nicht sichtbar ist, müsstest du AVM fragen ;-)

Hab ich lange nicht gemacht: Konnte man auf der "Internet-Zugangs-Seite" (von AVM) nicht neben "IP beziehen" sogar die IP direkt eintragen?

Wenn das VPN immer läuft, ist es nicht ganz so wild, aber du wirst vermutlich noch immer ein "DHCP-Problem" haben:
Der DHCP der Freetz-Box müsste als Gateway seine IP angeben, der DHCP der OpenWRT-Box seine.
Es gilt bei DHCP-Anfragen zwar: Wer zuerst kommt, mahlt zuerst, und der "lokale" DHCP ist ja "näher" und damit vermutlich schneller, aber prinzipiell könnte es immer zu Problemen kommen!
"Sicher" ist man dann nur, wenn man die IPs und das Gateway fest vergibt und auf DHCP verzichtet.
 
Hallo zusammen,

also, eine WAN IP ist nicht einstellbar, solange man im AVM Web-IF unter Internet -> Zugangsdaten -> Internetanbieter die Option "vorhandener Zugang über Lan" ausgewählt hat. Ändert man dies jedoch auf "Anderer Internetanbieter", kann man unter "Verbindungseinstellungen ändern" auch IP usw. vergeben. Im Terminal per ifconfig scheint der WAN Adapter trotzdem nicht aufzutauchen/konfigurierbar zu sein.

@MaxMuster, das mit dem DHCP kann sein, dazu kann ich aber nichts sagen, da ich mit festen IP Adressen arbeite.

Ich habe noch ein merkwürdiges Verhalten festgestellt; wenn die Brücke auf der Freetzbox nicht aktiv ist, kann ich mit Clienten der FreetzBox die IP des TAP interfaces pingen, nicht jedoch die des LAN Interfaces. Das macht für mich keinen Sinn, da ja der Client an dem Lan Interface hängt, und nicht an dem virtuellen TAP. Das soll mir aber jetzt egal sein, da ich ja die Brücke eh brauche.

Noch ein Nachtrag für alle die meinen Leidensweg als Hilfestellung / Tutorial nutzen: Um die Bridge rebootfest zu machen, muss die bridge in der /var/flash/ar7.cfg hinterlegt werden. Dazu wird die Datei per nvi geöffnet und unter brinterfaces -> name = "lan" -> interfaces der tap0 Adapter hinzugefügt.
Dann noch einmal der Befehl ar7cfgchanged und die bridge sollte beim nächsten reboot eingerichtet sein.
 
Zuletzt bearbeitet:
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.