Dropped UDP fragment

bitblit

I apologize for the cross post. I didn't notice the "Configuration" forum and couldn't delete my original wrongly placed post.

I have a virtual machine running on Linux with a non routable 172.16.0.81 ip address. I have a set of Windows PC's that use non-open source software to access other non-open source software on the virtual machine, but they require broadcasts. I have no problem when they are all collocated, but I setup OpenVPN to access the virtual machine remotely. I'll post my configs when I get back in on Monday. Both OpenVPN and the virtual machine use the same TAP on the Linux side. I can ping the VM from the Windows clients and both sides see the broadcast packets from each other. My non-open source software connects and starts doing its thing, but 1 UDP fragment gets dropped. The protocol is similar to TFTP. Hundreds of similar fragments get through, but this one magic bullet fragment just will not get through, and its the same fragment every time.

Below are 3 UDP fragments that get through successfully and recorded by Wireshark on the Windows box (sans payloads and target mac):

No.     Time        Source                Destination           Protocol Length Info
   1125 404.333982  172.16.168.1          172.16.0.81           IPv4     1514   Fragmented IP protocol (proto=UDP 0x11, off=0, ID=7280) [Reassembled in #1127]

Frame 1125: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
    Arrival Time: Nov 18, 2011 12:38:46.607803000 CST
    Epoch Time: 1321641526.607803000 seconds
    [Time delta from previous captured frame: 0.000491000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 404.333982000 seconds]
    Frame Number: 1125
    Frame Length: 1514 bytes (12112 bits)
    Capture Length: 1514 bytes (12112 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:data]
Ethernet II, Src: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
    Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        Address: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.168.1 (172.16.168.1), Dst: 172.16.0.81 (172.16.0.81)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 1500
    Identification: 0x7280 (29312)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xa21d [correct]
        [Good: True]
        [Bad: False]
    Source: 172.16.168.1 (172.16.168.1)
    Destination: 172.16.0.81 (172.16.0.81)
    Reassembled IPv4 in frame: 1127
Data (1480 bytes)



No.     Time        Source                Destination           Protocol Length Info
   1126 404.334031  172.16.168.1          172.16.0.81           IPv4     1514   Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7280) [Reassembled in #1127]

Frame 1126: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
    Arrival Time: Nov 18, 2011 12:38:46.607852000 CST
    Epoch Time: 1321641526.607852000 seconds
    [Time delta from previous captured frame: 0.000049000 seconds]
    [Time delta from previous displayed frame: 0.000049000 seconds]
    [Time since reference or first frame: 404.334031000 seconds]
    Frame Number: 1126
    Frame Length: 1514 bytes (12112 bits)
    Capture Length: 1514 bytes (12112 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:data]
Ethernet II, Src: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
    Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        Address: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.168.1 (172.16.168.1), Dst: 172.16.0.81 (172.16.0.81)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 1500
    Identification: 0x7280 (29312)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 1480
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xa164 [correct]
        [Good: True]
        [Bad: False]
    Source: 172.16.168.1 (172.16.168.1)
    Destination: 172.16.0.81 (172.16.0.81)
    Reassembled IPv4 in frame: 1127
Data (1480 bytes)



No.     Time        Source                Destination           Protocol Length Info
   1127 404.334087  172.16.168.1          172.16.0.81           UDP      670    Source port: 4414  Destination port: 60000

Frame 1127: 670 bytes on wire (5360 bits), 670 bytes captured (5360 bits)
    Arrival Time: Nov 18, 2011 12:38:46.607908000 CST
    Epoch Time: 1321641526.607908000 seconds
    [Time delta from previous captured frame: 0.000056000 seconds]
    [Time delta from previous displayed frame: 0.000056000 seconds]
    [Time since reference or first frame: 404.334087000 seconds]
    Frame Number: 1127
    Frame Length: 670 bytes (5360 bits)
    Capture Length: 670 bytes (5360 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
    Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        Address: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.168.1 (172.16.168.1), Dst: 172.16.0.81 (172.16.0.81)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 656
    Identification: 0x7280 (29312)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 2960
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xc3f7 [correct]
        [Good: True]
        [Bad: False]
    Source: 172.16.168.1 (172.16.168.1)
    Destination: 172.16.0.81 (172.16.0.81)
    [3 IPv4 Fragments (3596 bytes): #1125(1480), #1126(1480), #1127(636)]
        [Frame: 1125, payload: 0-1479 (1480 bytes)]
        [Frame: 1126, payload: 1480-2959 (1480 bytes)]
        [Frame: 1127, payload: 2960-3595 (636 bytes)]
        [Fragment count: 3]
        [Reassembled IPv4 length: 3596]
User Datagram Protocol, Src Port: 4414 (4414), Dst Port: 60000 (60000)
    Source port: 4414 (4414)
    Destination port: 60000 (60000)
    Length: 3596
    Checksum: 0xb11c [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (3588 bytes)

The following 3 fragments sent from the Windows box to the Linux server immediately after the previous 3 as recorded by Wireshark (sans payload). Packet number 1130 gets silently dropped and does not appear on the Linux side.

No.     Time        Source                Destination           Protocol Length Info
   1129 404.338438  172.16.168.1          172.16.0.81           IPv4     1514   Fragmented IP protocol (proto=UDP 0x11, off=0, ID=7284) [Reassembled in #1131]

Frame 1129: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
    Arrival Time: Nov 18, 2011 12:38:46.612259000 CST
    Epoch Time: 1321641526.612259000 seconds
    [Time delta from previous captured frame: 0.000511000 seconds]
    [Time delta from previous displayed frame: 0.004351000 seconds]
    [Time since reference or first frame: 404.338438000 seconds]
    Frame Number: 1129
    Frame Length: 1514 bytes (12112 bits)
    Capture Length: 1514 bytes (12112 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:data]
Ethernet II, Src: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
    Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        Address: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.168.1 (172.16.168.1), Dst: 172.16.0.81 (172.16.0.81)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 1500
    Identification: 0x7284 (29316)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xa219 [correct]
        [Good: True]
        [Bad: False]
    Source: 172.16.168.1 (172.16.168.1)
    Destination: 172.16.0.81 (172.16.0.81)
    Reassembled IPv4 in frame: 1131
Data (1480 bytes)



No.     Time        Source                Destination           Protocol Length Info
   1130 404.338487  172.16.168.1          172.16.0.81           IPv4     1514   Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7284) [Reassembled in #1131]

Frame 1130: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
    Arrival Time: Nov 18, 2011 12:38:46.612308000 CST
    Epoch Time: 1321641526.612308000 seconds
    [Time delta from previous captured frame: 0.000049000 seconds]
    [Time delta from previous displayed frame: 0.000049000 seconds]
    [Time since reference or first frame: 404.338487000 seconds]
    Frame Number: 1130
    Frame Length: 1514 bytes (12112 bits)
    Capture Length: 1514 bytes (12112 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:data]
Ethernet II, Src: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
    Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        Address: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.168.1 (172.16.168.1), Dst: 172.16.0.81 (172.16.0.81)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 1500
    Identification: 0x7284 (29316)
    Flags: 0x01 (More Fragments)
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..1. .... = More fragments: Set
    Fragment offset: 1480
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xa160 [correct]
        [Good: True]
        [Bad: False]
    Source: 172.16.168.1 (172.16.168.1)
    Destination: 172.16.0.81 (172.16.0.81)
    Reassembled IPv4 in frame: 1131
Data (1480 bytes)



No.     Time        Source                Destination           Protocol Length Info
   1131 404.338541  172.16.168.1          172.16.0.81           UDP      670    Source port: 4414  Destination port: 60000

Frame 1131: 670 bytes on wire (5360 bits), 670 bytes captured (5360 bits)
    Arrival Time: Nov 18, 2011 12:38:46.612362000 CST
    Epoch Time: 1321641526.612362000 seconds
    [Time delta from previous captured frame: 0.000054000 seconds]
    [Time delta from previous displayed frame: 0.000054000 seconds]
    [Time since reference or first frame: 404.338541000 seconds]
    Frame Number: 1131
    Frame Length: 670 bytes (5360 bits)
    Capture Length: 670 bytes (5360 bits)
    [Frame is marked: True]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:data]
    [Coloring Rule Name: UDP]
    [Coloring Rule String: udp]
Ethernet II, Src: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23), Dst: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
    Destination: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        Address: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        Address: 00:ff:5b:67:b9:23 (00:ff:5b:67:b9:23)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.168.1 (172.16.168.1), Dst: 172.16.0.81 (172.16.0.81)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 656
    Identification: 0x7284 (29316)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 2960
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0xc3f3 [correct]
        [Good: True]
        [Bad: False]
    Source: 172.16.168.1 (172.16.168.1)
    Destination: 172.16.0.81 (172.16.0.81)
    [3 IPv4 Fragments (3596 bytes): #1129(1480), #1130(1480), #1131(636)]
        [Frame: 1129, payload: 0-1479 (1480 bytes)]
        [Frame: 1130, payload: 1480-2959 (1480 bytes)]
        [Frame: 1131, payload: 2960-3595 (636 bytes)]
        [Fragment count: 3]
        [Reassembled IPv4 length: 3596]
User Datagram Protocol, Src Port: 4414 (4414), Dst Port: 60000 (60000)
    Source port: 4414 (4414)
    Destination port: 60000 (60000)
    Length: 3596
    Checksum: 0xe5c9 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (3588 bytes)

I diff'd these fragments every which way against each other and can't find anything special about the dropped fragment. I'll post the OpenVPN maximum verbosity logs on Monday too. All I could infer from the logs is that the fragment was put into the tunnel on the Window side, but there is no mention of it on the Linux side.

The bit pattern from message 1130 gets dropped every time I send it. Not just a random UDP fragment drop. That one in particular, without fail. What is so special about the bit pattern? Why is it dropped? I've almost exhausted everything I can think of doing. I found some debug print statements in the OpenVPN code. I'm going to recompile OpenVPN with those debug print statements enabled on Monday.

bitblit

My client config file is:

client

dev tap
dev-node TAP
proto tcp
remote zeus 1196
resolv-retry infinite
persist-key
persist-tun

ca ca.crt
cert myclient.crt
key myclient.key

ns-cert-type server

verb 6

tun-mtu-extra 32
tun-mtu 1500
script-security 2 system
comp-lzo no
cipher none

My server config is:


port 1196

proto tcp

dev tap0

ca ca.crt
cert ovpnsrv1.crt
key ovpnsrv1.key 

dh dh1024.pem

server 172.16.0.0 255.255.0.0


client-config-dir ccd
route 172.16.0.0 255.255.0.0

client-to-client

duplicate-cn

keepalive 10 120

persist-key
persist-tun

verb 6

;mute 20

tun-mtu-extra 32
tun-mtu 1500
script-security 2 system
comp-lzo no
txqueuelen 250
tcp-queue-limit 300
cipher none

I temporarily disabled compression and encryption so I could view the data inside the tunnel with Wireshark. I verified that the packet is dropped between when it goes into the TAP, and when the packets flow out the NIC. Inside the tunnel, I can see the packets before and after the dropped packet.

I also tried this with Windows XP SP3, Windows XP x64 SP2, Windows 7 x64. The same packet is dropped everytime. Any help would be greatly appreciated.

bitblit

I switched from TCP mode to UDP mode and got the same error. The same fragment was dropped. I tried this on three different PC's, and 2 different tunnel mechanisms. I was able to replicate the dropped packet by crafting the message manually and sending it out the TAP. I've done all I can do to narrow down the problem but haven't got any replies from anybody.

janjust

what makes you think packet 1130 is dropped:

[3 IPv4 Fragments (3596 bytes): #1129(1480), #1130(1480), #1131(636)]
[Frame: 1129, payload: 0-1479 (1480 bytes)]
[Frame: 1130, payload: 1480-2959 (1480 bytes)]
[Frame: 1131, payload: 2960-3595 (636 bytes)]
[Fragment count: 3]
[Reassembled IPv4 length: 3596]

seems like packet 1131 is the full 3596 byte packet ?

bitblit

Sorry. I should have been more clear. Those 6 packet decodes were all on the Windows side going into the TAP. I see all 6 of the packets coming in. I see 5 coming out on the Linux side. That packet #1130 on the Windows side is the one that didn't make it through. Bit for bit, those remaining 5 packets are correct and match the original packets exactly.

Also, Wireshark reassembles the entire datagram in the last packet. You see the entire message in the decode pane. It also lets you see the original raw undecided data, and the individual payloads that comprised the entire message. It confused me the first time I saw it too. The MTU of my TAP is 1500 bytes. 3596 wouldn't fit in a single packet anyway.

janjust

ah sorry about that, I thought the tcpdump was run on the server side...
is this dropped packet fully reproducable? it would be nice to run the server with 'verb 5' (or higher) set and then watch for the incoming packets - the server log file will list the packets and their size. Does the packet end up on the VPN server? or is it dropped somewhere earlier? Does the server (really) fail to inject the packet into the tap adapter? is there a firewall rule blocking certain types of packets (I'd run with iptables turned OFF for debugging).

bitblit

The dropped packet is very reproducible. I've done it many times with 3 different clients, 3 different versions of windows, and 2 different versions of OpenVPN. I ran it with verb 9 on both ends. Like I said, on the client side the packet is logged as being received, encrypted and inserted into the tunnel. On the receiving end, nothing is mentioned. I see log entries for the packets before and after it.

I disabled encryption and compression so I could see the packets from inside the tunnel. I used Wireshark on eth0 on my server, and Microsoft Metwork Monitor on the NIC on my client. I could see the packets both before and after the dropped packet, but that packet was dropped before it made it into the tunnel. So, it gets dropped somewhere between OpenVPN TAP and the NIC.

No firewall on either end. Iptables is off. Windows firewall is off. The only thing between us is a layer 2 switch (I kept it simple for debugging). I found instructions for how to disable the QoS service in Windows. I disabled it. Enabled it with multiple different settings. No change. I actually worked on debugging this for about 4 days.

The only thing left is to replicate the build environment, build a debug version, and step through code. This wasn't supposed to be a big task, so I have to put it down to work on other things to keep it off management radar. if I can pick it back up, are there nsfructions out there for setting up a build and debug environment for OpenVPN? I'm pretty sure this is a Windows issue.

janjust

make sure you're using openvpn 2.2.2 on Windows 7 - it could be an IPv6 related bug in the tap-win32 driver that was fixed in the tap-win32 driver included in openvpn 2.2.2.

As for build instructions, take a look here:
https://community.openvpn.net/openvpn/wiki/BuildingOnWindows

bitblit

I tried both 2.2.2 and 2.3alpha, on Windows 7, Windows XP SP3, and Windows XP x64 SP2.

Is it possible to throttle the TAP? I have a theory, but I'm not sure how to exercise it. I think that, maybe, the TAP is accepting UDP packets faster than the physical NIC can send. That would explain another issue I'm running into. To test it though I would need to make the TAP as slow or slower than the physical NIC. Is that possible?

bitblit

I should add that I don't mean throttle by message content. Not a traffic shaper. Rather, slowing down the entire virtual adapter from 1Gbps (or whatever the equivalent is) to 10Mbps. Even just adding a busy wait between receiving the user message and when it sends it off to the physical NIC. Either something in the TAP or in the OpenVPN service. I don't know how the Windows IP stack is implemented, but I assume that throttling the TAP would throttle the user application code that is sending anything to the TAP.

janjust

errr, actually , that is not possible in the tap-win32 adapter; Windows sees the tap-win32 adapter as a 10 Mbps adapter but it is actually capable of achieving higher speeds.

Which protocols are bound to the tap-win32 adapter? can you try it by unbinding everything except TCP/IP v4 ?

bitblit

IP is the only protocol that I have bound. What about the QoS service? Traffic shaping. I just read up on it. I think I can use that to reduce the thru put by IP address. I won't be able to try it for a while. Maybe next week.

bitblit

I solved my problem. Thought I would post it here. It wasn't OpenVPN at all. In fact, it was a mysterious random nonrepeatable ghost in the system. Me trying to use OpenVPN with it made the problem deterministic and easily repeatable. The host application sent messages over UDP bigger than the MTU size. I theorized that the TAP took its time chunking the message into fragments, and transmitted the fragments in rapid fire succession. The packets entered the physical NICs buffers slightly faster than the IP stack could route them. It gradually filled the queue at a deterministic rate until the queue overflowed, causing the stack to drop the UDP fragment. The deterministic nature of the host application and the TAP caused it to overflow the queue on the same packet everytime.

To test the theory, I polled the user community using this particular application and found similar failures occurred on real hardware. I even got a Wireshark recording of one. It was never properly diagnosed because it was random and rarely happened. I think this was due to the fast switches, low latency network, and non deterministic network traffic.

I convinced the developer to give me an engineering prototype with the message size lowered to below the MTU size. I tested it on real hardware and OpenVPN and everything worked perfectly.

janjust

Excellent to hear that you solved it ! And thanks for posting your solution, it could be very valuable when troubleshooting similar issues.

Closing topic.