|
|
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 |