Hello, I have an OpenVPN server that I run for personal use at one site. It is a very stable server that rarely needs any maintenance. It is still running the version of OpenVPN that was newest when it was built, which is 2.1_rc17, built on May 30 2009. A number of clients, both at that site and at remote locations, connect to this server and exchange data without issues. I recently installed OpenVPN 2.3.2 on a Windows 7 client. Configuration was just as easy as any other client I've done, but I am encountering a very curious problem of data corruption in connections made over the link. It is my understanding that this should be impossible, as TCP packet checksums will not match up, and yet, the evidence is pretty clear. Examples: [list] [*] Trying to SSH to another host on the VPN, PuTTy gives me the following message: "Incoming packet was garbled on decryption". Sometimes this happens before I even log in, other times I get a few commands in before the error comes up. [*] RDP connections to other hosts fail. Microsoft's Terminal Services Client gives the following error: "Because of a protocol error detected at the client, this session will be disconnected." Sometimes the error message includes a "(code 0x1104)" or a "(code 0x1204)" — the message, and thus the actual protocol error encountered, is not always the same. I get this message whether I am connecting to a Windows host or to xrdp on a UNIX host. [*] VNC connections sometimes connect but show heavily garbled screen representations.[/list] When I create a port redirection on an Internet-connected machine that allows direct connections to these services (not via the VPN), they succeed without issues. I've tried rebooting and installing the latest Windows Updates, but the problem persists. This is truly a confusing problem for me. I've never seen OpenVPN behave in this way before. Does anyone have any clues? :-) Many thanks, Jonathan Gilbert

Ah, right. :-) Server: [code]server 10.8.0.0 255.255.255.0 route 10.8.0.0 255.255.255.0 dev tun client-to-client ifconfig-pool-persist ipp.txt comp-lzo proto udp ca ca.crt cert server.crt key server.key dh dh1024.pem[/code] Working client: [code]client remote israel.logiclrd.cx dev tun resolv-retry infinite comp-lzo proto udp ca ca.crt cert laura.crt key laura.key[/code] Client exhibiting strange corrupt data: [code]client remote israel.logiclrd.cx dev tun resolv-retry infinite comp-lzo proto udp ca ca.crt cert JONATHAN-OPT990.crt key JONATHAN-OPT990.key[/code] The goal is, obviously, to identify the cause of the corruption and eliminate it. I will obtain logs and post them shortly. Thanks :-)

And just to confirm: [list] [*] I connected from RESONATOR to laliari and issued 'find /', and I got the entire listing of files, no data corruption. [*] When I try to connect to RESONATOR from JONATHAN-OPT990, I am immediately informed of protocol errors.[/list] The common denominator is JONATHAN-OPT990's link into the VPN. Thanks again :-)

There goes that theory -- 32-bit 2.2.2 on JONATHAN-OPT990 is exhibiting the same problem. [url]http://israel.logiclrd.cx/openvpn-corrupt-data-2.png[/url]

I've identified the nature of the corruption. I don't have any theories yet as to what is causing it, but small pieces of the file are being duplicated, appearing slightly earlier than the correct location and overwriting whatever bytes were there, sort of like this: [code] Correct: This is a sample sentence for demonstration purposes only. |-----------| | | .------------' | v |-----------| Corrupt: This is a samplr demonstratir demonstration purposes only. [/code] I don't see how this type of corruption could maintain the value of a TCP checksum, so that rules out my other theory. This is just plain bizarre. :-/

apparent data corruption over VPN link

logic

Hello,

I have an OpenVPN server that I run for personal use at one site. It is a very stable server that rarely needs any maintenance. It is still running the version of OpenVPN that was newest when it was built, which is 2.1_rc17, built on May 30 2009.

A number of clients, both at that site and at remote locations, connect to this server and exchange data without issues.

I recently installed OpenVPN 2.3.2 on a Windows 7 client. Configuration was just as easy as any other client I've done, but I am encountering a very curious problem of data corruption in connections made over the link. It is my understanding that this should be impossible, as TCP packet checksums will not match up, and yet, the evidence is pretty clear.

Examples:

Trying to SSH to another host on the VPN, PuTTy gives me the following message: "Incoming packet was garbled on decryption". Sometimes this happens before I even log in, other times I get a few commands in before the error comes up.
RDP connections to other hosts fail. Microsoft's Terminal Services Client gives the following error: "Because of a protocol error detected at the client, this session will be disconnected." Sometimes the error message includes a "(code 0x1104)" or a "(code 0x1204)" — the message, and thus the actual protocol error encountered, is not always the same. I get this message whether I am connecting to a Windows host or to xrdp on a UNIX host.
VNC connections sometimes connect but show heavily garbled screen representations.

When I create a port redirection on an Internet-connected machine that allows direct connections to these services (not via the VPN), they succeed without issues.

I've tried rebooting and installing the latest Windows Updates, but the problem persists.

This is truly a confusing problem for me. I've never seen OpenVPN behave in this way before. Does anyone have any clues? :-)

Many thanks,

Jonathan Gilbert

logic

Ah, right. :-)

Server:

server 10.8.0.0 255.255.255.0
route 10.8.0.0 255.255.255.0
dev tun
client-to-client
ifconfig-pool-persist ipp.txt
comp-lzo
proto udp

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

Working client:

client
remote israel.logiclrd.cx
dev tun
resolv-retry infinite
comp-lzo
proto udp
ca ca.crt
cert laura.crt
key laura.key

Client exhibiting strange corrupt data:

client
remote israel.logiclrd.cx
dev tun
resolv-retry infinite
comp-lzo
proto udp
ca ca.crt
cert JONATHAN-OPT990.crt
key JONATHAN-OPT990.key

The goal is, obviously, to identify the cause of the corruption and eliminate it.

I will obtain logs and post them shortly.

Thanks :-)

logic

Server log:

Mon Oct 21 14:20:48 2013 OpenVPN 2.1_rc17 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on May 30 2009
Mon Oct 21 14:20:48 2013 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Mon Oct 21 14:20:48 2013 WARNING: --keepalive option is missing from server config
Mon Oct 21 14:20:48 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Oct 21 14:20:48 2013 Diffie-Hellman initialized with 1024 bit key
Mon Oct 21 14:20:48 2013 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 21 14:20:48 2013 ROUTE default_gateway=10.128.0.4
Mon Oct 21 14:20:48 2013 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{35FAE714-D625-4112-911D-B7DB3DEE2D1C}.tap
Mon Oct 21 14:20:48 2013 TAP-Win32 Driver Version 9.4 
Mon Oct 21 14:20:48 2013 TAP-Win32 MTU=1500
Mon Oct 21 14:20:48 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.8.0.1/255.255.255.252 on interface {35FAE714-D625-4112-911D-B7DB3DEE2D1C} [DHCP-serv: 10.8.0.2, lease-time: 31536000]
Mon Oct 21 14:20:48 2013 Sleeping for 10 seconds...
Mon Oct 21 14:20:58 2013 Successful ARP Flush on interface [4] {35FAE714-D625-4112-911D-B7DB3DEE2D1C}
Mon Oct 21 14:20:58 2013 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Mon Oct 21 14:20:58 2013 Route addition via IPAPI succeeded [adaptive]
Mon Oct 21 14:20:58 2013 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Mon Oct 21 14:20:58 2013 Route addition via IPAPI succeeded [adaptive]
Mon Oct 21 14:20:58 2013 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 21 14:20:58 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Oct 21 14:20:58 2013 UDPv4 link local (bound): [undef]:1194
Mon Oct 21 14:20:58 2013 UDPv4 link remote: [undef]
Mon Oct 21 14:20:58 2013 MULTI: multi_init called, r=256 v=256
Mon Oct 21 14:20:58 2013 IFCONFIG POOL: base=10.8.0.4 size=62
Mon Oct 21 14:20:58 2013 IFCONFIG POOL LIST
Mon Oct 21 14:20:58 2013 WSSWPG45,10.8.0.4
Mon Oct 21 14:20:58 2013 WSSWPG44,10.8.0.8
Mon Oct 21 14:20:58 2013 WSSWPG38,10.8.0.12
Mon Oct 21 14:20:58 2013 laliari,10.8.0.16
Mon Oct 21 14:20:58 2013 laura,10.8.0.20
Mon Oct 21 14:20:58 2013 faster,10.8.0.24
Mon Oct 21 14:20:58 2013 WSSWPG56,10.8.0.28
Mon Oct 21 14:20:58 2013 BABY45,10.8.0.32
Mon Oct 21 14:20:58 2013 susesux,10.8.0.36
Mon Oct 21 14:20:58 2013 ELECTRON,10.8.0.40
Mon Oct 21 14:20:58 2013 TERACLUSTER,10.8.0.44
Mon Oct 21 14:20:58 2013 VIDEOHEAD,10.8.0.48
Mon Oct 21 14:20:58 2013 DEVSYSTEMA0AB,10.8.0.52
Mon Oct 21 14:20:58 2013 AI,10.8.0.56
Mon Oct 21 14:20:58 2013 ISRAEL,10.8.0.60
Mon Oct 21 14:20:58 2013 RESONATOR,10.8.0.64
Mon Oct 21 14:20:58 2013 laura,10.8.0.68
Mon Oct 21 14:20:58 2013 laliari,10.8.0.72
Mon Oct 21 14:20:58 2013 VIDEOHEAD,10.8.0.76
Mon Oct 21 14:20:58 2013 faster,10.8.0.80
Mon Oct 21 14:20:58 2013 slackoff,10.8.0.84
Mon Oct 21 14:20:58 2013 AI,10.8.0.88
Mon Oct 21 14:20:58 2013 slackoff2,10.8.0.92
Mon Oct 21 14:20:58 2013 REACTOR,10.8.0.96
Mon Oct 21 14:20:58 2013 RAIDER,10.8.0.100
Mon Oct 21 14:20:58 2013 WHEDON,10.8.0.104
Mon Oct 21 14:20:58 2013 JONATHAN-OPT990,10.8.0.108
Mon Oct 21 14:20:58 2013 Initialization Sequence Completed
Mon Oct 21 14:20:58 2013 MULTI: multi_create_instance called
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 Re-using SSL/TLS context
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 LZO compression initialized
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 Local Options hash (VER=V4): '530fdded'
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 Expected Remote Options hash (VER=V4): '41690919'
Mon Oct 21 14:20:58 2013 184.71.72.34:42893 TLS: Initial packet from 184.71.72.34:42893, sid=0f807ba6 69be8b1b
Mon Oct 21 14:21:02 2013 184.71.72.34:42893 VERIFY OK: depth=1, /C=CA/ST=MB/L=Winnipeg/O=DeltaQDevelopment/CN=israel.logiclrd.cx/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:02 2013 184.71.72.34:42893 VERIFY OK: depth=0, /C=CA/ST=MB/O=DeltaQDevelopment/CN=JONATHAN-OPT990/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:03 2013 184.71.72.34:42893 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:03 2013 184.71.72.34:42893 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:03 2013 184.71.72.34:42893 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:03 2013 184.71.72.34:42893 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:03 2013 184.71.72.34:42893 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Oct 21 14:21:03 2013 184.71.72.34:42893 [JONATHAN-OPT990] Peer Connection Initiated with 184.71.72.34:42893
Mon Oct 21 14:21:03 2013 JONATHAN-OPT990/184.71.72.34:42893 MULTI: Learn: 10.8.0.110 -> JONATHAN-OPT990/184.71.72.34:42893
Mon Oct 21 14:21:03 2013 JONATHAN-OPT990/184.71.72.34:42893 MULTI: primary virtual IP for JONATHAN-OPT990/184.71.72.34:42893: 10.8.0.110
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 PUSH: Received control message: 'PUSH_REQUEST'
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 SENT CONTROL [JONATHAN-OPT990]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ifconfig 10.8.0.110 10.8.0.109' (status=1)
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:05 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:06 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:07 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:08 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:09 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:09 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:09 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:09 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:09 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:09 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:10 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:10 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:10 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:10 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:10 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:14 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:20 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:21 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:36 2013 JONATHAN-OPT990/184.71.72.34:42893 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:38 2013 MULTI: multi_create_instance called
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Re-using SSL/TLS context
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 LZO compression initialized
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Local Options hash (VER=V4): '530fdded'
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Expected Remote Options hash (VER=V4): '41690919'
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 TLS: Initial packet from 10.128.0.66:1194, sid=3525a383 f0003ce3
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 VERIFY OK: depth=1, /C=CA/ST=MB/L=Winnipeg/O=DeltaQDevelopment/CN=israel.logiclrd.cx/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 VERIFY OK: depth=0, /C=CA/ST=MB/O=DeltaQDevelopment/CN=RESONATOR/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Oct 21 14:21:38 2013 10.128.0.66:1194 [RESONATOR] Peer Connection Initiated with 10.128.0.66:1194
Mon Oct 21 14:21:38 2013 RESONATOR/10.128.0.66:1194 MULTI: Learn: 10.8.0.66 -> RESONATOR/10.128.0.66:1194
Mon Oct 21 14:21:38 2013 RESONATOR/10.128.0.66:1194 MULTI: primary virtual IP for RESONATOR/10.128.0.66:1194: 10.8.0.66
Mon Oct 21 14:21:40 2013 MULTI: multi_create_instance called
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Re-using SSL/TLS context
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 LZO compression initialized
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Local Options hash (VER=V4): '530fdded'
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Expected Remote Options hash (VER=V4): '41690919'
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 TLS: Initial packet from 184.71.82.246:60923, sid=dbcb3beb 22d9bcd9
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 PUSH: Received control message: 'PUSH_REQUEST'
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 SENT CONTROL [RESONATOR]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ifconfig 10.8.0.66 10.8.0.65' (status=1)
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 VERIFY OK: depth=1, /C=CA/ST=MB/L=Winnipeg/O=DeltaQDevelopment/CN=israel.logiclrd.cx/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 VERIFY OK: depth=0, /C=CA/ST=MB/O=DeltaQDevelopment/CN=laliari/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Oct 21 14:21:40 2013 184.71.82.246:60923 [laliari] Peer Connection Initiated with 184.71.82.246:60923
Mon Oct 21 14:21:40 2013 laliari/184.71.82.246:60923 MULTI: Learn: 10.8.0.18 -> laliari/184.71.82.246:60923
Mon Oct 21 14:21:40 2013 laliari/184.71.82.246:60923 MULTI: primary virtual IP for laliari/184.71.82.246:60923: 10.8.0.18
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:40 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 laliari/184.71.82.246:60923 PUSH: Received control message: 'PUSH_REQUEST'
Mon Oct 21 14:21:41 2013 laliari/184.71.82.246:60923 SENT CONTROL [laliari]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ifconfig 10.8.0.18 10.8.0.17' (status=1)
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:41 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:42 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:43 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:43 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:43 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:44 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:44 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:44 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:44 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:44 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:44 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:45 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:45 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:45 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:45 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:45 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:46 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:47 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:48 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:48 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:48 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:48 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:49 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:49 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:49 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:50 2013 MULTI: multi_create_instance called
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Re-using SSL/TLS context
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 LZO compression initialized
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Local Options hash (VER=V4): '530fdded'
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Expected Remote Options hash (VER=V4): '41690919'
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 TLS: Initial packet from 10.128.0.101:1194, sid=db236924 3d31c374
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 VERIFY OK: depth=1, /C=CA/ST=MB/L=Winnipeg/O=DeltaQDevelopment/CN=israel.logiclrd.cx/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 VERIFY OK: depth=0, /C=CA/ST=MB/O=DeltaQDevelopment/CN=REACTOR/emailAddress=logic@deltaq.org.
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Oct 21 14:21:50 2013 10.128.0.101:1194 [REACTOR] Peer Connection Initiated with 10.128.0.101:1194
Mon Oct 21 14:21:50 2013 REACTOR/10.128.0.101:1194 MULTI: Learn: 10.8.0.98 -> REACTOR/10.128.0.101:1194
Mon Oct 21 14:21:50 2013 REACTOR/10.128.0.101:1194 MULTI: primary virtual IP for REACTOR/10.128.0.101:1194: 10.8.0.98
Mon Oct 21 14:21:51 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:51 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 PUSH: Received control message: 'PUSH_REQUEST'
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 SENT CONTROL [REACTOR]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ifconfig 10.8.0.98 10.8.0.97' (status=1)
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:53 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:54 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:55 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:55 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:55 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:55 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:56 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:57 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:58 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:59 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:59 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:59 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:21:59 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:00 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:01 2013 MULTI: multi_create_instance called
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Re-using SSL/TLS context
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 LZO compression initialized
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Local Options hash (VER=V4): '530fdded'
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Expected Remote Options hash (VER=V4): '41690919'
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 TLS: Initial packet from 10.128.0.4:1194, sid=2139cf38 435cfe46
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 VERIFY OK: depth=1, /C=CA/ST=MB/L=Winnipeg/O=DeltaQDevelopment/CN=israel.logiclrd.cx/emailAddress=logic@deltaq.org.
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 VERIFY OK: depth=0, /C=CA/ST=MB/O=DeltaQDevelopment/CN=ISRAEL/emailAddress=logic@deltaq.org.
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Oct 21 14:22:01 2013 10.128.0.4:1194 [ISRAEL] Peer Connection Initiated with 10.128.0.4:1194
Mon Oct 21 14:22:01 2013 ISRAEL/10.128.0.4:1194 MULTI: Learn: 10.8.0.62 -> ISRAEL/10.128.0.4:1194
Mon Oct 21 14:22:01 2013 ISRAEL/10.128.0.4:1194 MULTI: primary virtual IP for ISRAEL/10.128.0.4:1194: 10.8.0.62
Mon Oct 21 14:22:01 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:01 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:02 2013 REACTOR/10.128.0.101:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:03 2013 ISRAEL/10.128.0.4:1194 PUSH: Received control message: 'PUSH_REQUEST'
Mon Oct 21 14:22:03 2013 ISRAEL/10.128.0.4:1194 SENT CONTROL [ISRAEL]: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ifconfig 10.8.0.62 10.8.0.61' (status=1)
Mon Oct 21 14:22:03 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:06 2013 RESONATOR/10.128.0.66:1194 Need IPv6 code in mroute_extract_addr_from_packet
Mon Oct 21 14:22:07 2013 TCP/UDP: Closing socket
Mon Oct 21 14:22:07 2013 C:\WINDOWS\system32\route.exe DELETE 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Mon Oct 21 14:22:07 2013 Route deletion via IPAPI succeeded [adaptive]
Mon Oct 21 14:22:07 2013 C:\WINDOWS\system32\route.exe DELETE 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Mon Oct 21 14:22:07 2013 ROUTE: route deletion failed using DeleteIpForwardEntry: The parameter is incorrect.  
Mon Oct 21 14:22:07 2013 Route deletion via IPAPI failed [adaptive]
Mon Oct 21 14:22:07 2013 Route deletion fallback to route.exe
Mon Oct 21 14:22:07 2013 Closing TUN/TAP interface
Mon Oct 21 14:22:07 2013 SIGTERM[hard,] received, process exiting

Client log:

Mon Oct 21 14:20:38 2013 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Mon Oct 21 14:20:38 2013 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mon Oct 21 14:20:38 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Oct 21 14:20:38 2013 UDPv4 link local (bound): [undef]
Mon Oct 21 14:20:38 2013 UDPv4 link remote: [AF_INET]24.77.237.43:1194
Mon Oct 21 14:20:45 2013 TLS: Initial packet from [AF_INET]24.77.237.43:1194, sid=7188b281 94e72d94
Mon Oct 21 14:20:45 2013 VERIFY OK: depth=1, C=CA, ST=MB, L=Winnipeg, O=DeltaQDevelopment, CN=israel.logiclrd.cx, emailAddress=logic@deltaq.org.
Mon Oct 21 14:20:45 2013 VERIFY OK: depth=0, C=CA, ST=MB, O=DeltaQDevelopment, CN=server, emailAddress=logic@deltaq.org.
Mon Oct 21 14:20:50 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:20:50 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:20:50 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Oct 21 14:20:50 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 21 14:20:50 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Oct 21 14:20:50 2013 [server] Peer Connection Initiated with [AF_INET]24.77.237.43:1194
Mon Oct 21 14:20:52 2013 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Oct 21 14:20:52 2013 PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.0 255.255.255.0,topology net30,ifconfig 10.8.0.110 10.8.0.109'
Mon Oct 21 14:20:52 2013 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 21 14:20:52 2013 OPTIONS IMPORT: route options modified
Mon Oct 21 14:20:52 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Oct 21 14:20:52 2013 open_tun, tt->ipv6=0
Mon Oct 21 14:20:52 2013 TAP-WIN32 device [OpenVPN Connection] opened: \\.\Global\{93C4FDB2-320D-4480-8232-ADE7191E0FC8}.tap
Mon Oct 21 14:20:52 2013 TAP-Windows Driver Version 9.9 
Mon Oct 21 14:20:52 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.110/255.255.255.252 on interface {93C4FDB2-320D-4480-8232-ADE7191E0FC8} [DHCP-serv: 10.8.0.109, lease-time: 31536000]
Mon Oct 21 14:20:52 2013 Successful ARP Flush on interface [20] {93C4FDB2-320D-4480-8232-ADE7191E0FC8}
Mon Oct 21 14:20:57 2013 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Mon Oct 21 14:20:57 2013 C:\Windows\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.109
Mon Oct 21 14:20:57 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Mon Oct 21 14:20:57 2013 Route addition via IPAPI succeeded [adaptive]
Mon Oct 21 14:20:57 2013 Initialization Sequence Completed
Mon Oct 21 14:21:49 2013 C:\Windows\system32\route.exe DELETE 10.8.0.0 MASK 255.255.255.0 10.8.0.109
Mon Oct 21 14:21:49 2013 Route deletion via IPAPI succeeded [adaptive]
Mon Oct 21 14:21:49 2013 Closing TUN/TAP interface
Mon Oct 21 14:21:49 2013 SIGTERM[hard,] received, process exiting

During this session, I connected from JONATHAN-OPT990 to laliari through the VPN via SSH, issued 'find /', and was promptly informed that an incoming packet "was garbled on decryption." As far as I can tell, no log entries were written when this occurred; it appears to be something OpenVPN is unaware of.

Thanks :-)

logic

And just to confirm:

I connected from RESONATOR to laliari and issued 'find /', and I got the entire listing of files, no data corruption.
When I try to connect to RESONATOR from JONATHAN-OPT990, I am immediately informed of protocol errors.

The common denominator is JONATHAN-OPT990's link into the VPN.

Thanks again :-)

logic

I've prepared a screenshot showing the corruption in a VNC connection. I've censored some parts of the image, but the effects of the corrupt data are clearly visible on the right-hand monitor. On the left side, a separate VNC connection can be seen to the same computer but without going through the OpenVPN tunnel. If the corruption were not present, the two monitors would be showing identical views.

http://israel.logiclrd.cx/openvpn-corrupt-data.png

Thanks, :-)

logic

Well, simply because of having been installed at various times, there are probably a wide variety of OpenVPN versions across the machines in this network. JONATHAN-OPT990, running 64-bit 2.3.2 on Windows 7, is the most recently-configured. The next-newest installation is probably whedon, running 64-bit 2.2.2 on FreeBSD (pre-built package).

I'll try downgrading JONATHAN-OPT990 to 2.2.2 and see if that makes a difference. Thanks :-)

logic

There goes that theory -- 32-bit 2.2.2 on JONATHAN-OPT990 is exhibiting the same problem.

http://israel.logiclrd.cx/openvpn-corrupt-data-2.png

logic

I have working clients running Linux, FreeBSD, Windows XP and Windows 7. One of the Windows 7 clients was previously running Windows Server 2008.

Typical working systems have a single NIC, may or may not have virtualization software installed (which, of course, adds a virtual NIC or two), and connects to the Internet via NAT. The problematic system is Windows 7 64-bit with a single NIC, has VirtualBox installed and connects to the Internet via NAT. The integrity of the uplink doesn't really seem to be in question, because the corruption isn't happening low enough to interfere with the VPN's own framing. The machine is a development system with 16GB of RAM, frequently running multiple instances of Visual Studio. It has SQL Server installed. At any point in time, there are several dozen Chrome tabs open. I'm not aware of anything particularly unusual installed on it, and connections to the same resources that don't go through the OpenVPN tunnel are unaffected. For instance, another way to get whedon from JONATHAN-OPT990 is to connect to laliari's Internet interface with an SSH client that supports tunnelling and configure local ports to forward to desired endpoints on whedon. (laliari and whedon are on the same LAN.) This works without any issues at all. The whedon host is a hypervisor to two virtual machines, and their console VNC connection is both snappy and stable. Connecting to the port on whedon via OpenVPN from, say, RESONATOR works just fine, but the same connection from JONATHAN-OPT990 produces corrupt data.

I've just done an HTTP download of a file from RESONATOR onto JONATHAN-OPT990 through the OpenVPN tunnel, and then copied the same file via an alternative transport that doesn't use OpenVPN. I haven't yet had a chance to analyze how precisely the files differ, but they are definitely different, so I have, in essence, a captured sample of the data corruption. I'll post a reply if I find anything of interest.

logic

Mm, nope, that wasn't it. I've uninstalled VirtualBox, restarted, and tried again, and the symptoms are identical.

logic

Yeah, it's definitely an odd case. Logically, I don't think any of those can be the cause:

If it were a problem with the NIC, OpenVPN's own communication would be affected, and there would be broken packets logged. Connections outside of the VPN tunnel would also have issues.
If it were the memory, the system as a whole would be unstable. Any time a particular app got hold of a particular chunk of memory, it would encounter odd errors. Programs would be crashing left, right and centre and the OS would regularly bluescreen.
If the disk were corrupted, the system logs would be filled with I/O errors. Apps other than OpenVPN would be affected, and there wouldn't be a clean split between repeatably broken transfers through OpenVPN vs. repeatably clean transfers outside of the tunnel.

What's also especially weird about this is that OpenVPN is a layer 3 tunnel. TCP sits on top of it, and as far as it is concerned, the tunnel is logically the same type of thing as a network cable, moving 802.3 frames around, right? TCP has a checksum system in it, so wouldn't corrupt packets coming out of the VPN tunnel be detected by that and rejected by the TCP stack? But somehow, they're being accepted, and the client code using the TCP connection sees what appears to be a consistent stream of data -- just, the data isn't what was sent by the other side.

Logically, this means that either the TCP stack's checksumming algorithm isn't functional (could it be that the errors are being generated in such a way that the correct data and the broken data actually have the same checksum in each packet?), or the corruption is being introduced after the TCP stack, which would pretty much require it to be a bug in Windows itself (in the WinSock2 component perhaps?), at the boundary between kernel mode, where the data comes out of the TCP connection processing, and the user mode, where a buffer is magically filled when a 'recv()' call returns. I don't see how the latter case could know whether a connection was, lower down, going through the VPN tunnel or not, and if it is the case that it couldn't know, then that eliminates that as a possibility, and we're down to the TCP stack checksumming either being somehow inactive, or being ineffective for the type of corruption we're seeing.

The file I downloaded the other day, in which I captured an example of the corruption, contained binary data with many repetitive blocks with only small differences. I'm going to try a different test today, transferring a decent-sized block of text with no repetitions in it. If the data is being reordered or duplicated somehow, this should let me identify the exact nature of the corruption.

logic

I've identified the nature of the corruption. I don't have any theories yet as to what is causing it, but small pieces of the file are being duplicated, appearing slightly earlier than the correct location and overwriting whatever bytes were there, sort of like this:

Correct: This is a sample sentence for demonstration purposes only.
                                     |-----------|
                                           |
                                           |
                              .------------'
                              |
                              v
                        |-----------|
Corrupt: This is a samplr demonstratir demonstration purposes only.

I don't see how this type of corruption could maintain the value of a TCP checksum, so that rules out my other theory. This is just plain bizarre. :-/

logic

debbie10t wrotelogic, did you ever work out what was wrong here ?

Unfortunately not. I have so far had to resort to other, unencrypted channels to communicate out from the machine in question.

Thanks for following up. :-)

logic

The thing that's odd, though, is that if I recall correctly, I have other clients running the same newer version without issue. In any case, though, it is a fair suggestion, and I'm sure there are other good reasons to do that update. One of these days, when I have the time, I'll look into doing it and seeing if it fixes anything, but I do have the strong sense that it is a problem on the client side.

There is another, totally unrelated problem I've been noticing recently that might be a symptom of the same underlying problem. There's nothing certain to connect them at this point, but I have been finding that reloading Chrome when many tabs are saved produces corrupt images in many of the tabs. I wonder if perhaps the network card drivers are mixing up buffers in some way. Unfortunately, there is no newer version of those drivers currently available.

logic

Well, the client exhibiting the problem is running on Windows 7 64-bit and the network drivers in question were released last month, but yeah, for sure, I've noticed a number of companies have stopped bothering to make drivers for XP at all. :-)

SoSD

I've got a Windows 7 64-bit workstation that recently (in the past 6 months) began exhibiting very similar behavior. I've experienced very occasional issues with PuTTy SSH, and Remote Desktop connections even without a VPN active, but activating any VPN be it OpenVPN, or the standard Windows VPN (SSTP or L2TP/IPsec) immediately started causing bizarre data corruption issues with web sites, images, and so on.

Attempting to start an SSH or Remote Desktop session through the VPN would fail with the same error messages logic reported.

I did not really use VPN connections that often on the workstation and it took me a while to get around to troubleshooting it, but for the moment uninstalling the SonicWall VPN software *seems* to have resolved the problem. I'm a bit skeptical and will do some more testing on the workstation later to see if it the issue will crop up again or not, but it was very easy to replicate previously so hopefully this has done it.

The SonicWall software had been present for some time, and I don't recall there being any issues immediately after it had been installed, so perhaps there was some incompatibility with OpenVPN, or some other piece of software or driver update that had been introduced later.

At any rate, I will try to remember to update this thread in a week or so with whether or not the issue has been resolved on the workstation in question.

alanw

Same happening here Windows7 64.
Happened with Windows pptp connections as well as Sophos ( openvpn )
uninstalling Sonicwall 4.7.3 solved the issue for me.

Hitchcock

Just registered to say Thanks! 😃

I had the same problem and the answer was to uninstall SonicWall.

tony359

Hi

I register too since I have a very similar problem. I also had SonicWall 4.7.3 but uninstalling it did not help.

I'll keep trying, I have been uninstalling one by one all recent windows updates and software I have installed but so far no luck.

Attached an example of a VNC screen when I try to use it.
Any ideas appreciated!
Thanks

tony359

While the previous post was being approved - 10 days - I managed to find the solution: a virtual machine network protocol. Once removed, all returned to normal.