Hallo!
Ich habe ein kleines Problem mit meiner OpenVPN 2.0 Installation auf SuSE 9.3. OpenVPN habe ich einfach per Yast installiert. Bei der Konfiguration habe ich mich strikt an das HowTo der Projektseite gehalten (http://openvpn.net/howto.html).
Die „normale“ Installation mit der gerouteten Konfiguration hat wunderbar funktioniert. Der Tunnel läßt sich ohne Probleme mit meinem WinXP SP2 Client aufbauen. Auf diesem habe ich den OpenVPN GUI 1.0 installiert. Ping und Nutzung von Diensten auf den Kisten klappt ohne Probleme.
Jetzt möchte ich aber einen bridged Tunnel aufbauen um Broadcast aus/in das „Heimnetz“ zu schicken.
Dafür habe ich mich wieder an das HowTo (http://openvpn.net/bridge.html) gehalten. Habe die Einstellungen in den Configs angepasst und das tap0 Device per beiliegendem Script eingerichtet.
Wenn ich jetzt versuche die Verbindung aufzubauen, haut (fast) alles hin. Aber aus irgendeinem Grunde, kommt das tap Device auf Server Seite anscheinend nicht hoch. Der Client meldet mir nämlich das er darauf warten würde. Das versucht er dann so lange bis ich abbreche.
Ein ifconfig auf der Linux Kiste zeigt mir die bridge und das tap Device aber an.
Ich weiß leider nicht mehr weiter und habe die Configs schon zig mal kontrolliert. Ich schätze mal, das es irgendwo an den tap/br Devices auf Linux Seite liegt.
Danke für eure Hilfe!
PS: Bevor die Frage kommt. Firewall etc. ist abgeschaltet 
.
Ich weiß leider nicht mehr weiter und habe die Configs schon
zig mal kontrolliert. Ich schätze mal, das es irgendwo an den
tap/br Devices auf Linux Seite liegt.
Was sagt denn die syslog a) zum Start des Servers, b) zu den Versuchen des Clients, zum Server zu verbinden?
Gruss
Schorsch
Also ich konnte unter /var/log/messages folgendes finden:
Aug 15 16:49:15 pc010100 openvpn[28363]: MULTI: multi\_create\_instance called
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Re-using SSL/TLS context
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 LZO compression initialized
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Control Channel MTU parms [L:1574 D:138 EF:38 EB:0 ET:0 EL:0]
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Data Channel MTU parms [L:1574 D:1450 EF:42 EB:23 ET:32 EL:0 AF:3/1]
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Local Options hash (VER=V4): 'f7df56b8'
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Expected Remote Options hash (VER=V4): 'd79ca330'
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 TLS: Initial packet from 10.1.22.205:4019, sid=f9da5a1d 8bfd50d0
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 VERIFY OK: depth=1, /C=DE/ST=NRW/L=Bielefeld/O=OpenVPN-TEST/CN=pc010100/[email protected]
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 VERIFY OK: depth=0, /C=DE/ST=NRW/O=OpenVPN-TEST/CN=lt011096/[email protected]
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug 15 16:49:15 pc010100 openvpn[28363]: 10.1.22.205:4019 [lt011096] Peer Connection Initiated with 10.1.22.205:4019
Aug 15 16:49:16 pc010100 openvpn[28363]: lt011096/10.1.22.205:4019 PUSH: Received control message: 'PUSH\_REQUEST'
Aug 15 16:49:16 pc010100 openvpn[28363]: lt011096/10.1.22.205:4019 SENT CONTROL [lt011096]: 'PUSH\_REPLY,route-gateway 10.1.1.100,ping 10,ping-restart 120,ifconfig 10.1.0.226 255.224.0.0' (status=1)
Aug 15 16:49:26 pc010100 openvpn[28363]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Aug 15 16:49:26 pc010100 openvpn[28363]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Aug 15 16:49:36 pc010100 openvpn[28363]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Testest du innerhalb eines lokalen (10.x.y.z) Netzes?
In
[…] openvpn[28363]: 10.1.22.205:4019 TLS: Initial packet from 10.1.22.205:4019, sid=f9da5a1d 8bfd50d0
sollte als from eine öffentliche Adresse auftauchen. Erst baust du die Verbindung auf, dann wird gebridget. Die Adresse des fernen Netzes ist beliebig, mir scheint, dass du in vorauseilendem Gehorsam dem fernen Netz schon einen Adressbereich vorgegeben hast, den zuzuteilen nur OpenVPN zusteht.
Schnapp dir ein Notebook, richte es entsprechend ein, und versuche dann via GPRS oder UMTS das Bridging aufzubauen.
HTH
Schorsch
Ich teste das im Moment in unserem internen LAN. Ein Test von außen ist leider nicht möglich. Mein Chef möchte nicht, das ich die Ports in der Firewall aufreiße.
Der Server hat die IP 10.1.1.100 und mein Laptop die IP 10.1.22.205. Beide liegen im gleichen Subnet.
Ich habe mal die Configs ausgemistet und alle Kommentare ausgebaut und nur die aktiven Optionen eingebaut:
server.cfg:
port 1194
proto udp
dev tap0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.1.1.100 255.224.0.0 10.1.0.226 10.1.0.227
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
client.cfg:
client
dev tap
proto udp
remote 10.1.1.100 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:\\Programme\\OpenVPN\\easy-rsa\\keys\\ca.crt
cert C:\\Programme\\OpenVPN\\easy-rsa\\keys\\client1.crt
key C:\\Programme\\OpenVPN\\easy-rsa\\keys\\client1.key
comp-lzo
verb 3
Vielleicht hilft dir das weiter.
MfG
Michael
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Jetzt hat sich noch ein erneutes Problem ergeben! Wenn ich versuche die Bridge zu starten, passiert folgendes:
Tue Aug 16 11:06:56 2005 Note: Cannot ioctl TUNSETIFF tap0: Device or resource busy (errno=16)
Tue Aug 16 11:06:56 2005 Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Tue Aug 16 11:06:56 2005 TUN/TAP device /dev/tap0 opened
Tue Aug 16 11:06:56 2005 Cannot ioctl TUNSETPERSIST(1) tap0: Invalid argument (errno=22)
Tue Aug 16 11:06:56 2005 Exiting
Eine Idee wie ich das wieder grade biegen kann?
In beiliegendem Script zum erstellen der Bridge steht folgendes:
#!/bin/bash
#################################
# Set up Ethernet bridge on Linux
#################################
# Define Bridge Interface
br="br0"
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"
# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth\_ip="10.1.1.100"
eth\_netmask="255.224.0.0"
eth\_broadcast="10.31.255.255"
for t in $tap; do
openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth\_ip netmask $eth\_netmask broadcast $eth\_broadcast
Ich teste das im Moment in unserem internen LAN. Ein Test von
außen ist leider nicht möglich. Mein Chef möchte nicht, das
ich die Ports in der Firewall aufreiße.
Der Server hat die IP 10.1.1.100 und mein Laptop die IP
10.1.22.205. Beide liegen im gleichen Subnet.
In meinem letzten Posting habe ich einen ziemlichen Blödsinn geschrieben (Routing und Bridging im Hinterkopf wirr gemischt).
Ich habe mal die Configs ausgemistet und alle Kommentare
ausgebaut und nur die aktiven Optionen eingebaut:
Die Configs sehen soweit gut aus, was du noch machen könntest, wäre auf dem Client die Verbosity hochzusetzen und dir dann dessen Logfiles anzuschauen (üblicherweise unter …\programme\openvpn\log). Leider sind auf der OpenVPN-Seite die Fehlercodes nicht gelistet (oder ich habe sie nicht gefunden), der Code 111 in read UDPv4 [ECONNREFUSED]: Connection refused (code=111) sagt aber m. W. nur, dass der Client die Verbindung beendet hat. (eine Google-Suche http://www.google.de/search?hs=uel&hl=de&rls=de&q=op… könnte dir einige weitere Infos bringen).
Ich schätze daher, dass dein Problem auf dem XP-Client liegt.
HTH
Schorsch