Hi OpenVPN Users,
cause of my real bad english, and some wrong/confusing and/or
incomplete statements in the last mail,
I rewrote it... Please excuse the last bad email about this issue.
I have a serious problem with OpenVPN: If a client successful connects, my
OpenVPN Server runs out of reachability at iso/osi level level 4 (TCP/UDP).
The interesting thing is that ping works...
What I have done?
1. /usr/local/sbin/openvpn --mktun --dev tap0
2. brctl addbr br0
3. ifconfig br0 _myip_eth0_ netmask _mynetmask_eth0_
4. brctl addif br0 tap0
5. brctl addif br0 eth0
6. ifconfig tap0 0.0.0.0 promisc up
7. ifconfig eth0 0.0.0.0 promisc up; route add default gw _my_eth0_default_gw_
8. iptables -F
9. iptables -F -t nat
10. /usr/local/sbin/openvpn --config /etc/openvpn/server.conf
It think this is the norm proceeding as usual for bridging. If now a
client connects, the server is after some seconds unreachable, and
then only ping works at all.
Already opened connections, e.g. ssh connections, doesn't react
anymore. But the thing is, that within the first minutes of the
occuring of the problem, sometimes communication works for less than
a second (or something like that), so that a rush of messages, which
are cucumulated on the server side, reach the ssh client. If I enter
a command ahead into the hanging ssh client before that event, it
sometimes runs it and shows immediatly the result at this occurrence.
But as more time flies as higher is the probability that the connection
is timed out. After some minutes no session remains in connected state.
New connections doesn't work at all. This effect and the fact that
ping works shows, that there isn't a categorical connection problem
which could be the cause. I also had have till now never problems
like this with this server at all.
Naturally I investigated this behaviour: I tested with udp, if
packets can't be send to the server and/or if the receiving is the
problem. A tcpdump in a "screen" shows as if the server isn't
receiving udp (of course also tcp) packtes during the problem:
They aren't shown in a "tcpdump -n -i eth0". If the server (tries)
to sends packets, they are shown in "tcpdump -n -i eth0", but they
doen't reach the destination. I tried this with more than one
another host than the vpn-client.
I also took a pcap record, maybe the mac adress (hardware
iso/osi level 2 adress of the network card) is a factor. But this
isn't the case. There is no differences in working packages and
not working packages I can see in tcpdump, especially the mac
adresses are the same.
I did run a script which records changes to iptables, ifconfig
and netstat -nr, in screen too. Also there is no change during
the occurence of the problem to see... beside the increasing
of the counts of RX/TX Packets/Bytes of the interfaces in ifconfig.
... and the error counter of tap allways increases.
I know problems like this if I add the eth0 to the bridge. But this
is only a short onetime effect. Here I have a persistent problem.
Maybe OpenVPN generates this problem by continuous and non-stoping
reinitialysing of the bridge? But I can't find any hint about that
in the Logfile at "verb 6". Maybe this isn't logged?
The funny thing is, that I had a bridging tunnel already running,
exactly with this kernel, but OpenVPN in Version 2.0RC1.
My openvpn/kernel version on server is:
websrv tmp # uname -a
Linux websrv.pRiV.de 2.6.11.11 #1 SMP Mon May 30 21:30:10 i686 Celeron
(Coppermine) GenuineIntel GNU/Linux
websrv tmp # /usr/local/sbin/openvpn |head -n 1
OpenVPN 2.0.2 i686-pc-linux [SSL] [LZO] built on Sep 2 2005
websrv tmp #
I welcome any help. Maybe somebody knows how to make seeable if the
kernel drops pakets, and at best also the cause of this?
The "verb 6"-Log of the Server, and also the config of server and client,
is available at
http://www.priv.de/openvpnproblem/.
Regards
Markus Mueller
|