OpenVPN clients can't see each other: subnet or net30?
Clients reach the server but not each other. Split the fault with one ping, then choose subnet topology, client-to-client, or a bridged TAP segment.
Two unrelated faults produce the same complaint. In the first, one client cannot reach another even by tunnel address, because the addresses are not in one subnet or the server is not forwarding peer traffic. In the second, ping works and the application's device list stays empty, because discovery relies on broadcast that a layer-3 tunnel cannot carry. One ping separates them, and the fix for each is nothing like the fix for the other.
One ping splits the problem in two
From one client, ping the other client's tunnel address, not its name and not its LAN address. If that fails, forwarding or addressing is the problem and discovery is irrelevant until it is fixed. If it succeeds, forwarding already works and the remaining gap is broadcast or name resolution.
ip addr show tun0Read the client interface before anything else, because the netmask names the topology. A /24 or another subnet mask means a shared pool; a /30 with a peer address means the older point-to-point layout, where each client has exactly one neighbour, the server.
net30 versus subnet, read from the client side
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
With net30 the server hands out a small block per client, so a route to another client's tunnel address does not exist unless the server forwards it. With subnet the entire pool is one network, every client can address every other, and the server forwards between them. That is why one server configuration can look healthy while peer pings fail: nothing is broken, the clients are simply not in one network. The client sees a working link and a peer address that does not answer, which reads like a firewall but is an addressing layout.
Switching the directive is a server-side edit plus a restart, and it applies to the next connection rather than to sessions already up. Reconnect the clients before judging the change. If an appliance regenerates the configuration from a web interface, record the directive, the file and the date, and make the edit through the interface when one exists, because a rebuild will overwrite a hand edit on the next save.
client-to-client is a separate gate
Even inside one subnet the server drops packets that arrive from one client and are addressed to another unless client-to-client is set. That keyword turns the server into a forwarder for peer traffic instead of an endpoint that only accepts it. It is the second condition people miss after fixing topology.
It does not extend to broadcast. The setting forwards unicast between clients; it does not turn the tunnel into a shared segment, and no amount of it will deliver a multicast discovery query to every peer.
TUN versus TAP, and what each can carry
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
Bridging a tap device into the LAN puts remote clients in the office broadcast domain, which solves discovery completely. The price is the platforms that do not implement TAP, a bridge that has to exist on the server, and a failure domain where a broadcast storm on the office wire reaches every remote laptop.
For two or three workstations that need name resolution, a hosts entry or a unicast address is far cheaper than a bridge. Reach for TAP when a protocol you cannot replace depends on layer-2 discovery, and not before.
Same-subnet clients without a bridge
Assigning an address from the LAN range does not put the client on the wire. The server routes between tunnel and Ethernet, so ARP for that address stops at the server's interface and the rest of the LAN never learns where it lives.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP closes that gap by having the server answer on the client's behalf. For a range, parpd manages the entries as clients come and go, while the sysctl net.ipv4.conf.eth0.proxy_arp=1 answers for everything routed elsewhere, which is broad enough to create its own surprises on a busy segment.
Whichever route you take, drop NAT between the tunnel and the wire. A MASQUERADE rule conceals exactly the addressing question you are trying to answer. It also leaves the next person with a topology they cannot reason about from the client side.
Before changing anything, capture one attempt on the server with tcpdump -ni tun0 and confirm whether the peer packet arrives at all. Arriving and being dropped points at client-to-client; never arriving points at topology or routing. The OpenVPN 2.6 manual documents both keywords and the topology default, which is worth checking against your version before copying a line from a forum post.
- The tun interface shows a pool mask rather than a /30 peer pair.
- A direct ping to the other tunnel address succeeds before you test discovery.
- The server config includes
client-to-clientwhenever peers must exchange packets. - Name the discovery protocol you are testing instead of saying the app fails.
- Use TAP only if every client platform in the group supports it.
- Keep NAT out of the path between tunnel and LAN when same-subnet reachability matters.