VLAN and Firewall Rule Review Checklist

This article applies to yachts using VLANs, routed subnets, firewall rules, switch ACLs, VPNs, Wi-Fi SSIDs, or vendor access paths to separate onboard systems.

Applicability depends on the network design, vessel size, refit history, guest/owner expectations, whether bridge or OT systems are connected, whether personal data is handled, and whether vendors can reach the yacht remotely.

Many yacht networks look segmented on paper. Guest has a VLAN. Crew has a VLAN. AV has a VLAN. Cameras have a VLAN. Engineering has a VLAN. The diagram looks tidy.

The real question is whether those boundaries are enforced.

If the firewall allows broad traffic between zones, if switch trunks carry more VLANs than needed, if a vendor VPN lands inside the wrong subnet, or if Wi-Fi SSIDs all route through the same permissive policy, the yacht may have labels rather than segmentation.

This checklist is for proving the separation. It is not enough to say "we have VLANs." The technical team should be able to show what is allowed, what is blocked, why exceptions exist, and who approved them.

Do a VLAN and firewall rule review at least annually, and always after major change.

Useful trigger points include:

• Newbuild handover.
• Shipyard or refit period.
• Firewall replacement.
• Switch replacement.
• Wi-Fi upgrade.
• SatCom or SD-WAN change.
• AV/control upgrade.
• CCTV or access-control expansion.
• Owner office changes.
• Engineering OT integration.
• Vendor remote-access change.
• Cyber incident or suspicious network behaviour.

The best time to review is before a busy season. The worst time is during a guest trip when something strange is already happening.

Start with evidence, not memory.

Gather:

• Current network diagram.
• VLAN and subnet list.
• Firewall policy export or screenshots.
• Switch configuration export.
• Wi-Fi SSID-to-VLAN mapping.
• VPN user and vendor access list.
• DHCP scope and reservation list.
• Known static IP list.
• Monitoring or firewall traffic logs.
• List of recent refit/vendor changes.

If those records do not exist, the first review finding is documentation. Without a baseline, every rule looks like a possible workaround.

For each VLAN or subnet, write the plain-English purpose.

Examples:

• Guest internet only.
• Crew welfare internet.
• Crew admin and management systems.
• Owner office.
• AV and control.
• CCTV and access control.
• SatCom and WAN management.
• Bridge-adjacent data gateway.
• Engineering monitoring or OT.
• Network infrastructure management.

This sounds basic, but it catches many problems. If nobody can explain why a VLAN exists, it may be old refit debris. If one VLAN is doing five jobs, it may need to be split. If a vendor says "that is just the technical network," ask which technical systems and what consequence they carry.

Every zone should have a default posture.

For low-trust zones, the default should usually be deny between internal networks. Guest devices should reach the internet, DNS, DHCP, and maybe a captive portal. They should not browse the yacht.

For management and owner zones, the default should protect personal and business data. Access to printers, file shares, cloud services, and admin portals should be intentional.

For AV, CCTV, bridge-adjacent, and OT zones, the default should reflect consequence. Some discovery and local system traffic may be necessary, but broad access into other networks should be treated as an exception.

If the firewall has rules like "LAN to any allow" or "technical networks any any", investigate them. They may be old commissioning shortcuts.

Read each firewall rule as a sentence.

"This source is allowed to reach this destination using this service for this reason."

If the sentence is vague, the rule is vague.

Good rules usually have:

• Named source zone or host.
• Named destination zone or host.
• Specific service or port group.
• Clear comment or ticket reference.
• Owner or approver.
• Review date.

Weak rules usually have:

• Any source.
• Any destination.
• Any service.
• No comment.
• Old vendor name.
• No obvious business reason.
• Disabled but not removed duplicates.

Do not delete unknown rules casually. First find out what depends on them. But do not let fear preserve every old exception forever.

Some exceptions are legitimate.

An AV controller may need to reach a lighting processor. A monitoring server may need to poll switches. A dashboard may need read-only data from a vessel-management interface. A vendor may need temporary access to a specific appliance.

The problem is not the exception. The problem is an unnamed exception.

For each exception, record:

• What it supports.
• Who approved it.
• Whether it is permanent or temporary.
• Whether it can be narrowed.
• Whether logging is enabled.
• When it should be reviewed.

If the exception exists only because "it stopped something breaking," treat that as an open investigation, not a finished design.

Firewall rules are only part of the story. Switch configuration can quietly undo the design.

Review trunk ports between switches, firewalls, wireless controllers, AV switches, and virtualised servers. Confirm they carry only the VLANs they need. A trunk carrying every VLAN across the yacht may be convenient, but it increases the chance that a patching mistake or compromised switch reaches more than intended.

Check native VLANs and untagged ports. Unknown or spare ports should not drop devices into a sensitive network. If a contractor plugs into a spare rack port, where do they land?

Disable unused switch ports where practical. At minimum, place unused ports into an unused or quarantine VLAN.

Wi-Fi names are not security controls. They are labels.

Confirm where each SSID lands:

• Guest SSID.
• Crew welfare SSID.
• Owner or family SSID.
• Technical or vendor SSID.
• IoT or AV device SSID.

Guest and crew welfare SSIDs should not land in the same zone as management, AV control, CCTV, bridge-adjacent data, or OT. If a technical SSID exists, control who knows the password and whether device approval is required.

If using RADIUS or 802.1X, confirm that user or device identity actually maps to the correct VLAN. If using shared passwords, assume the password will spread and design accordingly.

VLANs and firewall rules control traffic after a device is on the network. The next question is how devices get into the right zone in the first place.

Use the strongest method that is practical for the yacht.

802.1X or NAC is the strongest common option for managed networks. It can authenticate devices or users and place them into the correct VLAN. It takes planning, but it reduces reliance on shared passwords and manual patch discipline.

MAC address filtering can help with known fixed devices, such as cameras, printers, NVRs, AV processors, monitoring appliances, and some controllers. It is useful for inventory discipline and accidental-device control. It is not strong security because MAC addresses can be spoofed.

Static switch-port assignment is simple and useful in racks where devices rarely move. It only works if patching is controlled and labels are accurate.

DHCP reservations and IP plans do not authenticate devices, but they make review easier. A device with a known name, IP, MAC address, and owner is easier to validate than a mystery host.

Do not rely only on configuration review. Test from the network positions people actually use.

Examples:

• From guest Wi-Fi, confirm you cannot reach camera/NVR interfaces, switch management, firewall admin, NAS, owner printers, or AV processors.
• From crew welfare Wi-Fi, confirm admin systems are not exposed.
• From AV/control, confirm it can reach required AV systems but not unrelated CCTV, owner office, or OT systems.
• From a vendor VPN, confirm the vendor reaches only the approved host or subnet.
• From the infrastructure management zone, confirm access is restricted to authorised admin devices.

Use simple tools first: ping where appropriate, browser tests for web interfaces, port scans where authorised, firewall logs, and packet captures if needed.

Record results. A test that is not recorded becomes an anecdote.

Logs tell you whether the rules match real behaviour.

Look for:

• Blocked traffic from guest or crew networks toward sensitive zones.
• Repeated attempts to reach management interfaces.
• Vendor VPN sessions outside approved windows.
• Rules that are never used.
• Rules that are used far more widely than expected.
• Deny logs that show a service was blocked after a refit.

If the firewall or switch can label traffic by policy, use clear rule names. "Guest to internet" is useful. "Rule 47" is not.

Closeout should produce something useful.

At minimum, create:

• Updated VLAN and subnet list.
• Updated network diagram.
• Firewall rule review notes.
• Exceptions register.
• Vendor access register.
• List of removed, narrowed, or renamed rules.
• Open risks with owner and due date.
• Test evidence showing segmentation works.

Do not bury the output in a generic IT folder. Store it where the captain, manager, ETO, and future vendors can find it during refit or incident response.

A yacht has a guest SSID, crew SSID, AV VLAN, CCTV VLAN, and management VLAN. During review, the ETO finds a firewall rule created during refit:

"AV network to any, any service, allow."

The rule was added because a touch panel could not control a media room after a switch replacement. It was never removed.

The proper fix is not simply deleting it. The proper fix is to identify what the touch panel actually needs. Maybe it needs access to one processor, one media server, and one lighting interface. Those become named rules. Everything else is blocked again. The change is tested from the room, recorded, and added to the exception register.

That is a successful review. It turns a hidden workaround into a controlled design.

The first mistake is assuming that VLANs equal security. VLANs separate traffic, but firewall policy and access control decide whether that separation matters.

The second mistake is keeping old exceptions because nobody knows what they do. Unknown rules should trigger investigation, not permanent immunity.

The third mistake is testing only from the firewall interface. Test from guest Wi-Fi, crew Wi-Fi, vendor VPN, AV racks, and real endpoints.

The fourth mistake is forgetting physical ports. A spare switch port in the wrong VLAN can undo a lot of design work.

The fifth mistake is failing to explain the review to non-technical decision-makers. If management does not understand why a broad vendor rule is risky, it may be reopened the next time service pressure appears.