RUT241 BACnet BBMD over WireGuard - Who-Is not answered on LAN, RUT241 appears to add invalid Source Network (0xFFFF) when relaying

Hello,

I’m trying to scan/discover BACnet objects on a RUT241 LAN network remotely, from a central BACnet client (WAGO BACnet Configurator) connected over a WireGuard VPN, with RUT241 acting as a BACnet BBMD for the local BACnet/IP devices. I’ve done extensive packet captures on both sides of the router and would like input from anyone who has run into this, or from Teltonika.

Topology

  • RUT241, WireGuard client, VPN interface wgpv, VPN address 10.250.251.10/32

  • Central site / BACnet client: 10.250.251.3 (WAGO BACnet Configurator), registers to RUT241’s BBMD as a Foreign Device

  • RUT241 LAN: 10.50.0.0/24 (br-lan), with a BACnet/IP controller at 10.50.0.10

  • WireGuard tunnel works correctly otherwise: reachable, routed, port-forwarded to the controller’s own web UI, no packet loss observed

I reconfigured the RUT241 BACnet setup from scratch to rule out leftover configuration, and the issue reproduces identically.

Current bacnet_router configuration (UCI)

bacnet_router.general.bbmd_port='47808'
bacnet_router.general.bbmd_enabled='1'
bacnet_router.general.bbmd_interface='wgpv'
bacnet_router.general.force_gateway='0'
bacnet_router.general.enabled='1'
bacnet_router.general.allow_ra='1'
bacnet_router.1.device_type='bip'
bacnet_router.1.device='br-lan'
bacnet_router.1.port='47808'
bacnet_router.1.network='1'
bacnet_router.1.enabled='1'

Firewall (zone for wgpv)

firewall zone "wireguard": network=wgpv, input=ACCEPT, output=ACCEPT, forward=REJECT, masq=1
forwarding: wireguard -> lan
forwarding: lan -> wireguard

What works correctly

  1. Register-Foreign-Device from 10.250.251.3 → RUT241 replies with BVLC-Result, Result Code 0x0000 (Successful completion). Verified byte-for-byte in Wireshark.

  2. Who-Is-Router-To-Network / What-Is-Network-Number from 10.250.251.3 → RUT241 correctly replies with I-Am-Router-To-Network / Network-Number-Is.

  3. A global Who-Is (device instance range 0-4194303) sent by the foreign device is received by RUT241 and re-broadcast onto br-lan as expected for a BBMD (BVLC function Original-Broadcast-NPDU).

The problem

The controller at 10.50.0.10 never replies with I-Am to the Who-Is that arrives via the VPN/BBMD path. The same controller replies within ~2 ms when the identical Who-Is is sent directly on the local LAN (bypassing VPN/BBMD entirely) - confirmed with a local scanning tool on the LAN side. So the controller itself is healthy and does answer Who-Is under normal circumstances.

To find the difference, I captured the exact same request simultaneously on the WireGuard interface (as received by RUT241) and on br-lan (as sent out by RUT241 to the local network).

Request as received by RUT241 on wgpv, from 10.250.251.3 (BVLC function 0x09, Distribute-Broadcast-To-Network, carrying an Unconfirmed-REQ Who-Is with device instance range 0-4194303):

81 09 00 12 01 20 ff ff 00 ff 10 08 09 00 1b 3f ff ff

Decoded NPDU: version=1, control=0x20 (only the Destination-present bit is set; the Source-present bit is 0). DNET=0xFFFF, DLEN=0 (global broadcast), Hop Count=0xFF. No source network/address information is present in this NPDU at all.

Same logical request as rebroadcast by RUT241 onto br-lan (BVLC function 0x0B, Original-Broadcast-NPDU, as expected for a BBMD forwarding a foreign device’s broadcast):

81 0b 00 1b 01 28 ff ff 00 ff ff 06 0a fa fb 03 ba c0 ff 10 08 09 00 1b 3f ff ff

Decoded NPDU: version=1, control=0x28 - now both the Destination-present and Source-present bits are set, even though the original request had no source specifier. The added fields are: SNET=0xFFFF, SLEN=6, SADR=10.250.251.3:47808 (correctly matching the real foreign device’s BACnet/IP address), Hop Count=0xFF, followed by the unchanged Who-Is(0,4194303) APDU.

So RUT241 is adding a Source Network + Source Address block to the NPDU that was not present in the original message from the Foreign Device, and the Source Network value it uses is 0xFFFF. Per ASHRAE 135 / BACnet/IP Annex J, 0xFFFF (65535) is a reserved value that is only valid as a Destination Network identifier (meaning “broadcast to all networks”) and should never appear as a Source Network number, since a message cannot have “all networks” as its origin.

Question

Has anyone else run into local BACnet/IP devices not responding to Who-Is forwarded through a RUT241 BBMD from a registered Foreign Device? Is there a setting to control the Source Network value used when relaying Foreign Device broadcasts?

Our goal is to scan and discover BACnet objects on our RUT241 LAN network remotely, from a central BACnet client application connected over a WireGuard VPN, using RUT241 as a BACnet BBMD.

Router details:

  • Model: RUT241

  • Firmware version: RUT2M_R_00.07.23.7

Thanks in advance for any pointers.

Greetings,

Apologies for the delayed response.

My colleague informed me that he has been in contact with you via email regarding this matter and has been working to resolve the issue.

Could you please let me know if you require any further assistance, or if the issue has now been resolved?

Best Regards,
Justinas