openvpn - config: windows -> freetz

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Ach so, zudem routest du jetzt das "andere" VPN durch das "hier besprochene".
Du solltest besser eine Host-Route zu diesem anderen Server durch das DSL eintragen...
 
Hat der eine feste IP oder eine Dynamische?
Bei einer festen wäre es einfach:
Code: 
route add <IP des Servers> dev dsl
 
leider eine dynamische IP. Ein Dyndns-Anbieter ist hinterlegt. Ginge dies auch?
 
Nur kurz, bis zum nächsten IP-Wechsel, aber du kannst statt der IP auch den Namen eingeben...
Zur Not müsstest du (erstmal Testen, ob es so geht ;-)) ein Skript basteln, das alle paar Minuten die IP auflöst und bei einer Änderung das Routing anpasst...
 
Ok. Der DSL-Tipp hat gut funktioniert. Jetzt kann ich beide OpenVPN-Netze bei gleichzeitig aufgebauter Verbindung erreichen. Danke für den Tipp!!

Soweit ich den den dyndns-Name bei route add angebe, muss es logischerweise der sein, der in der Client-Box bei OpenVPN hinterlegt ist?
D.h. das Routing macht nach der Auflösung des Dyndns auf die jeweilige IP keinen weiteren Vergleich, ob die IP zu einer weiteren im Routing eingetragenen DynDNS passt? Oder/Und das Routing löst die eingetragene DynDNS nicht per se auf und behandelt die sich daraus ergebende IP auch nicht als eigenen hinterlegte Eintrag (so als wäre die IP von vornherein eingetragen worden)?

EDIT: Habs herausgefunden. die EIngabe des Namens führt zur Auflösung, so dass dann nur die IP des aufgelösten DynDNS eingetragen wird.
 
Zuletzt bearbeitet:
Genau, die Auflösung passiert nur einmal beim Einrichten der Route.
Möglicher "Workaround", z.B. in rc.custom:
Code: 
fixroute(){
# hier deinen Namen eintragen, ich brauchte was zum testen ;-)
NAME=heise.de
# Dummy für OLD
OLD=8.8.8.8

while true; do
  NEW=$(ping -c1 $NAME 2>/dev/null | sed -n '/data/ s/.*(\([0-9\.]*\)).*/\1/p')
  if [ -n "$NEW" -a "$NEW" != "$OLD" ]; then
    route -n | grep -q "$OLD" && route del $OLD dev dsl 2>/dev/null
    route add $NAME dev dsl
    OLD=$NEW
  fi
  sleep 300
done
}
fixroute &
 
Dein Skript löst auch das Problem, dass die Routing-Tabelle nicht mit den alten IPs überläuft. Es entfernt die Alte bevor die Neue eingetragen wird, wenn ich das richtig sehe?
 
So ist es gedacht, ja.
 
wird der "Dummy" >>OLD<< nach dem ersten Durchlauf (Neustart) aktualisiert, so dass bereits die aktuelle IP bei Änderung gelöscht werden kann?
 
Beim Neustart der Box gibt es ja noch nix, da kann nichts gelöscht werden (es wird geprüft, ob ein Eintrag für diese IP in der Routingtabelle ist, bervor gelöscht wird).
Wenn du das (von Hand) startest und der Routing Eintrag ist schon da wird es einmal eine Fehlermeldung geben ("route: SIOCADDRT: File exists"), danach läuft es wie gewollt. Die Fehlermeldung könnte man auch noch abfangen, wenn es ganz wichtig wäre (wie beim Löschen erst prüfen, ob schon ein Eintrag da ist und wenn nicht, die Route setzen).
Code: 
route -n | grep -q "$NEW" ||  route add $NAME dev dsl
 
bin jetzt noch Deinem anderen Ansatz nachgegangen.

Scheinbar mag die zweite Verbindung nicht über die erste aufgebaut werden.

Code: 
Nov 24 20:30:12 fritz daemon.err openvpn[15123]: Connection reset, restarting [-1]
Nov 24 20:30:12 fritz daemon.notice openvpn[15123]: /sbin/route del -net 172.30.1.112 netmask 255.255.255.255
Nov 24 20:30:12 fritz daemon.notice openvpn[15123]: Closing TUN/TAP interface
Nov 24 20:30:12 fritz daemon.notice openvpn[15123]: /sbin/ifconfig tap0 0.0.0.0
Nov 24 20:30:13 fritz daemon.notice openvpn[15123]: SIGUSR1[soft,connection-reset] received, process restarting
Nov 24 20:30:13 fritz daemon.notice openvpn[15123]: Restart pause, 5 second(s)
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: Socket Buffers: R=[87380->131072] S=[16384->131072]
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: TUN/TAP device tap0 opened
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: TUN/TAP TX queue length set to 100
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: /sbin/ifconfig tap0 172.30.1.206 netmask 255.255.255.0 mtu 1500 broadcast 172.30.1.255
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: /sbin/route add -net 172.30.1.112 netmask 255.255.255.255 gw 172.30.1.123
Nov 24 20:30:18 fritz daemon.notice openvpn[15123]: Attempting to establish TCP connection with [AF_INET]XX.XX.XXX.XXX:143 [nonblock]
Nov 24 20:30:19 fritz daemon.notice openvpn[15123]: TCP connection established with [AF_INET]XX.XX.XXX.XXX:143
Nov 24 20:30:19 fritz daemon.notice openvpn[15123]: TCPv4_CLIENT link local: [undef]
Nov 24 20:30:19 fritz daemon.notice openvpn[15123]: TCPv4_CLIENT link remote: [AF_INET]XX.XX.XXX.XXX:143
Nov 24 20:31:19 fritz daemon.err openvpn[15123]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Nov 24 20:31:19 fritz daemon.err openvpn[15123]: TLS Error: TLS handshake failed
Nov 24 20:31:19 fritz daemon.err openvpn[15123]: Fatal TLS error (check_tls_errors_co), restarting
Nov 24 20:31:19 fritz daemon.notice openvpn[15123]: /sbin/route del -net 172.30.1.112 netmask 255.255.255.255
Nov 24 20:31:19 fritz daemon.notice openvpn[15123]: Closing TUN/TAP interface
Nov 24 20:31:19 fritz daemon.notice openvpn[15123]: /sbin/ifconfig tap0 0.0.0.0
Nov 24 20:31:20 fritz daemon.notice openvpn[15123]: SIGUSR1[soft,tls-error] received, process restarting
Nov 24 20:31:20 fritz daemon.notice openvpn[15123]: Restart pause, 5 second(s)
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: Socket Buffers: R=[87380->131072] S=[16384->131072]
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: TUN/TAP device tap0 opened
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: TUN/TAP TX queue length set to 100
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: /sbin/ifconfig tap0 172.30.1.206 netmask 255.255.255.0 mtu 1500 broadcast 172.30.1.255
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: /sbin/route add -net 172.30.1.112 netmask 255.255.255.255 gw 172.30.1.123
Nov 24 20:31:25 fritz daemon.notice openvpn[15123]: Attempting to establish TCP connection with [AF_INET]XX.XX.XXX.XXX:143 [nonblock]
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: TCP connection established with [AF_INET]XX.XX.XXX.XXX:143
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: TCPv4_CLIENT link local: [undef]
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: TCPv4_CLIENT link remote: [AF_INET]XX.XX.XXX.XXX:143
Nov 24 20:31:26 fritz daemon.warn openvpn[15123]: WARNING: Bad encapsulated packet length from peer (18516), which must be > 0 and <= 1591 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attac
Nov 24 20:31:26 fritz daemon.err openvpn[15123]: Connection reset, restarting [0]
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: /sbin/route del -net 172.30.1.112 netmask 255.255.255.255
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: Closing TUN/TAP interface
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: /sbin/ifconfig tap0 0.0.0.0
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: SIGUSR1[soft,connection-reset] received, process restarting
Nov 24 20:31:26 fritz daemon.notice openvpn[15123]: Restart pause, 5 second(s)
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: Socket Buffers: R=[87380->131072] S=[16384->131072]
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: TUN/TAP device tap0 opened
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: TUN/TAP TX queue length set to 100
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: /sbin/ifconfig tap0 172.30.1.206 netmask 255.255.255.0 mtu 1500 broadcast 172.30.1.255
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: /sbin/route add -net 172.30.1.112 netmask 255.255.255.255 gw 172.30.1.123
Nov 24 20:31:31 fritz daemon.notice openvpn[15123]: Attempting to establish TCP connection with [AF_INET]XX.XX.XXX.XXX:143 [nonblock]
Nov 24 20:31:32 fritz daemon.notice openvpn[15123]: TCP connection established with [AF_INET]XX.XX.XXX.XXX:143
Nov 24 20:31:32 fritz daemon.notice openvpn[15123]: TCPv4_CLIENT link local: [undef]
Nov 24 20:31:32 fritz daemon.notice openvpn[15123]: TCPv4_CLIENT link remote: [AF_INET]XX.XX.XXX.XXX:143

Insbesondere
Code: 
Nov 24 20:31:26 fritz daemon.warn openvpn[15123]: WARNING: Bad encapsulated packet length from peer (18516), which must be > 0 and <= 1591 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attac

Die MTU ist sowohl auf dem einem wie auch dem anderen Server auf 1500 eingestellt.

Kann dies die Ursache für das hier sein?
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
 
Zuletzt bearbeitet:
Du müsstest zudem auch ein "float" in der Server Konfig haben, weil sich die IP des Clients durch das VPN hindurch ja ändert (sofern auch die VPN-IPs genattet werden, hattest du jetzt beide Netze in der iptables-Config drin, LAN und VPN-Netz?).
 
ich habe folgende beiden Sachen auf dem hier besprochenen Server drin

Code: 
iptables -t nat -A POSTROUTING -s 10.2.1.0/24 -j SNAT --to-source TO.EXT.IP
iptables -t nat -A POSTROUTING -s 172.30.2.0/24 -j SNAT --to-source TO.EXT.IP
Erstere IP (10.2...) ist das VPN-Netz des "ersten" hier besprochenen OpenVPN-Servers
Letztere IP (172.30...) ist das LAN-Netz des Box-Netzes, von dem aus die Verbindung auch in die zweite Box bzw. deren Netz (172.30.1.0) erfolgt/erfolgen soll. Also das Netz, von dem aus die Fehlermeldung und die Route von zuvor stammen.
Float ist jetzt auch drin. Hilft aber auch nicht.
 
Zuletzt bearbeitet:
Ich füge mal die betreffenden 4 Configs bei.

Config hier besprochener Server
Code: 
user openvppn
group openvppn




 #  OpenVPN 2.1 Config, Thu Jan  1 01:02:19 CET 1970
local XX.XX.XXX.XXX
port 443


float
proto tcp-server
dev tap


#Helperline for rc.openvpn to add tap0 to lan bridge


ca /etc/openvpn/easy-rsa2/keys/ca.crt
cert /etc/openvpn/easy-rsa2/keys/server.crt
key /etc/openvpn/easy-rsa2/keys/server.key    # Diese Datei geheim halten.  # This file should be kept secret




dh /etc/openvpn/easy-rsa2/keys/dh1024.pem


#nicht in original-server-config drin
tls-server




port 443 
ifconfig 10.2.1.101 255.255.255.0
push "route-gateway 10.2.1.101"


max-clients 10
mode server
#ip zu weisung an clients
#ifconfig-pool 10.2.1.102 10.2.1.120


push "route 10.2.1.0 255.255.255.0"




push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 4.2.2.1"






#client-to-client


#nachfolgend erledigt
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450




#
keepalive 5 30
comp-lzo
persist-key
persist-tun
status /etc/openvpn/443.log
log-append /etc/openvpn/443-ovp.log








## cipher AES-256-CBC
cipher AES-128-CBC


verb 3
route 172.30.2.0 255.255.255.0 10.2.1.102




Config OPENVPN der zweiten BOX

Code: 
root@fritz:/var/mod/root# cat /mod/etc/openvpn*.conf
#  OpenVPN 2.1 Config, Sun Nov 24 20:57:12 CET 2013
proto tcp-server
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
port 1143
ifconfig 172.30.1.201 255.255.255.0
push "route-gateway 172.30.1.201"
max-clients 5
mode server
ifconfig-pool 172.30.1.202 172.30.1.206
push "route 172.30.1.0 255.255.255.0"
client-to-client
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
float
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
route 172.30.2.0 255.255.255.0 172.30.1.206
float


Config der hier betroffenen Client-Box (die sich zu beiden OpenVPN-Servern verbinden soll und von der die Fehlermeldungen stammen

1. Verbindung zum hier besprochenen Server


Code: 
#put your config here
# to use Keys and Certs from GUI here are samples
#ca /tmp/flash/openvpn/openvpn_2/ca.crt
#cert /tmp/flash/openvpn/openvpn_2/box.crt
#key /tmp/flash/openvpn/openvpn_2/box.key
#dh /tmp/flash/openvpn/openvpn_2/dh.pem


#  vps-ch


proto tcp-client
dev tap
#dev tun
#secret "D:\\Programme\\OpenVPN\\config\\key"
tls-client
remote-cert-tls server
#ns-cert-type server


ca /tmp/flash/openvpn/openvpn_2/ca.crt
cert /tmp/flash/openvpn/openvpn_2/zwei.crt
key /tmp/flash/openvpn/openvpn_2/zwei.key




script-security 2






remote XX.XX.XXX.XXX 443


pull


ifconfig 10.2.1.102 255.255.255.0


#route-gateway 10.8.0.1
#redirect-gateway


#route 172.30.1.0 255.255.255.0 172.30.1.201


verb 3


cipher AES-128-CBC
comp-lzo


2. Verbindung zur zweiten Box


Code: 
#auskommentieren, dann drucker/scanner erreichbar
route 172.30.1.112 255.255.255.255 172.30.1.123


#in ar7 tap0 auf der 7490 nur eintragen, wenn 
#server? oder generell nicht mehr?
#jedenfalls kommt im client-betrieb 
#fehlermeldung der ip-doppelbelegung


#put your config here
# to use Keys and Certs from GUI here are samples
#ca /tmp/flash/openvpn/ca.crt
#cert /tmp/flash/openvpn/box.crt
#key /tmp/flash/openvpn/box.key
#dh /tmp/flash/openvpn/dh.pem


#  OpenVPN 2.1 Config, Tue Mar 18 04:06:30 CET 2008


proto tcp-client
dev tap
#dev tun
#secret "D:\\Programme\\OpenVPN\\config\\key"
tls-client
remote-cert-tls server


#deakt 20-10-2013
#ns-cert-type server


#ca /tmp/flash/openvpn/ca.crt
#cert /tmp/flash/openvpn/client03.crt
#key /tmp/flash/openvpn/client03.key


ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key


#tls-auth "C:\\Users\\1\\Desktop\\config\\key" 1


script-security 3






remote XX.XX.XXX.XXX 143
#remote dx1.dyndns.org 143


#nobind
#route delete
#pull


#ggf re-akt, wenn route auf server entfernt
#dhcp-option DNS 172.30.1.1




#ggf re-akt, wenn route auf server entfernt
#dhcp-option WINS 172.30.1.1






#route-gateway 172.30.1.1
#redirect-gateway


#dhcp+redirect + route-gateway = internet ueber opvn-server


#client-to-client #nur auf server!


ifconfig 172.30.1.206 255.255.255.0




#macht keinen sinn
#route 172.30.1.0 255.255.255.0 172.30.1.201


#route 172.30.1.0 255.255.255.0 172.30.1.206


#ifconfig 172.30.1.205 172.30.1.201




tun-mtu 1500
mssfix
verb 3
#daemon
cipher AES-256-CBC
#comp-lzo
float
keepalive 10 120
resolv-retry infinite
 
Sorry, hat etwas gedauert.
Wenn ich das richtig verstanden habe, geht es hier "nur ums Prinzip", denn es ist m.E. überhaupt nicht sinnvoll, das eine VPN durch das andere zu leiten. Allein die zusätzliche Last durch doppelte Verschlüsselung aller Pakete des "zweiten" VPNs auf der Box ...

Aber, um es zu prüfen: Was steht denn im "Problem-Server" für eine IP deiner Client-Box? Steht da die externe IP des "ersten" VPN-Servers?
 
Ich hab mich inzwischen damit angefreundet, die Verbindungen nicht zu überlagern.

Aber was anderes ist mir aufgefallen. Und zwar läuft das Streaming von Videos wie beispielsweise von akamaihd.net nur sehr stockend, während über andere Verbindungsarten wie ssh das Streaming tadellos läuft.

Kennst Du ggf. Ansätze mit der das Streaming-Verhalten über eine Openvpn überprüft und ggf verbessert werden kann?
 
Einmal ist das Ver-/Entschlüsseln der Daten schon recht Prozessorintensiv, dann ist ein TCP-OpenVPN deutlich anspruchsvoller als ein UDP-basierendes OpenVPN und zudem ändern sich im Tunnel die möglichen Paketgrößen (Stichwort MTU). Das letztere kannst du unter Experten-Einstellungen beeinflussen.

Streamst du über UDP oder TCP, dementsprechend könnte der MTU (TCP) oder "Fragment" (UDP) Parameter helfen?
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 580 (Mitglieder: 34, Gäste: 546)

Neueste Beiträge

Statistik des Forums

Themen
246,753
Beiträge
2,256,867
Mitglieder
374,779
Neuestes Mitglied
ProUser
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