OpenVPN werkt niet sinds virtual network toevoeging

[G-Meister]

Al een geruime tijd heb ik een server draaien met daarop OpenVPN, alles werkte naar behoren alleen sinds ik een extra IP adres heb gekoppeld aan mijn netwerk adapter staat hij geen connecties meer toe.

Als ik verbinding maakt met de cliënt, krijg ik de melding "TLS key negotiation failed to occur within 60 seconds". Nu heb ik al de adviezen opgevolgd van OpenVPN om het zonder een firewall te proberen. Maar dit heeft niet geholpen (wat opzicht logisch is, aangezien hier verder niets aan veranderd is).

Helaas kan ik verder op het wereldwijde web ook niets vinden wat mij zou kunnen helpen met het probleem. Dus ik hoop dat één van jullie misschien weten wat het zou kunnen zijn. Hieronder de config files:

/etc/network/interfaces (Debian 6)

code:

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.2.200
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast       192.168.2.255
        gateway 192.168.2.254

auto eth0:1
iface eth0:1 inet static
        address 192.168.2.105
        netmask 255.255.255.0
        network 192.168.2.0
        broadcast       192.168.2.255
        gateway 192.168.2.254

/etc/openvpn/server.conf (Debian 6)

code:

port 8085
proto udp
dev tun
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
server 10.8.0.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
ifconfig-pool-persist ipp.txt
push "redirect-gateway"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.8.9"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 9

/var/log/daemon.log (Debian 6)

code:

Jul  4 12:14:00 server-1 ovpn-server[6275]: MULTI: REAP range 0 -> 16
Jul  4 12:14:00 server-1 ovpn-server[6275]: MULTI TCP: multi_tcp_action a=TA_TIMEOUT p=0
Jul  4 12:14:00 server-1 ovpn-server[6275]: MULTI TCP: multi_tcp_dispatch a=TA_TIMEOUT mi=0x00000000
Jul  4 12:14:00 server-1 ovpn-server[6275]: MULTI TCP: multi_tcp_post TA_TIMEOUT -> TA_UNDEF
Jul  4 12:14:00 server-1 ovpn-server[6275]: SCHEDULE: schedule_find_least NULL

client.conf (Windows 7)

code:

dev tun
client
proto udp
remote <IP ADRES> 8085
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 3

Client log (Windows 7)

code:

Wed Jul 04 11:22:47 2012 OpenVPN 2.1_rc19 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Jul 16 2009
Wed Jul 04 11:22:47 2012 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Wed Jul 04 11:22:47 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Jul 04 11:22:48 2012 LZO compression initialized
Wed Jul 04 11:22:48 2012 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Jul 04 11:22:48 2012 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jul 04 11:22:48 2012 Local Options hash (VER=V4): '41690919'
Wed Jul 04 11:22:48 2012 Expected Remote Options hash (VER=V4): '530fdded'
Wed Jul 04 11:22:48 2012 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Jul 04 11:22:48 2012 UDPv4 link local: [undef]
Wed Jul 04 11:22:48 2012 UDPv4 link remote: <IP>:8085
Wed Jul 04 11:23:48 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jul 04 11:23:48 2012 TLS Error: TLS handshake failed
Wed Jul 04 11:23:48 2012 TCP/UDP: Closing socket
Wed Jul 04 11:23:48 2012 SIGUSR1[soft,tls-error] received, process restarting
Wed Jul 04 11:23:48 2012 Restart pause, 2 second(s)

Alvast bedankt voor jullie hulp!

[Mijzelf]

Op welk adres luistert OpenVPN (netstat -ltp), en naar welk adres heb je geforward in je router?

En kun je de default gateway voor 'het andere' adres verwijderen, of levert dat andere problemen?

[Elijan9]

Ik weet niet wat je precies probeert te doen met dit virtuele netwerk? Maar dit komt doordat je nu twee gelijke routes voor de server hebt die terug naar het internet leiden, dit krijg je ook als je een tweede netwerkkaart zou instellen op dezelfde manier. Als de weg terug anders bewandeld wordt dan de heenweg dan krijg je deze error en het "gewicht" van eth0 en eth0:1 is het zelfde, het is dus om het even welke route wordt doorlopen op de terugweg.

Je kunt meerdere dingen proberen:

• De "multihome" optie in de server configuratie gebruiken zodat pakketten die op de ene interface binnenkomen vanaf dezelfde interface beantwoord worden.
• De openvpn server binden naar het IP adres waarop de openvpn client ook binnenkomt (m.b.v. "local") zodat OpenVPN zich alleen aan de juiste interface verbindt.
• Het tweede netwerk geen default gateway meegeven.
• De metrics van het tweede netwerk hoger zetten, zodat altijd de eerste bewandeld wordt.
• Een virtueel netwerk aanmaken die niet overlapt met je bestaande... Wat probeer je eigenlijk te bereiken?

[G-Meister]

Mag ik jullie beide hartelijk bedanken voor het antwoord! Ik heb bij eth0:1 de default gateway weggehaald en toen was inderdaad het probleem opgelost

De reden waarom ik een tweede virtuele netwerk heb gekoppeld is omdat ik eerst een extra server had staan. Aan deze server was een andere poort gekoppeld, omdat ik het zonde vond om 2 servers te draaien heb ik alles gemigreerd naar 1 server. Echter de glasvezel router van KPN (mensen die dit ding ook hebben kennen de frustratie), liet het maar niet toe om de andere poort open te zetten op IP 192.168.2.200. Zelfs na verschillende reboots bleef de poort dicht, terwijl hij wel telkens direct werkte op 192.168.2.105. Vandaar dat ik het op deze manier heb opgelost

Het is trouwens al een gelukje dat er überhaupt een poort open wil op deze routers, van de duizenden poorten die ik heb gescand. Kunnen er wel maximaal 5 open...

Nogmaals bedankt Mijzelf en Elijan9 voor jullie hulp

[ Voor 3% gewijzigd door G-Meister op 04-07-2012 13:14 ]

[TallManNL]

Nog een kleine aanpassing voor TS:
google DNS servers zijn 8.8.4.4 en 8.8.8.8.
8.8.8.9 is geen DNS server.

Klein puntje maar je kan het maar verbeterd hebben

[G-Meister]

TallManNL schreef op woensdag 04 juli 2012 @ 13:16:
Nog een kleine aanpassing voor TS:
google DNS servers zijn 8.8.4.4 en 8.8.8.8.
8.8.8.9 is geen DNS server.

Klein puntje maar je kan het maar verbeterd hebben

Thanks, het zijn de kleine dingen die het doen

[Mijzelf]

G-Meister schreef op woensdag 04 juli 2012 @ 13:11:
Echter de glasvezel router van KPN (mensen die dit ding ook hebben kennen de frustratie), liet het maar niet toe om de andere poort open te zetten op IP 192.168.2.200. Zelfs na verschillende reboots bleef de poort dicht, terwijl hij wel telkens direct werkte op 192.168.2.105. Vandaar dat ik het op deze manier heb opgelost

Dan heb je nu een nieuw probleem. De service die je op 192.168.2.105 hebt draaien is nu niet meer bereikbaar vanaf buiten. Want geen default gateway.

[G-Meister]

Mijzelf schreef op woensdag 04 juli 2012 @ 13:23:
[...]

Dan heb je nu een nieuw probleem. De service die je op 192.168.2.105 hebt draaien is nu niet meer bereikbaar vanaf buiten. Want geen default gateway.

Nee, dat functioneert nog gewoon.