I need to access a physical serial port on one machine from another computer over my LAN as if it were local. It’s for monitoring and controlling an older device that only has RS-232, but my main workstation is in a different room. What hardware or software solutions should I use, and how do I set them up securely?
You’ve basically got three ways to turn “old RS‑232 gizmo in the corner” into “feels like a local COM port over the LAN.”
1. Software-only solution on the machine that has the real serial port
If one PC has the physical COM port and you just want to share it over the network, use a virtual COM port / TCP redirector:
- Install something like Serial to Ethernet Connector on the machine with the actual RS‑232 port.
- It creates a server that exposes that COM port over TCP or UDP.
- On your main workstation, the same tool (or another virtual COM port client) creates a virtual COM port that forwards everything over the network to that server.
- From your app’s point of view, it is just talking to COM3 or whatever, but all the traffic is going over Ethernet.
That kind of setup is basically what people mean by a serial over IP connection for legacy hardware in a modern LAN. If you want a step by step and feature overview, check out something like
using serial communication over Ethernet on your network
which explains how to map remote serial ports to virtual COM ports and support things like multiple clients, encryption, etc.
Pros:
- No extra hardware if you already have a serial port.
- Lets you keep the old device exactly where it is.
Cons: - Needs that “server” PC to stay on.
- Network hiccups can look like flaky serial behavior if your app is picky.
2. Dedicated hardware: Serial device server
If you don’t want a full PC next to the device:
- Get a serial device server or RS‑232 to Ethernet adapter.
- Typical brands: Lantronix, Digi, Moxa, USR, cheap no‑name boxes on Amazon if you like living dangerously.
- They expose the serial port as:
- A raw TCP socket (you connect with a terminal or a redirector), or
- A virtual COM port via vendor software on your workstation.
Pros:
- Small, low power, usually more reliable than a random old PC.
- Some support multiple serial ports.
Cons: - Cost. Good ones are not super cheap.
- Vendor software can be clunky.
3. DIY with a small SBC
If you’re into tinkering:
- Use a Raspberry Pi or similar with a USB to RS‑232 adapter or a proper HAT.
- Run
ser2netorsocatto bridge the TTY to TCP. - On your Windows machine, use a virtual COM port driver to connect to that TCP endpoint.
This is basically the open source flavor of what Serial to Ethernet Connector does but with more manual config.
For your specific “monitor and control an older RS‑232 device from a different room” scenario and wanting it to look like a local port, software like Serial to Ethernet Connector is the most straightforward if you already have a box next to the hardware. For maximum plug and forget reliability, grab a dedicated RS‑232 to Ethernet device server and use its virtual COM port driver on your main workstation.
3 Likes
You’ve already got solid options from @sternenwanderer, so I’ll just fill in some gaps and push back on a couple of points.
If your main requirement is “behave like a local COM port” instead of “I’m okay with some weird network-y behavior,” you really want to think about:
- How picky the legacy device / software is
- How your network behaves under load
- How much pain you’re willing to tolerate when it randomly drops
1. Latency and timing issues people forget about
Everyone loves to say “just tunnel it over TCP, problem solved.” Not always.
Some older RS-232 devices and especially old DOS/Windows apps:
- Expect very predictable timing for responses
- Rely on RTS/CTS or DTR/DSR in very specific sequences
- Hate any kind of jitter, buffering, or delayed flushes
Software redirectors and cheap serial device servers can mess this up. Stuff like:
- Aggressive TCP buffering or Nagle’s algorithm
- Power saving on the NIC
- Wi-Fi in the path instead of wired
If your gear is timing sensitive, seriously consider:
- Wired Ethernet only between both sides
- Disable Nagle on the TCP side if the tool lets you
- For very strict stuff, a better quality serial device server or a proper tool like Serial to Ethernet Connector that handles signaling and virtual COM behavior properly
2. When software sharing is actually a bad idea
@sternenwanderer is right that software on the PC with the serial port is easy, but I’d disagree that it is always “most straightforward.”
It becomes a pain when:
- That “server” machine has random Windows updates and reboots
- Someone logs out, the redirector service stops, and your remote COM vanishes
- The machine is a shared desktop and people unplug stuff “just to test something”
If this thing is supposed to run 24/7 or control something non-trivial, a full OS with updates, users, AV popups, etc, is more like a liability.
In those cases, I’d rank options like this:
- Dedicated hardware serial device server (Lantronix, Moxa, etc)
- Small Linux SBC with ser2net
- Windows box + software redirector
Most people flip that list. I’ve been bitten enough times to put the dedicated box at the top when reliability matters.
3. Making it “feel” truly local on Windows
If you are on Windows and your app absolutely insists on a COM port (no TCP support, no config flexibility), you need a virtual COM port driver that does this well:
- Creates a COM port with a stable name
- Restores it at boot
- Handles disconnects cleanly instead of BSOD or hanging the app
- Properly fakes control lines and timeouts
That’s where something like Serial to Ethernet Connector is worth it. It does more than just “pipe bytes over TCP.” It gives you a local COM interface that behaves like real hardware as far as the OS and most apps are concerned.
They also have a download page that explains the feature set and usage in more user friendly form. Worth a look here:
turn any networked PC into a powerful serial-over-IP bridge
Compared to some vendor drivers from cheap hardware boxes, having a more robust virtual COM solution can save you a ton of debugging when the line drops or the remote end reboots.
4. Security and access control, which almost nobody mentions
You’re basically putting a hardware control interface on your LAN. Some stuff to think about:
- Use authentication and encryption where possible
- Put the serial server on a separate VLAN or at least a tight firewall segment
- If multiple users might connect, decide if you want single client exclusive access or multiple readers
Tools like Serial to Ethernet Connector and decent device servers let you:
- Restrict client IPs
- Require a password
- Control whether more than one client can open the port
For gear that controls motors, valves, test rigs, etc, that’s not optional.
5. When a full “serial over Ethernet” setup is overkill
Worth asking yourself:
- Is this just for occasional monitoring / config, not continuous operation?
- Does the device have a front panel and you only need remote access rarely?
If yes, sometimes the simpler and saner solution is:
- Put a small PC / thin client right next to the device
- Use RDP / VNC to that machine
- Let that machine talk to the serial port locally
You lose the “remote COM on your main workstation” magic, but avoid all the quirky edge cases of virtual COM over TCP. For some flaky old control software, this is actually the most stable setup.
6. TL;DR suggestion based on your scenario
You have:
- One old RS-232 device
- Main workstation in a different room
- Need it to look like a local COM port
I’d pick one of these paths:
-
If you already have a machine by the device and do not trust that hardware for 24/7:
- Install Serial to Ethernet Connector on that box
- Expose its physical COM over TCP
- Install the same tool on your main workstation and create a virtual COM that maps to that TCP endpoint
-
If you want something you set once and never touch again:
- Get a mid-range serial device server from a reputable brand
- Use their virtual COM driver or pair it with decent virtual COM software if their driver sucks
Avoid Wi-Fi in between if you want it to feel really local, and test your specific app for how it behaves when the link is briefly interrupted. That part usually decides which method survives in the long run.
The missing angle here is less “how” and more “how to keep future you from cursing present you.”
Both @nachtdromer and @sternenwanderer covered the big three (software redirector, hardware device server, SBC). I’ll focus on tradeoffs and where each breaks in real life, especially for your “feels like a local COM port” requirement.
1. Serial to Ethernet Connector specifically
If you want a virtual COM that behaves properly on Windows, Serial to Ethernet Connector is a solid choice, but it is not magic.
Pros:
- Good at exposing a remote serial port as a true virtual COM.
- Handles control lines and signals better than a lot of cheap vendor drivers.
- Flexible: client/server, multiple connections, encryption, useful logging.
- Easy to get going if you already have a Windows box with the real RS‑232 next to the device.
Cons:
- Paid software; for a single hobby setup it can feel pricey.
- You now depend on a full Windows install plus this service always running.
- Still subject to network glitches; if your LAN is noisy, your old app may misbehave.
- Extra complexity if you want redundant paths or failover.
Where it shines:
A controlled environment where that “server” PC is stable, on wired Ethernet, and you care more about compatibility with cranky Windows software than about reducing moving parts.
Where I’d skip it:
Industrial or long‑running setups where unattended reliability beats flexibility. In that case a hardware device server or a lean SBC with ser2net has less that can suddenly change under you.
2. When a device server actually wins
I disagree slightly with the idea that software on the existing PC is automatically “most straightforward.” It’s straightforward to install, but not necessarily straightforward to live with for years.
A mid‑range box from Moxa, Lantronix, Digi, etc.:
- Runs a tiny, predictable firmware.
- Has fewer “surprises” than Windows updates plus drivers.
- Often supports both raw TCP and a vendor virtual COM driver, so you can still get that local‑port illusion.
Typical failure modes with these are power or cabling, which are easier to diagnose than “random redirector service died after Patch Tuesday.”
3. Consider the “remote desktop” hack
One trick neither answer leaned on hard:
Instead of pushing the serial port over IP, push the desktop over IP:
- Put a small PC / thin client right next to the RS‑232 device.
- Plug the device into its physical COM port or USB‑RS232.
- Run your legacy software there.
- Use RDP/VNC from your main workstation.
Pros:
- To the serial device and app, everything is truly local.
- No virtual COM weirdness, no timing surprises.
- Any odd driver or timing hack the original software expects just works.
Cons:
- You are not exposing a COM port to your main machine, you are remoting into another desktop.
- Slightly annoying if you wanted to integrate with local scripts or tools on the main workstation.
If the original program is touchy, this is often the least painful option long term.
4. Timing & control lines: wired vs Wi‑Fi
This part is easy to underestimate and both earlier posts only brushed over it:
- Avoid Wi‑Fi in the path if at all possible.
- Some legacy RS‑232 gear cares about RTS/CTS or DTR/DSR transitions within tight margins.
- TCP jitter plus Wi‑Fi plus power saving NICs is how you get ghost bugs that appear “random.”
If you use Serial to Ethernet Connector or a hardware server, run it over wired Ethernet and, if your tool allows, tweak buffering / disable Nagle on the serial TCP side.
5. Multi‑user & security angle
If multiple people might connect or if the device controls anything that moves:
- Ensure only one client can have write access at a time, or at least be aware if the tool allows multiple writers.
- Use authentication and, if available, TLS for the serial tunnel.
- Put this on a segmented part of the LAN rather than your flat office network.
Serial to Ethernet Connector does decently here with authentication and access control. Hardware servers vary a lot; some have surprisingly crude security.
6. How I’d choose in your place
Given your scenario (old RS‑232, workstation in another room, want it to feel local):
-
If you already have a stable PC by the device, wired network, and Windows:
- Try Serial to Ethernet Connector to share the physical COM.
- Use a virtual COM on your main workstation.
- Monitor how your legacy app behaves under brief network outages before trusting it for anything critical.
-
If this is going to run for months or years unattended:
- Prefer a dedicated RS‑232 to Ethernet device server.
- Only add virtual COM software on your workstation if the vendor driver is bad.
-
If the legacy software is very fragile or weird:
- Host it on a small machine next to the device.
- Remote in with RDP instead of exporting the serial port across the network.
@nachtdromer and @sternenwanderer both pointed you to the right building blocks. The real decision is what you value more: fewer moving parts and long‑term stability, or flexibility and easy configuration.