1
OpenVPN DD-WRT Linksys WRT54GL Citrix Verbindungsprobleme
Probleme mit Citrix XenApp Sitzungen über OpenVPN-Verbindungen
Folgende Problemstellung:
Unsere Firmenzentrale ist mit mehreren Standorten via OpenVPN verbunden. In den Standorten stehen u.a. WinXP-Clients (W2k3-Domänen-Mitglieder), die sich u.a. an DCs in der Firmenzentrale sowie an einem Terminalserver (Citrix XenApp 5.0) anmelden sollen.
In der Zentrale steht der OpenVPN-Server (performanter HP-Server), auf der VMware ESXi als Host und Win2k3 als Gastbetriebssystem installiert ist. Auf dem W2k3-Server läuft dann der OpenVPN-Server.
In den Außenstellen befinden sich LINKSYS-WRT54GL V1.0 Router mit DD-WRT-Software (V24SP1) und der nachfolgenden Clientkonfiguration.
Das VPN steht soweit. Problem ist, das in sehr unregelmäßigen Abständen die Citrix-Sitzungen kurz getrennt werden und wieder aufgebaut werden (keine Meldung im Eventlog).
Wer kann uns ggf. weiterhelfen. Wir haben schon versucht, auf das Protokoll TCP umzustellen. Dann sind zwar die Probleme mit den wegfliegenden Citrix-Sitzungen so gut wie nicht mehr vorhanden, jedoch geht die Performance sehr zurück und einer unserer Standorte kann innerhalb Citrix - bedingt durch schwache Anbindung (1MBit-Standleitung) – kaum noch arbeiten. Die Lösung einer stärkeren Standleitung kommt jedoch aus Kostengründen für uns nicht in Frage.
Wer hat dort eine Idee ? Liegt es ggf. am LINKSYS? Gibt es evt. besserer Router für OpenVPN.
Konfiguration OpenVPN-Server:
port 763
proto udp
mode server
tls-server
dev tap
dev-node OpenVPN-WAN
ifconfig 10.100.0.1 255.255.255.0
client-config-dir c:\\Programme\\OpenVPN\\config\\ccd
dh c:\\Programme\\OpenVPN\\secrets\\dh1024.pem
ca c:\\Programme\\OpenVPN\\secrets\\ca.crt
key c:\\Programme\\OpenVPN\\secrets\\grzis4.key
cert c:\\Programme\\OpenVPN\\secrets\\grzis4.crt
comp-lzo
push "route-gateway 10.100.0.1"
push "route 192.168.202.0 255.255.255.0"
push "dhcp-option DNS 192.168.202.8"
push "dhcp-option WINS 192.168.202.8"
tun-mtu 1500
tun-mtu-extra 32
verb 3
mute 50
keepalive 10 60
ping-timer-rem
persist-key
persist-tun
push "ping 10"
push "ping-restart 60"
push "ping-timer-rem"
Konfiguration OpenVPN-Client auf LINKSYS WRT54GL (DD-WRT):
cd /tmp
mkdir /tmp/ovpn
ln -s /usr/sbin/openvpn /tmp/ovpn/ovpn
/tmp/ovpn/ovpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc up
sleep 5
echo "
client
daemon
dev tap0
proto udp
tls-client
remote xxx.xxx.xxx 763
resolv-retry infinite
nobind
persist-key
persist-tun
ca /tmp/ovpn/ca.crt
cert /tmp/ovpn/gshr-001.crt
key /tmp/ovpn/gshr-001.key
dh /tmp/ovpn/dh1024.pem
ns-cert-type server
comp-lzo
verb 3
pull
tun-mtu 1500
tun-mtu-extra 32
" > /tmp/ovpn/gshr-001.config
echo "
BEGIN CERTIFICATE-----
xxx
END CERTIFICATE-----
" > /tmp/ovpn/ca.crt
echo "
BEGIN RSA PRIVATE KEY-----
xxx
END RSA PRIVATE KEY-----
" > /tmp/ovpn/gshr-001.key
chmod 600 /tmp/ovpn/gshr-001.key
echo "
BEGIN CERTIFICATE-----
xxx
END CERTIFICATE-----
" > /tmp/ovpn/gshr-001.crt
echo "
BEGIN DH PARAMETERS-----
xxx
END DH PARAMETERS-----
" > /tmp/ovpn/dh1024.pem
sleep 5
/tmp/ovpn/ovpn --config /tmp/ovpn/gshr-001.config
Unsere Firmenzentrale ist mit mehreren Standorten via OpenVPN verbunden. In den Standorten stehen u.a. WinXP-Clients (W2k3-Domänen-Mitglieder), die sich u.a. an DCs in der Firmenzentrale sowie an einem Terminalserver (Citrix XenApp 5.0) anmelden sollen.
In der Zentrale steht der OpenVPN-Server (performanter HP-Server), auf der VMware ESXi als Host und Win2k3 als Gastbetriebssystem installiert ist. Auf dem W2k3-Server läuft dann der OpenVPN-Server.
In den Außenstellen befinden sich LINKSYS-WRT54GL V1.0 Router mit DD-WRT-Software (V24SP1) und der nachfolgenden Clientkonfiguration.
Das VPN steht soweit. Problem ist, das in sehr unregelmäßigen Abständen die Citrix-Sitzungen kurz getrennt werden und wieder aufgebaut werden (keine Meldung im Eventlog).
Wer kann uns ggf. weiterhelfen. Wir haben schon versucht, auf das Protokoll TCP umzustellen. Dann sind zwar die Probleme mit den wegfliegenden Citrix-Sitzungen so gut wie nicht mehr vorhanden, jedoch geht die Performance sehr zurück und einer unserer Standorte kann innerhalb Citrix - bedingt durch schwache Anbindung (1MBit-Standleitung) – kaum noch arbeiten. Die Lösung einer stärkeren Standleitung kommt jedoch aus Kostengründen für uns nicht in Frage.
Wer hat dort eine Idee ? Liegt es ggf. am LINKSYS? Gibt es evt. besserer Router für OpenVPN.
Konfiguration OpenVPN-Server:
port 763
proto udp
mode server
tls-server
dev tap
dev-node OpenVPN-WAN
ifconfig 10.100.0.1 255.255.255.0
client-config-dir c:\\Programme\\OpenVPN\\config\\ccd
dh c:\\Programme\\OpenVPN\\secrets\\dh1024.pem
ca c:\\Programme\\OpenVPN\\secrets\\ca.crt
key c:\\Programme\\OpenVPN\\secrets\\grzis4.key
cert c:\\Programme\\OpenVPN\\secrets\\grzis4.crt
comp-lzo
push "route-gateway 10.100.0.1"
push "route 192.168.202.0 255.255.255.0"
push "dhcp-option DNS 192.168.202.8"
push "dhcp-option WINS 192.168.202.8"
tun-mtu 1500
tun-mtu-extra 32
verb 3
mute 50
keepalive 10 60
ping-timer-rem
persist-key
persist-tun
push "ping 10"
push "ping-restart 60"
push "ping-timer-rem"
Konfiguration OpenVPN-Client auf LINKSYS WRT54GL (DD-WRT):
cd /tmp
mkdir /tmp/ovpn
ln -s /usr/sbin/openvpn /tmp/ovpn/ovpn
/tmp/ovpn/ovpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc up
sleep 5
echo "
client
daemon
dev tap0
proto udp
tls-client
remote xxx.xxx.xxx 763
resolv-retry infinite
nobind
persist-key
persist-tun
ca /tmp/ovpn/ca.crt
cert /tmp/ovpn/gshr-001.crt
key /tmp/ovpn/gshr-001.key
dh /tmp/ovpn/dh1024.pem
ns-cert-type server
comp-lzo
verb 3
pull
tun-mtu 1500
tun-mtu-extra 32
" > /tmp/ovpn/gshr-001.config
echo "
BEGIN CERTIFICATE-----
xxx
END CERTIFICATE-----
" > /tmp/ovpn/ca.crt
echo "
BEGIN RSA PRIVATE KEY-----
xxx
END RSA PRIVATE KEY-----
" > /tmp/ovpn/gshr-001.key
chmod 600 /tmp/ovpn/gshr-001.key
echo "
BEGIN CERTIFICATE-----
xxx
END CERTIFICATE-----
" > /tmp/ovpn/gshr-001.crt
echo "
BEGIN DH PARAMETERS-----
xxx
END DH PARAMETERS-----
" > /tmp/ovpn/dh1024.pem
sleep 5
/tmp/ovpn/ovpn --config /tmp/ovpn/gshr-001.config
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 126096
Url: https://administrator.de/contentid/126096
Printed on: April 19, 2024 at 16:04 o'clock
1 Comment
Nach deiner Konfig zu urteilen nutzt du vermutlich aus Gründen der Einfachheit ein Bridging Szenario mit OpenVPN. Das ist bei VPN Verbindungen sehr kontraproduktiv, da du den VPN Tunnel mit der erheblichen Broadcast Last im Netzwerk von Windows belastest. Der VPN Tunnel transportiert also eigentlich sinnlosen Traffic der ihn in seiner Performance erheblich beeinträchtigt !
Vermutlich bricht dadurch durch Überlast aufgrund des eigentlich überflüssigen Broadcast Overheads der VPN Tunnel kurzzeitig weg. Logisch das da ein Schwenk auf TCP nichts bringt bzw. die ganze Sache eher noch verschlimmert durch erhöhten CPU Aufwand des Routers bei der Encapsulierung in TCP Pakete !
Gerade im Hinblick auf die 1 Mbit Anbindung solltest du dringenst auf ein geroutetes VPN Szenario umschwenken wie es in der Regel auch üblich ist bei VPN Verbindungen !
Vermutlich wird das deine Probleme auf Schlag lösen, denn in der Allgemeinen hat der WRT54 so keinerlei Performance Probleme mit OpenVPN.
Wie man ein geroutetes Szenario mit dem WRT54 aufsetzt beschreibt dir dieses Tutorial im Detail:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Nochwas: UDP 763 zu verwenden ist nicht gerade sehr intelligent und zeugt eigentlich von wenig Sorgfalt oder Wissen bei der VPN Planung
, denn das ist ein international von der IANA reservierter Port und du erzeugts somit einen Konflikt im Netzwerk !!
http://www.auditmypc.com/port/udp-port-763.asp
Du solltest generell keine Ports unter 1024 benutzen, denn die sind alle dediziert von der IANA reserviert !! Wenn du es nicht unbedingt musst wie z.B. 22 oder 443 um ein SSL Schlupfloch in der Firewall zu nutzen solltest du immer den OpenVPN Standard Port benutzen mit UDP 1194.
Wenn du es dennoch unbedingt ändern willst dann nimm Ports über 50000 wie z.B. 51194. Von der Portnummer hat das etwas Bezug zum OpenVPN Port und so kann man beim Sniffern ggf. sofort diese Pakete identifizieren !
Vermutlich bricht dadurch durch Überlast aufgrund des eigentlich überflüssigen Broadcast Overheads der VPN Tunnel kurzzeitig weg. Logisch das da ein Schwenk auf TCP nichts bringt bzw. die ganze Sache eher noch verschlimmert durch erhöhten CPU Aufwand des Routers bei der Encapsulierung in TCP Pakete !
Gerade im Hinblick auf die 1 Mbit Anbindung solltest du dringenst auf ein geroutetes VPN Szenario umschwenken wie es in der Regel auch üblich ist bei VPN Verbindungen !
Vermutlich wird das deine Probleme auf Schlag lösen, denn in der Allgemeinen hat der WRT54 so keinerlei Performance Probleme mit OpenVPN.
Wie man ein geroutetes Szenario mit dem WRT54 aufsetzt beschreibt dir dieses Tutorial im Detail:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Nochwas: UDP 763 zu verwenden ist nicht gerade sehr intelligent und zeugt eigentlich von wenig Sorgfalt oder Wissen bei der VPN Planung
, denn das ist ein international von der IANA reservierter Port und du erzeugts somit einen Konflikt im Netzwerk !!http://www.auditmypc.com/port/udp-port-763.asp
Du solltest generell keine Ports unter 1024 benutzen, denn die sind alle dediziert von der IANA reserviert !! Wenn du es nicht unbedingt musst wie z.B. 22 oder 443 um ein SSL Schlupfloch in der Firewall zu nutzen solltest du immer den OpenVPN Standard Port benutzen mit UDP 1194.
Wenn du es dennoch unbedingt ändern willst dann nimm Ports über 50000 wie z.B. 51194. Von der Portnummer hat das etwas Bezug zum OpenVPN Port und so kann man beim Sniffern ggf. sofort diese Pakete identifizieren !
