Yacht IP Plan and Network Map Template

This article applies to yachts that use routed networks, VLANs, managed switches, firewalls, Wi-Fi controllers, servers, cloud-managed devices, vendor VPNs, or any system where an IP address matters during support.

Applicability depends on the yacht's size, refit history, management model, vendor mix, and whether the network touches bridge data, SatCom management, CCTV, access control, AV, owner office systems, crew admin, or engineering OT.

The point is not to create a perfect drawing. The point is to leave a record that the next competent person can trust.

A yacht network can look tidy from the guest side while being hard to support behind the panels. The Wi-Fi works, the TVs stream, and the owner office opens email. Then a switch fails, a firewall is replaced, a vendor changes a controller, or a refit contractor asks which cable can be moved.

That is when weak documentation becomes operational risk.

An IP plan and network map should answer simple questions quickly:

• What is this device?
• Where is it?
• What network is it on?
• Who owns it?
• What depends on it?
• Can it be changed?
• Where is the latest backup or configuration export?

If the answer is spread across memory, old PDF drawings, device labels, installer WhatsApp messages, and a firewall with unnamed rules, the yacht does not have a network record. It has fragments.

Keep one controlled network record pack. It can live in a secure document system, a password-managed shared vault, or a properly backed-up onboard admin folder. The format matters less than whether it is current, controlled, and easy to export.

At minimum, keep these records:

• Network overview diagram.
• IP address plan.
• VLAN and subnet list.
• Firewall zone and rule summary.
• Switch and Wi-Fi inventory.
• DNS and DHCP record.
• Device ownership register.
• Vendor access register.
• Configuration backup location.
• Change log.

Do not make the master record depend on one cloud service only. During an outage, the crew may need an offline copy.

The overview diagram should show how the yacht is put together at a level useful for support. It does not need every cable. It does need the main trust zones, uplinks, gateways, and service paths.

Show:

• Internet sources: LEO, VSAT, 5G/LTE, marina Wi-Fi, shore connection, or backup WAN.
• WAN edge: firewall, SD-WAN router, bonded router, or provider equipment.
• Core switching: main switch stack, distribution switches, and critical uplinks.
• Wi-Fi control: controller, cloud-managed access points, or standalone APs.
• Server/storage area: NAS, virtual hosts, backup servers, or local services.
• Service networks: guest, crew, owner office, AV/control, CCTV, access control, SatCom management, infrastructure management, and engineering or OT where applicable.
• Controlled interfaces: bridge-data gateways, read-only dashboard feeds, vendor VPNs, cloud controllers, or remote support paths.

Use plain labels. A future engineer should not need to decode internal project names before they can begin fault-finding.

The IP plan should be the single place where address ownership is clear. It should not be a stale export from the DHCP server. It should explain how the address space is organised.

For each subnet, record:

• Subnet name.
• VLAN ID if used.
• CIDR range.
• Gateway address.
• DHCP range.
• Static reservation range.
• DNS servers.
• Default route or firewall zone.
• Purpose.
• Owner.
• Review date.

Keep the plan readable. A yacht does not need an enterprise numbering scheme if the crew cannot maintain it. A simple structure is usually better than a clever one.

For example, use a pattern that makes sense:

• Guest networks in one range.
• Crew welfare in another.
• Owner office separate from guest and crew.
• AV/control separate from general devices.
• CCTV and access control separate from owner or guest networks.
• Infrastructure management restricted to approved admin devices.

Private IPv4 address ranges from RFC 1918 are commonly used onboard. That does not make the network private in the security sense. A badly exposed private address can still be reached from another onboard zone, from a vendor VPN, or through a misconfigured route.

The VLAN list should explain the intent behind each network. Avoid records that only say "VLAN 20" or "technical".

For each VLAN, record:

• VLAN ID and name.
• Subnet.
• Firewall zone.
• Switches where it is present.
• Wi-Fi SSID mapping if any.
• Trunk ports where it is carried.
• Allowed inter-zone paths.
• Systems normally found there.
• Whether guest, crew, vendor, bridge-adjacent, or OT traffic is involved.

This is where old refit decisions often surface. If a VLAN exists but nobody knows why, mark it for review. If a VLAN carries too many unrelated systems, note that as a design risk.

Every important device should have an owner. "Owner" does not mean the person who bought it. It means the person or company responsible for support decisions.

For each device, record:

• Hostname.
• Friendly name.
• Make and model.
• Serial number if practical.
• MAC address.
• IP address or DHCP reservation.
• Physical location.
• Rack, panel, or deck area.
• VLAN or subnet.
• System owner.
• Support vendor.
• Admin access method.
• Backup or configuration export location.
• Warranty or support contract note.

This register saves time during real support. If a camera is offline, the crew should know whether it belongs to the CCTV contractor, the access-control vendor, the AV integrator, or the yacht's own IT team.

DNS and DHCP are quiet services until they fail. When they are undocumented, small changes become risky.

Record:

• DHCP server location.
• DHCP scopes.
• Lease duration.
• Reservations.
• DNS server location.
• Internal DNS names.
• Time server/NTP source.
• Any split DNS or local domain assumptions.
• Any devices that use hard-coded DNS.

Keep reservations tidy. A reservation named `unknown-device-13` is better than nothing for a day, but it should not still be there after the next review.

The network map should not reproduce every firewall rule. It should explain the main policy decisions.

Record:

• WAN interfaces and providers.
• Internal firewall zones.
• Default inter-zone posture.
• Management access rules.
• Vendor VPN methods.
• Named remote support accounts.
• MFA status.
• Time-limited access process.
• Logging location.
• Configuration backup process.

The useful question is not "does the firewall have rules?" It is whether the yacht can explain why those rules exist and what would break if one changed.

Use consistent visual language across diagrams.

Suggested conventions:

• Blue for guest and crew convenience networks.
• Dark grey for infrastructure management.
• Green for owner office or business systems.
• Orange for AV/control and media systems.
• Red for CCTV, access control, or security systems.
• Purple for SatCom and WAN edge.
• Black or heavy border for bridge-adjacent and OT interfaces.
• Dashed lines for remote access or cloud control paths.
• One-way arrows for read-only data feeds.

The colours are not the important part. Consistency is. If the diagram changes style every refit, people stop trusting it.

Set a review rhythm that matches yacht operations.

Update the network record:

• After any firewall, switch, Wi-Fi, server, SatCom, AV, CCTV, or OT change.
• Before and after refit.
• Before a busy charter or owner season.
• After a cyber incident, serious outage, or unexplained network fault.
• When a support vendor changes.
• When a captain, ETO, AV/IT lead, or management company changes.

At minimum, review the record annually. For a busy yacht with regular upgrades, quarterly is more realistic.

Every meaningful change should leave a small trail.

A good change entry says:

• What changed.
• Why it changed.
• Who requested it.
• Who approved it.
• Who performed it.
• When it happened.
• What was tested.
• Where the backup is.
• Whether rollback is possible.

This does not need to be bureaucratic. It can be brief. But it must be usable later, when the person who made the change is unavailable.

The network record is part of yacht handover. It should be reviewed when a new ETO, AV/IT technician, captain, management company, or integrator takes responsibility.

Use it to brief:

• Internet and WAN failover.
• Guest and owner network boundaries.
• Vendor remote-access rules.
• Critical switches and firewalls.
• Management credentials and vault location.
• Backup and restore process.
• Known weak points.
• Open changes or temporary workarounds.

The handover should include a walk-through of the real rack or main technical spaces. A diagram is much more useful when the person can connect it to the physical yacht.

A yacht enters refit with a working AV system, two internet providers, and a cloud-managed Wi-Fi platform. The refit scope starts small: add access points in a guest area and replace a few touch panels.

Halfway through the yard period, a contractor asks for a spare switch port. Nobody is sure which VLAN it should use. The old diagram shows a "technical" network, but the firewall has separate AV, CCTV, and management zones. The DHCP server has reservations from three different installers. Some devices are named by cabin, others by rack position, and several are just serial numbers.

The immediate fix is slow because nobody trusts the record.

With a current IP plan and network map, the conversation is different. The team can see the target VLAN, approved DHCP range, switch trunk path, firewall boundary, and support owner. The change still needs testing, but it starts from evidence rather than guesswork.

One common mistake is treating the network diagram as a sales drawing. A polished high-level graphic may help management, but technical crew also need an operational map.

Another mistake is letting each vendor keep a private version. AV, CCTV, IT, SatCom, and OT vendors can maintain their own detail drawings, but the yacht needs one integrated record showing how the boundaries meet.

A third mistake is documenting only live devices. Spare ports, unused VLANs, temporary routes, and abandoned reservations can become the source of the next fault.

The final mistake is failing to protect the record. A network map contains sensitive information. Store it securely, control access, and keep an offline copy available for incident response.