Wake an AV PC Across VLANs Without Public Port Forwarding

For Wake-on-LAN across VLANs, first prove that the target wakes from the required state on its own local segment. Then use an authenticated management path to a local relay, or a network owner approved directed broadcast design with tight restrictions. Do not expose a UDP wake port to the public Internet or assume that a normal routed unicast packet will always reach a sleeping PC.

Prove the target before the route

Use the same power state and wired adapter planned for daily operation. Record a successful local wake, the target's MAC address and time until the control application is ready. Microsoft's WOL behavior guidance shows why state and platform behavior matter; a routing change cannot make an unsupported shutdown state wake.

Once that baseline exists, draw the path from remote sender to gateway, target VLAN and sleeping adapter. Note where a packet can actually be observed. Capturing a datagram on the sender only proves transmission at that point.

Choose a delivery architecture

RFC 2644 explains why routers disable directed broadcast forwarding by default. If the venue approves an exception, document the exact ingress source, target subnet, destination port and rate controls supported by the platform. An unrestricted helper forwarding every broadcast is not an equivalent design.

Test after the easy case stops helping

A unicast wake can appear reliable immediately after shutdown because network equipment still knows the target's link layer address. Test after the relevant neighbor state has expired, as well as after a switch or router restart where permitted. Do not keep a PC artificially reachable during the test and call that proof of overnight wake.

• Place the target in its qualified power state.

• Wait for the intended long idle condition or use a controlled network owner approved state test.

• Trigger the authorized relay or remote management action.

• Observe the packet at the target VLAN if equipment permits.

• Record wake and application readiness separately.

• Repeat from an unauthorized source and confirm the action is denied.

If the packet reaches the target segment but the PC does not wake, return to power state and hardware checks. If no packet reaches the segment, inspect the relay, routing and policy without changing the PC's BIOS randomly.

Protect the wake path

A wake packet is not user authentication. Put authorization on the management interface that triggers it, using the venue's approved access service and named support accounts. Restrict the relay's command to known targets and preserve a log of who requested the action. Test what happens when the relay restarts or loses its own network connection.

For an exhibition, local operators should have a documented fallback that does not require opening the rack to the public. This might be a supervised physical start procedure or a supported management feature; choose it with the venue rather than assuming hardware support.

Accept the design when overnight and recovery tests reach the defined ready state, unauthorized senders cannot invoke the management action, and the relay dependency is included in handover. Read the general WOL guide for local diagnosis and power state testing for the target qualification matrix.