|
|
This is essentially the same setup I had under CIPE awhile back. I never had any corruption there. OpenVPN was the only change because CIPE had reconnect problems. I have noticed that the corruptions have lessened gradually with each new release of OpenVPN. As far as using tcpdump, I can't sit around watching hundreds of megabytes of packets going through trying to catch the bad segment that happens once every few days. I understand about the UDP layer having it's checksum, the VPN layer having its checksum (sha), and the TCP connection within the VPN (for FTP in this case) also having it's checksum. In reality I find it hard to believe that there could be a failure here, but this is the only place where the failures are showing up. The finger keeps pointing back to something withing the OpenVPN line of events. That's why I'm calling this a bug. Believe me, this isn't the first time I've sat down to troubleshoot this. I've been running OpenVPN for months now and have just put up with sporadic failures. Let's shift gears for a minute. How and where could it possibly fail? Can OpenVPN modify the data after it comes out of encryption? Does TCP checksumming really catch this? Could there be a problem with the tun device? Could it flub up the packet? Would the tap device be better to use? Thx/B++ *********** REPLY SEPARATOR *********** On 10/7/03 at 1:32 AM James Yonan wrote: >Brett, > >I think it's unlikely that OpenVPN could corrupt tunnel data simply because >OpenVPN exists "between" the FTP/TCP layers on both ends of the >connection. >Even if a bug in OpenVPN caused packet corruption, the packet would be >dropped >by the receiver because the TCP/IP checksum would not verify. > >You can test this by running tcpdump on the tun device on both ends of the >connection. > >If the corruption is happening at the OpenVPN/network layer, you will see a >good packet go "into" the tun device on one end but "come out" of the tun >device on the other end in a corrupted state. I think it's unlikely this >could occur simply because OpenVPN's HMAC-SHA1 authentication would catch >it. > And if the corruption occurred in OpenVPN after the HMAC-SHA1 >authentication >check, then the TCP/IP layer would catch it during checksum verification. > >On the other hand, if the corruption is happening at the FTP/TCP layer, you >would see FTP/TCP packets going "into" the tun device on the sender in an >already corrupted state, before they are even seen by OpenVPN. > >James > >Brett Johnson <maillist@xxxxxxx> said: > >> I'm having sporadic problems with OpenVPN corrupting data through the >tunnel. On the average this seems to happen a couple of times per week >with >my typical usage. I primarily send large files (100-300megs) through it by >ftp and periodically will fetch one or two per week. I'm the only one >using >this tunnel so there is no other traffic on it. >> >> I verify the transferred file by an MD5 sum once it is through. When a >file >corrupts, I'll check the ftp send (I use nohup and ncftpput/wget in a >script) >and will see no errors during the transfer. When the file is resent, it >will >pass the MD5 test on that try (so it isn't MD5 screwing up). >> >> I've noticed this problem from the start, but it hasn't really been high >enough priority to trouble shoot until now. I've been using OpenVPN for >many >months now and started on one of the early 1.3 versions I think. >> >> My previous VPN was using CIPE, but CIPE has some nasty reconnection >problems if something fails. Thankfully OpenVPN has never had those >problems. >:) CIPE never displayed these type of corruption errors when transferring >large files through it. I verified the CIPE files the same way I verify >these >files. >> >> Doing a post analysis on the corrupted files, the failure typically >happens >60-100megs through the transfer. The corruption does not happen at the >very >end of the file. >> >> Isn't VPN internal checksumming supposed to catch these kinds of errors >and >just resend the bad packet? >> >> I don't feel this has to do with my setup configuration as I would be >seeing >far more problems than a couple per week. >> >> My config: >> I'm using a normal udp tunnel. >> I'm using tun devices on both sides. >> I'm not bridging. >> Routing is properly setup on both ends. >> Both sides are using OpenVPN 1.4.3 compiled from the tar.gz made src.rpm. >> "client" side is Red Hat 9, kernel 2.4.20 compiled, OpenSSL 0.9.7a from >the >RH RPMs. >> "server" side is Red Hat 8, kernel 2.4.20 compiled, OpenSSL 0.9.7b >compiled >from source. >> config options are matched on both sides. >> >> Thx/B++ >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Openvpn-users mailing list >> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx >> https://lists.sourceforge.net/lists/listinfo/openvpn-users >> > > > >-- ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |