LAN Messenger Not Seeing Users on Other Subnets: Fix
The problem: discovery is broadcast, and broadcasts don’t route
Almost every LAN messenger finds its users the same way. On startup, the client sends a UDP packet to the subnet’s broadcast address saying “I’m here, who else is?” Every other client on that broadcast domain replies, and the user list populates. No server, no directory, no configuration.
This design is why LAN messengers install in five minutes on a flat network — and why they collapse the moment you segment.
A router will not forward a limited broadcast (255.255.255.255). That is not a bug or a vendor limitation; it is the defining behaviour of a Layer 3 boundary. Directed broadcasts to a specific subnet (192.168.20.255) can be forwarded, but have been disabled by default on Cisco equipment since IOS 12.0 because of the Smurf amplification attack, and most other vendors follow suit.
VLANs make this worse in a way that catches people out: two hosts can share an IP subnet and still be unable to see each other if they sit in different VLANs. VLANs are separate broadcast domains at Layer 2. An ARP request or a discovery broadcast in VLAN 10 never reaches VLAN 20, no matter what the subnet mask says.
So the symptom set is predictable. Users see only colleagues on their own floor. The user list is half-populated and different on every machine. Ping works fine between the two hosts, which makes the whole thing look like an application bug. It isn’t.
Five myths that send you down the wrong path
Myth 1: “Ping works, so the network is fine.” Ping is unicast. Discovery is broadcast. A successful ping proves routing exists — it proves nothing about whether the discovery packet was delivered. This is the single most common diagnostic dead end.
Myth 2: “Same subnet mask means same broadcast domain.” Only on a flat Layer 2 network. Once VLANs are in play, the broadcast domain is defined by the VLAN, not the mask.
Myth 3: “Opening the messenger’s port on the firewall will fix it.” Opening ports permits traffic that arrives. It does not make a router forward a broadcast that it is dropping by design. Port rules are necessary but not sufficient — you will need them and a discovery mechanism.
Myth 4: “Enabling ip directed-broadcast is a harmless fix.”
It is effective and it is a real security decision. An interface that forwards directed broadcasts can be used as a traffic amplifier. If you enable it, scope it with an ACL that permits only the messenger’s UDP port from your internal ranges, and document why.
Myth 5: “Any LAN messenger can be made to work across VLANs.” Many free ones cannot. Several popular open-source clients hardcode the broadcast address or expose it only through a config file that must be edited on every machine by hand. Before you spend a day on router configuration, confirm your client actually supports a list of remote broadcast targets.
The diagnostic ladder
Run this before changing anything. Temporarily disable the firewall on both test machines — for a few minutes only — and ping in both directions.
| Ping result | What it means | What to do |
|---|---|---|
| Both directions succeed | Hosts are on different subnets, routing is healthy | Add the remote subnet’s broadcast address to the client’s broadcast list |
| Only one direction succeeds | There is a NAT-enabled router between the subnets | Application-layer fixes will not work; change the network design or use a server-based tool |
| Both directions fail | No route at all, or a physical/VLAN misconfiguration | Network problem — fix routing before touching the messenger |
| Works with firewall off, fails with it on | Endpoint firewall is blocking the messenger’s ports | Push an inbound TCP/UDP allow rule via GPO |
That four-way split resolves the large majority of cases and, critically, tells you whose problem it is before you open a support ticket.
Comparing the available fixes
| Fix | Effort | Security exposure | Survives DHCP/re-IP | Works through NAT | Best for |
|---|---|---|---|---|---|
| Add remote broadcast addresses in the client | Low — one setting, deployable by GPO/registry | None | Yes, subnets rarely change | No | 2–10 known subnets |
ip helper-address on the router |
Medium | Low if scoped to the specific UDP port | Yes | No | Environments where you control the router |
ip directed-broadcast + ACL |
Medium | Moderate — must be scoped carefully | Yes | No | Cisco estates with an existing ACL discipline |
| Static unicast peer list | High — a list per client | None | No, breaks on re-IP | Sometimes | Very small, static deployments |
| L2 VPN / bridged tunnel | High | Depends on tunnel config | Yes | Yes | Remote sites |
| Server-based messenger | High — new server to build and patch | New attack surface to manage | Yes | Yes | 300+ users, many sites, or NAT in the path |
The first row deserves emphasis because it is the fix most people never find. A well-designed LAN messenger lets you add other subnets’ broadcast addresses to the client’s configuration. The client then sends its discovery packet to each listed address as a normal routed unicast-to-broadcast, and clients on the far side answer. No router changes, no directed-broadcast risk, no server.
Softros LAN Messenger implements exactly this through a Broadcasts list on the Network tab of its settings, alongside documented ports (TCP/UDP 19771 and 19880) you can pre-authorise in Windows Firewall. Deploy the setting once through your image or GPO and cross-subnet discovery becomes a solved problem rather than an ongoing one.
The one case nothing solves at the application layer is NAT between internal subnets. If discovery only travels one way because addresses are being translated, no client-side setting fixes it. Either remove the NAT or accept a server-based architecture where every client dials out to a known address.
From practice: a three-VLAN clinic
An outpatient clinic across two floors segmented its flat network into three VLANs — clinical workstations, administration, and a guest network — to satisfy an internal security review. Their messenger, previously working perfectly, fragmented overnight.
Reception could see reception. Nurses could see nurses. Nobody could see anyone on another floor, and because ping worked, the initial ticket was logged against the software vendor.
The diagnostic ladder resolved it in twenty minutes: both directions pinged successfully, which pointed straight at broadcast propagation rather than routing or firewalling. The fix was two entries in each client’s broadcast list, pushed with the existing GPO that deployed the application.
Two decisions turned out to matter more than the fix itself:
- The guest VLAN was deliberately left out. Discovery was not extended to it. Segmentation was the point of the exercise; a messaging tool should respect it, not quietly undo it.
- The broadcast list was baked into the deployment package. New machines get it at imaging time, so the problem cannot recur when the clinic adds workstations.
Total change window: under an hour, with no router configuration and no exception to the security review that started the whole thing.
FAQ
Why does ping work but the messenger doesn’t? Ping is unicast and routes normally. Discovery uses UDP broadcast, which routers drop by design. The two tell you completely different things.
Can devices on the same subnet but different VLANs talk to each other? Not without Layer 3 routing between them. VLANs are separate broadcast domains regardless of IP addressing.
Is ip helper-address or ip directed-broadcast the safer choice?
ip helper-address is generally preferred because you can forward only the specific UDP ports you need. Directed broadcast forwards a broader class of traffic and requires an ACL to be safe.
What ports does a LAN messenger need open? It varies by product. Softros uses TCP and UDP 19771 and 19880 (plus its terminal services component if installed). Check your vendor’s documentation and push the rules via Group Policy rather than machine by machine.
Will this work over a site-to-site VPN? If the VPN routes between the subnets without NAT, yes — add the remote broadcast address as you would for a local subnet. If the tunnel translates addresses, it won’t.
How many subnets can I add before it becomes unmanageable? Practically, up to about ten. Beyond that, the discovery traffic and the configuration burden both start to argue for a server-based product with a central directory.
Do I have to change anything on the router at all? Often no. If your client supports a broadcast address list and there is no NAT in the path, the entire fix lives in the application configuration.
Posted in How to