Why Your Yacht's WiFi Keeps Dropping: Common VLAN Mistakes
The WiFi Problem Nobody Sees Coming
We get called to more yacht WiFi issues than any other single problem. The symptom is always the same — intermittent disconnections, slow speeds, devices that can't find each other — but the root cause is almost always in the network architecture, not the access points. Most of these problems come down to VLAN misconfiguration, and they're completely preventable.
Mistake 1: Running a Flat Network
The most common mistake we see is a yacht with every device — crew phones, guest tablets, AV processors, Crestron touch panels, IP cameras, and Starlink — all on a single VLAN. This creates broadcast storms as the device count grows, causes ARP table overflows on consumer-grade switches, and means a guest downloading a 4K movie can starve the Crestron control system of bandwidth. The fix: minimum three VLANs — crew, guest, and AV/control — with proper inter-VLAN routing rules.
Mistake 2: Wrong DHCP Scopes
We frequently find vessels where the DHCP pool has 50 addresses but the owner brings 30 guests with 2-3 devices each. When the pool runs out, devices get APIPA addresses (169.254.x.x) and the crew reports "WiFi is down" when really it's a DHCP exhaustion issue. Size your guest DHCP pool for at least 3x the maximum guest count. Set lease times to 4 hours, not 24 — guests leave and take their DHCP leases with them.
Mistake 3: No Client Isolation on the Guest Network
Without client isolation (also called AP isolation or private VLAN), every guest device can see every other guest device on the network. This is both a security risk and a performance problem — AirPlay and Chromecast discovery traffic floods the wireless medium and causes latency spikes. Enable client isolation on all guest SSIDs and use a separate VLAN for any casting devices that need to be discoverable.
Mistake 4: Starlink on the Wrong VLAN
Starlink Maritime uses CGNAT and has specific MTU requirements (typically 1400). If the Starlink feed lands on the same VLAN as AV control traffic, the Crestron processors may fail to resolve DNS or lose cloud connectivity due to MTU mismatches. Route Starlink through a dedicated WAN VLAN and let your Peplink or firewall handle NAT and MTU clamping before distributing to internal VLANs.
Mistake 5: Firewall Rules Blocking AV Control Traffic
Crestron, Extron, and other AV systems use specific ports and multicast groups for device discovery and control. Overly aggressive firewall rules between VLANs can block CIP (Crestron Internet Protocol on port 41794), prevent Extron SIS commands, or kill multicast routing needed for Crestron NVX video distribution. Audit your inter-VLAN firewall rules specifically for AV protocol traffic — don't just allow "all" or block "all."
Mistake 6: Ignoring IGMP Snooping
Multicast traffic from video-over-IP systems (NVX, Extron NAV) and audio systems (Dante, Sonos) will flood all ports on a switch without IGMP snooping enabled. This means every device on the VLAN receives video traffic intended for a single display. Enable IGMP snooping on all managed switches and designate your core switch as the IGMP querier. Without this, adding a single NVX encoder can bring down the entire network.
How We Fix It
When we board a vessel for a network audit, we start with a complete topology map — every switch, AP, VLAN, and DHCP scope. We then test real-world performance with simulated guest load, verify AV control traffic flows, and check that Starlink/VSAT failover works correctly. The result is a documented, segmented network that performs reliably under charter conditions. Most audits take 4-6 hours and the improvement is immediately noticeable.