NetBIOS over a VPN: name, datagram and session are separate
The slogan about routers is too broad. Check which of the three services your application uses, and whether it resolves names by broadcast or a server.
"NetBIOS does not cross routers" is repeated as if it settled the design. It does not. A broadcast name lookup usually stays inside its broadcast domain, but NetBIOS services can also use directed IP traffic that routes perfectly well. The useful question is not whether NetBIOS crosses routers; it is which of its three services your application is using.
A software interface, not one wire protocol
RFC 1001 describes NetBIOS as an interface that applications program against, with several transports underneath. Its TCP/UDP model separates name service, datagram distribution, and session service, and it explicitly supports operation with or without IP broadcast.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
That table is why the slogan fails. A session service between two named hosts is an IP conversation; a broadcast datagram is not. One VPN design can satisfy the first and not the second, and a test that proves the first says nothing about the second.
Node types decide what the client asks for
RFC 1001's broadcast, point-to-point, and mixed node models describe how a host resolves names: by asking the local network, by asking a name server directly, or by trying one and then the other. The model affects what traffic must be permitted, not whether the application works at all.
A managed name-server arrangement gives clients a point-to-point path, but only for clients configured to use it. Putting a server somewhere on the network does not make an application consult it, and a client left in broadcast mode will keep asking the local segment and timing out. The server's address has to reach the client's configuration, through whatever management path that client honours.
So record three observations for the application in question: how it turns the server name into an address, whether discovery or messaging uses broadcast or a directed endpoint, and what address and transport the actual session uses. Those are independent facts, and each has its own fix. A single successful name resolution is evidence about the first only.
NetBIOS over TCP/IP is not NetBEUI
The two get conflated because both are called legacy. NetBIOS over TCP/IP carries its services inside IP packets, which a routed tunnel already transports. NetBEUI is a non-routable layer-2 protocol, and an IP tunnel does not carry arbitrary Ethernet frames just because it carries IP.
Adding an IP route cannot convert a non-IP frame into an IP application. If an application genuinely depends on layer-2 behaviour, the options are an explicitly bounded layer-2 service or replacing the application; there is no routing change that substitutes for either.
Choose the smallest change that satisfies the task
A current SMB share reached by an approved DNS name and an explicit UNC path does not need an Ethernet extension. The file-service task and the browsing experience are different requirements, and only the second depends on the neighbour list. Reaching the share by name solves the task without stretching the broadcast domain across a tunnel.
Browsing is the part that usually fails, and it fails quietly. A machine can open a share by path while the nearby-computer list stays empty, because the list is populated by broadcast discovery and the path uses DNS. Deciding that you need the list is a different requirement from deciding that you need the file. Write down which one the user actually asked for before you design anything.
When a legacy application truly requires broadcast or non-IP frames, assess a bounded layer-2 service with a named owner, or replace the application. A bridge expands the shared failure domain and the policy boundary, which is an architectural decision rather than a checkbox labelled NetBIOS. Document the specific operations the tunnel must carry, and an administrator can evaluate the request instead of guessing at "all Windows networking".