Some of the most stubborn integration problems are also the most invisible. A sensor sits in a plant room quietly broadcasting its readings. An alarm panel announces its status to the local network. A legacy controller waits for a server to answer it. All of it works perfectly — right up until the device and the software that needs to hear it end up on different networks. UDP broadcasts don't cross routers. The packet is shouted onto the local wire, the listeners on that wire hear it, and everything beyond the first router never knows it happened.
UDP Relay is Allegro IT's answer to that problem. It is a small, open-source tool that sits inside the device's network, listens for those UDP packets, and forwards them — in both directions — to an application that lives somewhere else entirely: another site, a VPN, or the cloud. It is free under the MIT license, and it is exactly the kind of unglamorous, infrastructure-level work that keeps existing equipment useful instead of forcing a rip-and-replace.
Why UDP Gets Stuck
UDP broadcast is how a great deal of hardware introduces itself to the world — sensors, alarms, PLCs, discovery protocols and telemetry streams all lean on it. It is fast, connectionless, and perfect for "shout it to whoever is listening on this network." The catch is right there in the design: a broadcast is scoped to its local segment. Routers don't forward it, so the instant your monitoring application moves to another building, a data centre, or a cloud VM, it goes deaf.
The usual ways out are expensive. Re-flash the device's firmware to speak a routable protocol — often impossible on sealed or certified equipment. Rebuild the network so everything shares one segment — rarely practical. Or replace working hardware with something cloud-native — costly and disruptive. UDP Relay takes the cheap path instead: it leaves the device exactly as it is and quietly carries its traffic across the boundary.
What UDP Relay Does
Install it on any machine that shares a network with the device. It listens for the device's broadcasts and forwards each packet to a remote endpoint you choose. When the remote server answers, the relay carries the reply back to the device — so request/response protocols keep working as if everything were on the same wire. Addresses and ports live in a plain XML file, so pointing the relay at a different server or moving it to another LAN never means recompiling.
How It Works
The relay runs two independent forwarding tasks, so traffic flows both ways — the device's outgoing broadcast and the server's reply each get their own path.
1. Listen on the LAN
The relay sits on the device's network and listens for its UDP broadcasts (or unicast packets) on the port you configure. Set the interface to 0.0.0.0 to listen on every interface.
2. Forward to the server
Each captured packet is forwarded to the remote endpoint you choose — your server on another site, behind a VPN, or in the cloud. The original payload is passed through untouched.
3. Catch the reply
The relay also listens for the server's response on its own port — the second forwarding task, running in parallel with the first.
4. Relay it back
The reply is forwarded back onto the device's network, so request/response protocols complete normally — the device never has to know the server isn't local.
Under the hood that is four endpoints — two to listen on, two to forward to — each a simple "listen here, send there" pair defined in XML. A socket timeout is configurable per host (set it to block indefinitely for always-on listening). Nothing is hard-coded, so the same binary serves every deployment.
Engineering Built for Real Deployments
A relay that only works on a developer's bench is a demo, not a tool. UDP Relay is built to be left running in the corner of a server room for months without anyone thinking about it.
Run it where it fits
Ship it as an always-on Windows Service with Event Log integration and ready-made install scripts, or run the cross-platform console on Windows, Linux or macOS. Same engine underneath, your choice of host.
Modern .NET, broad reach
The hosts target .NET 8, 9 and 10. The core engine targets .NET Standard 2.0, so it embeds in everything from classic .NET Framework apps to the latest .NET. IPv4 and IPv6 are both supported, detected per endpoint.
Built to stay up
If the remote endpoint is briefly unreachable, the relay shrugs it off and keeps running instead of silently dying — a regression-tested guarantee. Cancellable async I/O means clean, prompt shutdowns and deterministic socket cleanup.
Tested and automated
An xUnit test suite covers the engine — including a loopback round-trip and the unreachable-endpoint case — and GitHub Actions runs the whole build and test pass on every change.
Logging is pluggable through the standard Microsoft.Extensions.Logging pipeline, so the same relay can write to the console while you set it up, to a rolling log file in production, and to the Windows Event Log when it runs as a service — all without touching the core.
Open Source, Ready to Embed
UDP Relay is open source on GitHub under the MIT license — clone it, read it, run it, or fork it for your own needs. If you would rather build on the engine than run the host apps, the relay engine is published on NuGet as UDP_Relay_Core — add it to your own .NET project with a single dotnet add package UDP_Relay_Core and you are away. And if you just want to run it, every tagged release ships self-contained Windows and Linux builds that need no .NET runtime installed at all — download, edit the XML, and start it.
Where This Kind of Work Pays Off
UDP Relay exists because problems like it keep showing up in the real world:
- Sensors, alarms and IoT devices that broadcast readings on a local network while the monitoring application lives at another site or in the cloud.
- Legacy industrial and building-automation equipment that only speaks LAN-local UDP and cannot be reconfigured or replaced.
- Discovery and telemetry protocols that need to reach a central server across a segment they were never designed to leave.
This is the everyday work of connecting equipment that can't change to systems that need its data — and it is squarely what Allegro IT does. Legacy-system maintenance and modernisation, careful integration work, and keeping things that still have business value alive rather than throwing them away. UDP Relay is one small, public example of that approach.
Have a Device on the Wrong Side of the Network?
UDP Relay began as a concrete client problem and grew into a tool worth open-sourcing. If you have hardware stranded behind a router, a legacy system that needs to reach the cloud, or an integration that "just needs the packets to get through," that is precisely the kind of work we take on. Get in touch with Allegro IT to talk it through — or browse the source on GitHub.
