Black Mountain TechnologiesDiscuss a project
IT for AV/Lesson 16

Remote support 11 min read

Secure Remote AV Support: Getting In Without Leaving the Door Open

Build a support path that reaches the right AV devices without exposing the whole network.

Why an AV engineer should care

Remote access is incredibly useful. It lets BMT troubleshoot a DSP, inspect switch counters or reload a control processor without flying across three states because someone claims “the TV thing is broken.”

It is also dangerous when implemented as:

We forwarded port 443 through the firewall. Here’s the public IP and the admin password.

That exposes the AV product’s management interface directly to automated scanning, password attacks and any vulnerabilities hiding in its firmware. Today we’ll build safer paths that preserve remote support without placing an AV endpoint naked on the public internet.

Learning objectives

By the end of this lesson, you should be able to:

  • Explain what port forwarding exposes.
  • Compare VPNs, jump hosts, vendor cloud services and zero-trust access.
  • Design remote access around least privilege and MFA.
  • Account for AV discovery tools that do not work across routed connections.
  • Define BMT’s minimum remote-support requirements.

1. What happens during port forwarding

An internal device might have:

  • Address: 10.20.30.40
  • HTTPS port: TCP 443

Private addresses are not normally reachable from the internet. The firewall uses NAT to translate between the internal network and its public address.

A port-forwarding rule might say:

Any connection arriving at public TCP port 8443 should be forwarded to 10.20.30.40:443.

That effectively publishes the AV device’s login page to the world.

Changing external port 443 to something unusual like 48,327 does not provide meaningful security. Internet scanners examine every port. A weird port may reduce casual noise, but it does not make the service private.

HTTPS also does not solve this problem. HTTPS encrypts the session; it does not compensate for:

  • Default credentials
  • Weak passwords
  • Unpatched firmware
  • Authentication bypass vulnerabilities
  • Obsolete TLS libraries
  • Unlimited login attempts
  • Missing MFA
  • Poor event logging

CISA recommends removing unnecessary management interfaces from internet exposure or placing a separate zero-trust policy-enforcement point in front of them. The principle applies directly to AV equipment, even though the federal directive that prompted it specifically governs federal agencies. (cisa.gov)

2. The correct question is not “Can I reach it?”

The correct question is:

Who can reach exactly which resource, after proving what, and where is that access recorded?

Good remote access should establish:

  1. Identity: Who is connecting?
  2. Authentication: How did they prove it?
  3. Authorization: What may they access?
  4. Device condition: Are they connecting from an approved, secured computer?
  5. Time: Is the access permanent or temporary?
  6. Evidence: Are login and administrative events recorded?
  7. Revocation: How quickly can access be removed?

This is the useful part of zero trust. It does not mean trusting absolutely nobody and requiring seventeen passwords to adjust a fader.

It means that being “inside the network” does not automatically earn unlimited access. NIST’s Zero Trust Architecture says trust should not be granted solely because a user or device is on the LAN; authentication and authorization occur before access to a resource is established. (csrc.nist.gov)

3. Five remote-access approaches

A. Direct port forwarding

Internet → Firewall rule → AV device

This is the weakest normal approach.

The AV product itself must withstand every internet attack, yet AV devices often have long firmware lifecycles, limited logging and no MFA.

BMT position: Do not specify or establish direct forwarding to switch, DSP, control, signage or AVoIP management interfaces.

An IP allowlist can reduce exposure when an emergency exception is unavoidable, but it is still an exception—not the preferred architecture.

B. Client VPN

Technician → VPN gateway → Client network → AV device

The VPN authenticates the technician and establishes an encrypted tunnel into the site.

Advantages:

  • AV endpoints remain private.
  • Access can use MFA.
  • The client controls authorization.
  • One gateway can protect many internal devices.

Weaknesses:

  • A poorly configured VPN may provide access to the entire corporate network.
  • A compromised technician laptop can become an entry point.
  • Some AV discovery applications do not work across routed VPN connections.
  • The VPN gateway itself becomes important security infrastructure and must be maintained.

The VPN should permit BMT access only to the required AV management subnet, ports and services—not “any to any because we were troubleshooting and got impatient.”

C. VPN plus jump host

Technician → VPN/MFA → On-site jump host → AV management VLAN

A jump host, also called a bastion host, is a controlled computer used for administration. BMT remotely operates that computer, and the computer communicates with the AV equipment locally.

This is often the most practical enterprise AV approach because software such as Dante Controller, Crestron Toolbox, Q-SYS Designer or manufacturer discovery utilities may expect local broadcast, multicast or Layer 2 behavior.

The remote technician’s laptop does not need to participate directly in those discovery protocols. The on-site jump host does.

A good jump host should have:

  • Current operating-system and application patches
  • Endpoint protection
  • MFA at the remote-access layer
  • Named user accounts
  • Limited access to the AV management network
  • Session and login logging
  • No casual web browsing or email
  • Approved AV service applications only
  • Configuration files stored in a controlled location

Do not use the front-desk computer as the permanent AV jump host. Donna clicking a coupon attachment should not become part of the signal path.

D. Vendor cloud platform

AV device or agent → Outbound encrypted connection → Vendor cloud ← Technician

Many platforms establish an outbound connection to a cloud service. Because the session originates inside the site, no inbound firewall port may be required.

This can be a good solution, but “cloud” is not automatically synonymous with “secure.”

Evaluate:

  • Does it support MFA?
  • Are accounts individual or shared?
  • Can access be divided by customer and site?
  • Are administrative actions logged?
  • Can BMT’s access be revoked without affecting the client?
  • What device data leaves the site?
  • Does the product continue operating during a cloud outage?
  • Is the cloud connection required for operation or only management?
  • What happens when the subscription expires?
  • How quickly does the vendor address vulnerabilities?

Cloud management should fail safely. A lost internet connection must not make the conference room forget how to conference.

E. Zero-trust or application-specific access

Technician → Identity and policy check → Approved resource

A zero-trust access broker can expose a particular application or management service without granting the user general network access.

For example, a technician may receive HTTPS access to:

av-monitor.customer.com

but no direct reachability to the client’s user, finance or server networks.

This is cleaner than a broad VPN when the required management functions work through normal routed applications. It may be less useful for tools needing broadcast discovery, in which case a jump host remains appropriate.

4. Why AV discovery complicates remote support

Many AV programs locate devices using:

  • Layer 2 broadcasts
  • Multicast discovery
  • mDNS
  • Vendor-specific discovery packets

Routers normally do not forward broadcasts. VPNs and zero-trust connections are commonly routed rather than bridged.

Therefore, the technician may be able to ping a processor by IP but still see an empty discovery window.

The safe solutions are usually:

  1. Connect to devices directly by known IP or DNS name.
  2. Run the manufacturer’s tool on an on-site jump host.
  3. Use an approved discovery gateway where the protocol supports one.
  4. Use the manufacturer’s management platform or directory service.

Avoid stretching Layer 2 across the internet simply to make a discovery button work. Extending a VLAN remotely creates a much larger failure and security domain for very little practical benefit.

Good documentation solves part of this problem. If BMT’s closeout package contains accurate addresses, DNS names, VLANs and credentials handling instructions, discovery becomes convenient rather than essential.

5. Commercial-AV examples

Example 1: Enterprise control and audio system

A client has:

  • Ruckus ICX switches
  • Q-SYS Cores
  • Crestron processors
  • Dante devices
  • Separate AV management and Dante VLANs

BMT receives a named VPN account protected by MFA. The firewall permits that account to reach one hardened jump host.

The jump host can reach:

  • HTTPS and SSH on the AV switches
  • Q-SYS management addresses
  • Crestron processors
  • Dante devices through its approved local interface

It cannot reach:

  • Employee computers
  • Accounting servers
  • Building access-control systems
  • The client’s general server VLAN

Dante Controller runs on the jump host because Dante discovery and clocking traffic should remain local. Remote desktop carries the screen and user input—not the Dante network itself.

Example 2: Multi-location signage and sports-bar AV

A venue group has BrightSign players, managed displays and AVoIP endpoints at several locations.

The bad design forwards a unique public port to every player and decoder. The resulting spreadsheet becomes a directory of publicly reachable equipment.

The better design uses:

  • Vendor cloud management for supported signage functions
  • A VPN or outbound remote-support appliance for local equipment
  • Per-site access permissions
  • MFA
  • Centralized logs
  • No inbound forwarding to individual AV endpoints

If BMT’s contract ends, its accounts can be removed centrally without changing the local operation of every display.

6. BMT’s remote-support baseline

Remote access should require:

  • No direct internet exposure of AV management interfaces
  • MFA for all remote users
  • Named accounts—no shared bmtadmin account
  • Least-privilege access to required VLANs, devices and ports
  • A client-approved VPN, jump host, zero-trust gateway or cloud platform
  • Logs showing successful and failed access
  • Immediate revocation for former staff and vendors
  • Defined patch responsibility for the remote-access gateway and jump host
  • Secure credential storage
  • Configuration backup before significant remote changes
  • Local AV operation independent of the remote-access service
  • Remote access documented on the network diagram and closeout package

CISA’s current exposure-reduction guidance similarly recommends removing unnecessary exposure, using jump hosts, maintaining patches, monitoring traffic and applying MFA. (cisa.gov) Remote desktop and RMM tools are legitimate but powerful. Threat actors use the same tools because they provide real administrative control. CISA recommends controlling which remote-access products are permitted, applying segmentation and recording their use. (cisa.gov)

Practical exercise

Choose one existing BMT-supported site and complete this path:

Internet → ______ → ______ → AV management VLAN → Device

Then answer:

  1. Where does authentication occur?
  2. Is MFA required?
  3. Does the technician receive the whole network or only AV resources?
  4. Where are login attempts recorded?
  5. Can the client revoke BMT without reconfiguring every AV device?
  6. Does the AV system keep operating if remote access fails?

If the completed path is merely:

Internet → Port forward → Control processor

you have found the improvement project.

Compact glossary

  • NAT: Translation between internal and external addresses.
  • Port forwarding: Maps an inbound public port to an internal service.
  • VPN: Encrypted connection into a private network.
  • MFA: Authentication using more than one factor.
  • Jump host: Controlled computer used to administer other devices.
  • Bastion host: Another name for a hardened jump host.
  • RMM: Remote Monitoring and Management software.
  • Zero trust: Resource access based on verified identity and policy, not assumed trust from network location.
  • Least privilege: Grant only the access required for the task.
  • Allowlist: Explicit list of approved users, addresses, applications or services.

Review questions

  1. Why is moving a forwarded web interface to an unusual port not real security?
  2. Why might Dante Controller work on an on-site jump host but not directly across a VPN?
  3. What is the central idea behind zero trust?

Answers

  1. Internet scanners inspect all ports, and the underlying device remains publicly reachable and attackable.
  2. Dante discovery relies heavily on local multicast and Layer 2 behavior that a routed VPN generally does not carry.
  3. Access is granted to specific resources after verifying identity and policy; being inside the LAN does not automatically make someone trusted.

Where we are headed

This lesson connects networking, identity, certificates and logging into a practical support architecture. Lesson 17 will cover AV vulnerability and firmware management: CVEs, support lifecycles, patch decisions, configuration backups and how to update equipment without turning a functioning venue into an involuntary test lab.