When reading packets or network data from a tunnel interface, the order in which they are read does matter as they can impact connectionless protocols and also cause stateful protocols to spend time re-ordering data! There were three techniques that I tried implementing to solve this issue:

• Map a packet address to a thread index during the entire time of every connection state
• Index and order every packet read by number and wait to write them out in the same sequence
• Lock and time and order each threaded process just like many pistons firing inside of an engine block

One other observation I noticed is speed tests may seem lower which I believe is because of all the extra inner header data being prepended to the buffers in addition to the outer IPv4 + TCP headers:

• MITM: Encryption header/trailer
• MTUN: Encryption header/trailer + Inner IPv4 header + Inner protocol header
• GTUN: Encryption header/trailer + Inner IPv4 header + Inner protocol header + Batch read header

Added note: Making a VPN-style MITM Proxy service which handles thousands of network states and file descriptors is all about connection management and thread management!

Final note: Building these solutions on top of TCP allows for larger payloads, ordered delivery, auto keepalives, and connection management – full size MTU!

~

MTUN: github.com/stoops/vpn

MITM: github.com/stoops/mitm

~