Why BACnet Needs Layer 2: The Remote Access Problem Nobody Talks About

If you have ever tried to run a BACnet WHO-IS scan through a remote VPN connection and gotten zero results, you already know the problem this article is about. You are not misconfigured. Your credentials are fine. The tunnel is up. But BACnet discovery simply does not work — and the reason is fundamental to how BACnet/IP was designed.

This is the remote access problem that nobody in the building automation industry talks about openly: the vast majority of remote access tools operate at Layer 3, and BACnet discovery requires Layer 2. That gap is not a minor inconvenience. It breaks the primary workflow that every BAS technician depends on — the ability to discover, browse, and troubleshoot BACnet devices from a remote workstation.

How BACnet discovery actually works

Before we get into what breaks, it helps to be precise about the mechanism. BACnet/IP device discovery relies on two Application Protocol Data Units (APDUs): WHO-IS and I-AM.

When a BACnet workstation — whether it is Niagara Workbench, CAS BACnet Explorer, YABE, or any other tool — starts a device scan, it sends a WHO-IS broadcast. This is a UDP packet sent to the local subnet broadcast address (for example, 192.168.1.255) or the global broadcast address (255.255.255.255) on UDP port 47808 (0xBAC0). The WHO-IS packet may be unqualified (discover everything) or may specify a device instance range.

Every BACnet/IP device on the same broadcast domain that receives this packet responds with an I-AM packet. The I-AM contains four critical fields: the device's object identifier (device instance number), the maximum APDU length it supports, the segmentation capability, and the vendor ID. This is how your workstation populates its device tree.

The key detail: WHO-IS is a broadcast. It is not addressed to a specific IP. It is sent to every device on the subnet simultaneously. This is by design — the whole point of WHO-IS is to discover devices whose addresses you do not already know. If you already knew their IP addresses, you would not need discovery.

BACnet also uses broadcast for other essential operations. WHO-HAS discovers which device holds a specific object name. I-HAVE announces object ownership. Unconfirmed COV (Change of Value) notifications can also be broadcast. And at the network layer, BACnet uses broadcast for router discovery via Who-Is-Router-To-Network and I-Am-Router-To-Network messages.

All of these mechanisms share a single dependency: broadcast delivery across the local network segment.

Why Layer 3 VPNs break BACnet discovery

A Layer 3 VPN — the type used by virtually every commercial VPN product, from IPsec tunnels to SSL VPN appliances to modern mesh networking tools — operates at the IP routing layer. It creates a routed path between two networks. Your laptop gets an IP address on a virtual interface, and IP packets are routed between your machine and the remote network through an encrypted tunnel.

This works perfectly for unicast traffic. If you know a BACnet controller is at 192.168.1.50, you can send a unicast BACnet ReadProperty request directly to that IP, and it will be routed through the tunnel and delivered. The controller responds, the response is routed back, and your workstation displays the data.

But broadcast traffic does not route. This is not a bug in your VPN — it is a fundamental property of IP routing. RFC 922 defines the rules for IP broadcast, and a broadcast packet's scope is the local subnet. Routers do not forward broadcast packets from one subnet to another. A Layer 3 VPN creates a routed boundary between your laptop and the BACnet network, and broadcast traffic stops at that boundary.

When your workstation sends a WHO-IS to 255.255.255.255:47808, the packet goes to your local VPN interface's broadcast address. It does not cross the tunnel. Some VPN implementations will forward a directed broadcast (like 192.168.1.255) as a unicast packet to the remote gateway, but the remote gateway will not re-broadcast it onto the building network unless it has been specifically configured as a directed broadcast relay — which almost none are, because directed broadcast forwarding is a well-known amplification attack vector (RFC 2644 explicitly recommends disabling it).

The result: your VPN is up, your tunnel is healthy, you can ping the controllers by IP — but WHO-IS returns nothing. Your device tree is empty. You are blind to the BACnet network.

The workarounds (and why they all fall short)

The BAS industry has developed several workarounds for this Layer 3 broadcast problem. None of them fully solve it.

BBMD (BACnet Broadcast Management Device)

BBMD is the official BACnet solution for multi-subnet broadcast delivery, defined in ASHRAE 135 Annex J. A BBMD maintains a Broadcast Distribution Table (BDT) of peer BBMDs on other subnets. When a BBMD receives a local broadcast, it forwards it as a unicast to each registered peer, which then re-broadcasts it on its local subnet.

In theory, you could deploy a BBMD at the building site and register your remote workstation as a Foreign Device via the Foreign Device Registration (FDR) mechanism. Your workstation sends a Register-Foreign-Device request to the BBMD, which then includes you in broadcast distribution for a configured TTL (time to live, typically 60 seconds before re-registration is required).

In practice, BBMD has significant problems for remote access:

• Configuration complexity. Every BBMD needs a manually maintained BDT. Adding and removing remote technicians means touching the BBMD configuration — or relying on FDR, which has its own failure modes.
• FDR reliability. Foreign Device Registration requires the remote workstation to maintain a registration that expires every 30-60 seconds. If a re-registration packet is lost (common over cellular links), the remote device silently falls out of broadcast distribution. The technician's device tree goes stale with no error message.
• NAT traversal. BBMD was designed for enterprise LANs, not for connections traversing multiple NAT boundaries. The BBMD forwards broadcast packets to the registered IP of the foreign device. If that IP is a NAT address (which it almost always is for remote connections), packets are delivered to the NAT gateway, not the technician's workstation.
• No security controls. BBMD provides broadcast distribution, not security. Any device that can reach the BBMD can register as a foreign device. There is no authentication, no protocol restriction, no session time limit, and no audit trail.
• Single protocol scope. BBMD only solves broadcast for BACnet. If the technician also needs Modbus, Niagara, or HTTP access to controller web interfaces, BBMD provides nothing.

Static device lists (no discovery)

Some technicians give up on discovery entirely and manually add BACnet devices by IP address. Most BACnet workstation tools support this: you enter the controller's IP and device instance, and the tool communicates with it directly via unicast.

This works for reading and writing points on known devices. But it sacrifices the core value of BACnet discovery:

• You only see what you already know about. New devices, replaced controllers, or devices with changed addresses are invisible.
• Troubleshooting is crippled. Half of BACnet troubleshooting is figuring out what is on the network. If a controller is offline, it simply will not respond to a unicast — but you have no way to distinguish "offline" from "wrong IP address" or "different subnet" without broadcast discovery.
• BACnet router discovery does not work. Who-Is-Router-To-Network is broadcast-based. Without it, you cannot discover the BACnet internetwork topology — which MSTP trunks are behind which routers, which network numbers map to which segments.
• Device lists go stale. Controllers get re-addressed. New ones get added. Old ones get decommissioned. A static list is a snapshot that degrades over time.

Remote desktop into an on-site workstation

The most common workaround in practice: leave a PC on the building's BAS network running remote desktop software. The technician connects to the PC, opens their BACnet tools on that machine, and works through the remote desktop session. Since the PC is physically on the same broadcast domain as the controllers, WHO-IS works normally.

This solves the broadcast problem at the cost of everything else:

• Persistent access point. That PC is always on, always reachable. It is a permanent backdoor into the building network.
• Shared credentials. Multiple technicians from multiple integrators often share the same remote desktop login. There is no individual accountability.
• No protocol restriction. Once on the remote desktop, the technician has full network access from that machine — they can browse file shares, access other systems, and reach anything on the subnet.
• Tool limitations. The technician is limited to whatever BACnet software is installed on that specific PC. They cannot use their own licensed tools, their own templates, or their own workflow.
• Performance. Running a graphical BACnet workstation over a remote desktop session, especially over cellular or satellite connections, is painfully slow. Every mouse click, every menu open, every property read round-trips through the remote desktop protocol.

For a deeper look at how these traditional approaches compare on security, see our guide on secure BACnet remote access.

What Layer 2 remote access actually means

Layer 2 remote access solves the broadcast problem at its root. Instead of creating a routed (Layer 3) path between the technician's machine and the building network, a Layer 2 connection extends the broadcast domain across the encrypted tunnel.

From the perspective of the BACnet controllers on the building network, the technician's workstation appears to be physically connected to the same network switch. Ethernet frames — including broadcast frames — traverse the tunnel as if the two endpoints were on the same physical wire. The technician's network adapter receives an IP address from the building network (via DHCP or static assignment), and ARP, broadcast, and multicast traffic all flow normally.

Technically, this is achieved through a bridged tunnel. The encrypted tunnel carries Ethernet frames (Layer 2 PDUs) rather than IP packets (Layer 3 PDUs). At the building site, a CPE device bridges the tunnel interface with the local BACnet network interface. At the technician's side, a virtual TAP adapter is created that represents one end of the bridge.

The practical difference is immediate and obvious:

• WHO-IS works. The technician opens their BACnet tool, sends a WHO-IS broadcast, and every BACnet controller on the network responds with I-AM. The device tree populates exactly as it would if the technician were sitting in the building's mechanical room.
• WHO-HAS works. Object discovery across the network functions normally.
• Router discovery works. Who-Is-Router-To-Network and I-Am-Router-To-Network traverse the bridge. The technician sees the full BACnet internetwork topology, including MSTP trunks behind IP-to-MSTP routers.
• COV subscriptions work. Change of Value notifications, including unconfirmed broadcast COV, are delivered to the technician's workstation in real time.
• No BBMD required. Because the technician is on the same broadcast domain, there is no need for broadcast distribution infrastructure. The problem BBMD was designed to solve simply does not exist.

This also means Modbus devices on the same network segment are accessible, as are controller web interfaces (HTTP/HTTPS) and any other service on the local subnet. The technician's own workstation tools — their licensed copy of Niagara Workbench, their Tridium certificate, their custom BACnet templates — all work natively because the traffic is not being proxied through a remote desktop session. It is real, local network traffic.

Layer 2 access with protocol-level controls

There is an obvious concern with Layer 2 remote access: if the technician is on the same broadcast domain as the building network, what stops them from accessing everything on that network? This is a valid question, and it is the reason most remote access vendors avoid Layer 2 entirely — it is easier to restrict access at Layer 3 where you have IP-level ACLs.

SiteConduit solves this with a default-deny bridge filter that operates at the Layer 2 forwarding plane. Every Ethernet frame that crosses the bridge between the technician and the building network is inspected and matched against an allowlist. Frames that do not match an allowed protocol are silently dropped.

A typical BACnet session allowlist looks like this:

• ARP (EtherType 0x0806) — required for Layer 2 address resolution
• IPv4 (EtherType 0x0800), UDP, port 47808 — BACnet/IP
• IPv4, TCP, ports 80 and 443 — controller web interfaces
• IPv4, ICMP — ping and traceroute for diagnostics
• DHCP (UDP 67/68) — IP address assignment

Everything else — SMB file sharing, RDP, SSH, SQL, DNS to external resolvers, NTP, SNMP, FTP — is dropped at the bridge. The technician has Layer 2 adjacency for BACnet discovery and communication, but the attack surface is constrained to the explicitly permitted protocols.

This is fundamentally different from a Layer 3 ACL. A Layer 3 firewall can restrict IP addresses and ports, but it cannot see or filter Ethernet-level protocols (ARP, LLDP, STP) or control broadcast behavior. A bridge filter operates on every frame before it is forwarded, giving protocol-level control at the same layer where broadcast happens. You get the broadcast domain extension that BACnet needs, with default-deny security that your security team requires.

Additional controls layer on top of the protocol filter:

• Bandwidth caps — BACnet traffic is lightweight (typically under 50 Kbps for active polling). A 10 Mbps per-session cap prevents bulk data exfiltration through allowed protocols while leaving more than enough bandwidth for BAS work.
• Session time limits — sessions auto-expire after a defined window (2 to 24 hours). No standing Layer 2 access between maintenance windows.
• Per-protocol traffic accounting — every 60 seconds, the platform records how much traffic was exchanged per protocol. If a BACnet session suddenly generates heavy HTTP traffic, that is visible in real time.
• One-click termination — the building owner or security team can kill any active session immediately, severing the Layer 2 bridge in seconds.

For context on why these controls matter: persistent VPNs in building automation consistently rank as one of the top threat vectors in OT security assessments. Layer 2 access without protocol controls would make that problem worse, not better. The bridge filter is what makes Layer 2 safe for production BAS networks.

Discovering BACnet devices remotely over Layer 2

Here is what a Layer 2 BACnet remote session looks like in practice with SiteConduit.

The building site has a CPE device connected to the BACnet/IP network segment. The CPE is pre-configured and auto-provisioned — no on-site IT work required beyond plugging in an Ethernet cable and powering the unit. The CPE maintains a persistent encrypted tunnel back to the SiteConduit platform. No inbound ports are opened on the building's firewall.

Step 1: Start the session. The technician receives a session file (a .scconnect file) from the building owner or site administrator. The file is cryptographically bound to the technician's identity and the specific site — it cannot be reused, shared, or replayed.

Step 2: Connect. The technician opens the session file with the SiteConduit Connect app. The app creates a virtual TAP network adapter on the technician's machine and establishes an encrypted Layer 2 tunnel. Within seconds, the TAP adapter receives an IP address from the building network via DHCP. The technician's machine is now Layer 2 adjacent to the BACnet controllers.

Step 3: Discover. The technician opens their BACnet workstation tool — Niagara Workbench, CAS BACnet Explorer, YABE, or any tool that supports BACnet/IP. They run a WHO-IS scan. The scan goes out as a broadcast on UDP 47808, crosses the Layer 2 bridge, and reaches every BACnet controller on the building network. I-AM responses come back. The device tree populates.

Step 4: Work. The technician reads properties, writes setpoints, downloads trend data, uploads schedules, and troubleshoots alarms — using their own licensed tools, their own templates, and their normal workflow. There is no remote desktop lag. No round-trip through a screen-sharing protocol. Traffic flows at near-local-network speed through the encrypted tunnel.

Step 5: Session ends. When the time limit expires (or the technician disconnects), the Layer 2 bridge is torn down. The TAP adapter is removed. There is no residual connection, no standing access, and no credential to revoke. The session produced a complete audit record: who connected, when, which protocols were used, and how much traffic was exchanged per protocol.

From the technician's perspective, it feels like plugging into the building's network switch — except they are sitting in their office, or their truck, or their home, connecting over broadband, LTE cellular, or any internet path.

When you need Layer 2 vs. when Layer 3 is sufficient

Layer 2 remote access is not always necessary. Here is a practical guide to which scenarios require it and which do not.

You need Layer 2 when:

• BACnet device discovery is required. Any task that starts with "scan the network" or "find the controllers" requires WHO-IS broadcast — which requires Layer 2.
• Commissioning or recommissioning. During commissioning, device instance numbers, network numbers, and IP addresses may not be finalized. Discovery is the only way to find devices.
• Troubleshooting unknown issues. When the problem report is "something is wrong on the BACnet network," the technician needs full discovery to assess the network state — what devices are present, what is responding, what is missing.
• MSTP trunk diagnostics. Identifying which BACnet/MSTP devices are behind which IP-to-MSTP routers requires Who-Is-Router-To-Network and I-Am-Router-To-Network broadcasts.
• BACnet router table verification. Confirming network number assignments and router paths requires broadcast-based router discovery messages.
• COV subscription testing. Verifying that Change of Value notifications are being generated and delivered — especially unconfirmed broadcast COV — requires the technician to be on the broadcast domain.

Layer 3 is sufficient when:

• You already know every device's IP address. If you have a current, accurate device list, you can communicate with controllers via unicast BACnet over a Layer 3 connection.
• You are accessing a specific controller's web interface. HTTP/HTTPS to a known IP does not require broadcast. A Layer 3 connection to port 80/443 on the controller's IP is sufficient.
• Monitoring only. If your remote access is limited to reading points from known devices (for dashboards or alarming), unicast BACnet ReadProperty works fine over Layer 3. Learn more about secure BACnet remote access for monitoring scenarios.
• Niagara station-to-station. Niagara Fox protocol (TCP 1911) is unicast. Connecting to a known JACE or FX controller by IP works over Layer 3.

The reality for most BAS integrators: they need Layer 2 capability available when they need it, even if they do not use it for every session. The ability to fall back to full broadcast discovery is essential for troubleshooting and commissioning — the tasks where remote access provides the most value.

SiteConduit supports both modes. Layer 3 sessions provide routed access with protocol firewalling for routine monitoring and known-device maintenance. Layer 2 sessions extend the broadcast domain for discovery, commissioning, and deep troubleshooting — with the same default-deny bridge filter, bandwidth caps, time limits, and audit trail.

The gap in the market

As of early 2026, no other remote access platform purpose-built for building automation offers Layer 2 connectivity with protocol-level bridge filtering. OT remote access vendors focus on Layer 3 and application-layer proxying, which works for manufacturing and ICS environments where device addresses are known and stable. Generic VPN products provide no protocol awareness at all. Remote desktop tools sidestep the problem entirely at the cost of performance, security, and usability.

BACnet was designed around broadcast discovery. A remote access platform that does not support broadcast is a remote access platform that does not fully support BACnet. It is that simple.

If your technicians are working around the broadcast problem with BBMD hacks, static device lists, or remote desktop sessions, there is a better path. Layer 2 remote access with protocol controls gives them native BACnet behavior with the security your building network demands. Read our FAQ for more details on how SiteConduit handles BACnet, Modbus, and Niagara protocols.

SiteConduit is a managed remote access and monitoring platform purpose-built for building automation. We provide time-limited, protocol-restricted, fully audited Layer 2 and Layer 3 remote access for BAS integrators, facility managers, and security teams.

Join the waitlist at siteconduit.com for early access.