A data diode forwards data transparently – but only in one direction. Protocols that expect a handshake or an acknowledgement cannot complete across it. That is not a limitation to work around; it is the guarantee being enforced. The useful question is which protocols already work without a return path, and what to do about the ones that do not.
Why TCP cannot cross
TCP establishes a connection with a three-way handshake, and every segment it sends must be acknowledged by the receiver. Both require traffic flowing back. Across a true diode there is no component on the far side capable of transmitting, so the sender waits for acknowledgements that can never arrive, retransmits, and eventually gives up.
This trips people up because a diode looks like a network device. It has ports, it passes packets, and a quick test with a file copy fails in a way that suggests a fault. Nothing is broken – TCP is doing exactly what it is specified to do, against a link that is deliberately incapable of satisfying it.
Everything built on TCP inherits the problem: HTTP, SMB, FTP’s control channel, database connections, most APIs.
Protocols that cross natively
UDP, in all its forms – unicast, broadcast, multicast and manycast. UDP is connectionless by design: the sender transmits and does not expect a reply. Video streams, sensor telemetry and file transfer wrappers built on UDP pass straight through.
Syslog is natively UDP and is the classic diode deployment. Security and system logs leave the protected network for a monitoring centre while the log sources stay unreachable from it. The security property is worth spelling out: an attacker who compromises the monitoring side cannot use it as a route back into the systems being monitored, because there is no route. The evidence chain stays intact for the same reason.
Isolated networks still need accurate time – for certificate validation, for log correlation, for coordinated processes. Broadcast NTP distributes it without opening a return path. Note the broadcast qualifier: the usual client-server NTP mode is a request-response exchange and will not work.
A trap is a one-way push: equipment reports a state change outward without being asked. Polling – the other half of SNMP – is request-response and does not cross. Design monitoring around traps, not polls, on the protected side.
Handling everything else
For flows that genuinely need TCP semantics there are two honest approaches.
A proxy application terminates the protocol on the sending side, moves the payload across the diode as a one-way stream, and reconstructs it on the receiving side. The application at each end believes it had a normal conversation; the wire never carried one. This is what Data Diode Middleware (DDMW) does for files and directories. Because the far side reconstructs from a stream with no way to request a retransmission, middleware adds forward error correction and integrity checking – ask how a given implementation handles a corrupted or incomplete transfer, because it is the interesting failure mode.
Two physically independent one-way paths, each hardware-enforced, together supporting request and response. This is not a relaxed diode; it is two diodes pointing opposite ways, and each direction can be assessed on its own. Bidirectional data diodes covers when this is appropriate and when it quietly undoes the point of the exercise.
Planning the flows first
Most difficult diode projects are difficult because the flows were never written down. Before specifying hardware, list every flow that must cross the boundary and, for each one, three things: which direction, which protocol, and what happens if a message is lost.
That last question matters more than it looks. A diode gives no back-pressure – the receiver cannot ask the sender to slow down – so a sender that bursts above the link rate simply loses data. Size the link for the peak, not the average, and decide in advance whether loss is tolerable for each flow. For telemetry it usually is. For a file transfer it is not, which is exactly why middleware exists.
If the resulting list is all logs, telemetry, time and streaming, a standard data diode covers it natively. If it contains file shares or APIs, add middleware or a bidirectional pair. Either way the guarantee stays physical, which is the whole reason for choosing this approach over a firewall.
