bitblit
I'm using OpenVPN to bridge non routable IP packets from a linux server to a Windows PC. I confirmed it appeared to work, but found there is one specific UDP fragment that doesn't make it through. With Wireshark, I can see three fragments go into the Windows TAP, but only two appear on the Linux side. I turned on level 9 logging verbosity and confirmed there is no evidence the Linux side received such packet. I'm still looking at the Windows log.
The application detects a dropped packet and signals a retry. The client sends the three packets again, and the the same two make it through. It retried several times but consistently drops that one UDP fragment.
Why would OpenVPN drop a UDP fragment?
bitblit
I used npg to craft a specific packet and verify that OpenVPN is dropping it. I found that if all of the below are true, OpenVPN will log the packet as being encrypted and transmitted on one end, but it will not appear on the other end:
1. IP Version 4
2. Header length 20
3. Protocol is UDP
4. Byte 4 of the payload is 0x43
5. Payload is more than 247 bytes in size
Any help here would be much appreciated. I'm at a stand still until I fix this.
Mimiko
Search from where the packet comes and find if there is not set "don't fragment" flag.
bitblit
The flags are set correctly. I can see a couple hundred other fragmented UDP packets getting through successfully. The one fragment that doesn't get through is fragment #2 of 3. I see fragment #1 and #3. Of those 5 criteria I listed earlier, if I set the payload size to 247 or byte 4 to 0x42, the fragment gets through just fine. If I set the size back to 248 and byte 4 back to 0x43, it gets dropped. I verified this with Wireshark on both ends. I checked the OpenVPN logs on the receiving end, and do not see any mention of the dropped packet. On the sending side, it appears the packet got into the tunnel just fine.
Somebody suggested maybe a switch along the way was dropping it, but I find that highly unlikely since the VPN tunnel is encrypted. I don't see how a specific bit pattern in the plain text would cause the cypher text to have some magical bit pattern to cause a switch to drop it. Though at this point, I'm open to anything.
I've since connected the two PC's directly together via real NICs and a switch rather than the VPN, and no packets are dropped. Only when I use TAPs on both ends and a VPN between does it drop. I've done all I can do to rule out the TAPs. Maybe Wireshark can see a packet on the TAP, but the TAP drops it before it gets to the VPN. Not much I can do to verify that though.
I could even post the npg file that generates the two packets here. Both packets look identical except for byte 4.
bitblit
Bump.
I'm trying to get this to work again. I recompiled the newest version from source on the server and tried it again. Same packet fragment was dropped. I'm going to dig into it again today. If I remember correctly from the last attempt, I transmitted just that one single packet, and the second fragment was dropped. I changed those 5 things and resent just that one single packet and all 3 fragments went through, so I don't see how it could be congestion. That's the only packet I sent. Thousands of other fragmented packets went through successfully in other tests. It always drops that one fragment.
This is really hard to debug since I have very little debug log data. The client logs the packet fragment going in. The server logs receipt of the fragments before and after it. On either side, no mention of an error or dropped packets.
