Problem mit OpenVPN - Inacticity Timeout (--ping-restart)

[d@tenmaulwurf]

Morgen!

Ich habe eine OpenVPN-PKI-Lösung gebastelt, die auch in einem großen LAN hervorragend funktioniert.
Die gleiche Config habe ich jetzt genommen, um zwischen einem root-Server und mir verbinden zu können (feste IP).
Hier bekomme ich jetzt jedes Mal in den log (ca alle 5 min) einen Inactivity-Timeout.
Soweit ja irgendwie noch ok (obwohl es so ein Problem innerhalb des LANS mit der selben Config nicht gibt)., aber er macht sofort nach diesem Disconnect wieder einen Reconnect, was mir unlogisch erscheint.
Warum resetted er die Verbindung mit dem Grund sie wird nicht genutzt, um sie gleich wieder aufzubauen ?!

Genaue Fehlermeldung ist (Client-Log):

Code: Select all

Sun 01/29/06 02:18 PM: [DOMAIN.de] Inactivity timeout (--ping-restart)
Sun 01/29/06 02:18 PM: TCP/UDP: Closing socket
Sun 01/29/06 02:18 PM: SIGUSR1[soft
Sun 01/29/06 02:18 PM: Re-using SSL/TLS context  // hier geht's dann wieder an den reconnect

Clientconfig:

Code: Select all

client
dev tun
remote DOMAIN.de         // Domain verweist auf eine feste IP - kein DynDNS
tls-client
ca ca.crt
cert 1.crt
key 1.key
proto udp
port 1194
persist-key
persist-tun
user nobody
group nobody              // kein nogroup, da *BSD
comp-lzo
verb 3
log openvpn.log
ns-cert-type server

Serevrconfig:

Code: Select all

dev tun
server 172.16.0.0 255.255.255.0
tls-server
dh dh4096.pem
ca ca.crt
cert server.crt
key server.key
proto udp
port 1194
persist-key
persist-tun
user nobody
group nogroup
comp-lzo
verb 4
log /var/log/openvpn.log

Und hier nochmal ein Auszug aus der Serverlog, folgender Abschnitt wiederholt sich durch die reconnects immer wieder:

Code: Select all

Sun Jan 29 14:22:26 2006 us=469395 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 TLS: new session incoming connection from 85.178.39.216:1194
Sun Jan 29 14:22:32 2006 us=171703 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 VERIFY OK: depth=1, /C=DE/ST=Berlin/L=Berlin/O=DOMAIN_GbR/OU=Internet_Services/CN=DOMAIN.de/emailAddress=service@DOMAIN.de
Sun Jan 29 14:22:32 2006 us=174363 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 VERIFY OK: depth=0, /C=DE/ST=Berlin/O=FIRMA_GbR/OU=OpenVPN/CN=VORNAME_NACHNAME_-_KUNDENNUMMER/emailAddress=EMAIL@DOMAIN2
Sun Jan 29 14:22:32 2006 us=875342 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jan 29 14:22:32 2006 us=875370 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jan 29 14:22:32 2006 us=875424 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jan 29 14:22:32 2006 us=875438 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jan 29 14:22:32 2006 us=875477 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Sun Jan 29 14:22:32 2006 us=875662 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 TLS: tls_multi_process: untrusted session promoted to trusted
Sun Jan 29 14:22:32 2006 us=920984 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
Sun Jan 29 14:22:34 2006 us=86044 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 PUSH: Received control message: 'PUSH_REQUEST'
Sun Jan 29 14:22:34 2006 us=86107 VORNAME_NACHNAME_-_KUNDENNUMMER/85.178.39.216:1194 SENT CONTROL [VORNAME_NACHNAME_-_KUNDENNUMMER]: 'PUSH_REPLY,route 172.16.0.1,ifconfig 172.16.0.6 172.16.0.5' (status=1)

Vielen Dank im voraus,

so long,

d@tenmaulwurf

[dodolin]

Code: Select all

Sun 01/29/06 02:18 PM: [DOMAIN.de] Inactivity timeout (--ping-restart) 
Sun 01/29/06 02:18 PM: TCP/UDP: Closing socket 
Sun 01/29/06 02:18 PM: SIGUSR1[soft 

Guckst du, manpage zu --ping-restart:

Code: Select all

       --ping-restart n
              Similar  to  --ping-exit,  but trigger a SIGUSR1 restart after n
              seconds pass without reception of a ping or  other  packet  from
              remote.

              This  option  is useful in cases where the remote peer has a dy-
              namic IP address and a low-TTL DNS name is used to track the  IP
              address  using  a service such as http://dyndns.org/ + a dynamic
              DNS client such as ddclient.

              If the peer cannot be reached,  a  restart  will  be  triggered,
              causing  the  hostname  used with --remote to be re-resolved (if
              --resolv-retry is also specified).

              In server mode, --ping-restart, --inactive, or any other type of
              internally generated signal will always be applied to individual
              client instance objects, never to whole server itself.  Note al-
              so  in  server  mode  that any internally generated signal which
              would normally cause a restart, will cause the deletion  of  the
              client instance object instead.

              In  client mode, the --ping-restart parameter is set to 120 sec-
              onds by default.  This default will hold until the client  pulls
              a  replacement  value  from the server, based on the --keepalive
              setting in the server configuration.  To disable the 120  second
              default, set --ping-restart 0 on the client.

              See the signals section below for more information on SIGUSR1.

              Note  that the behavior of SIGUSR1 can be modified by the --per-
              sist-tun, --persist-key, --persist-local-ip,  and  --persist-re-
              mote-ip options.

              Also  note  that --ping-exit and --ping-restart are mutually ex-
              clusive and cannot be used together.

Vielleicht möchtest du also ping-restart 0 und/oder persist-tun setzen und austesten, ob das hilft.

[d@tenmaulwurf]

Danke :)

Aber guckst du hier:

"remote DOMAIN.de // Domain verweist auf eine feste IP - kein DynDNS"

Habe es auch schon versucht - bringt aber nix :|

[mr. pink]

Versuch doch mal die keepalive funktion:

Code: Select all

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

[d@tenmaulwurf]

Auch nicht.

Ich habe jetzt einfach mal von udp auf TCP umgestellt - gleicher Port - gleiche Config - nur halt das Protkoll auf Server- und Client-Seite verändert. Jetzt bleibt die Verbindung aufrecht.

Ich kann aber nicht TCP nehmen, weil ich TCP Trafic tunneln möchte. Wo zur Hölle liegt genau das Problem ?! :(