On a ship with a capped satellite or Starlink plan, a few crew devices on a VPN can use more data than the rest of the crew together. The firewall cannot apply its bandwidth limits, content filter or streaming rules to traffic it cannot see. This guide is the approach that works on a SonicWall: several layers, each one catching what the previous one missed, and a log you actually read.
Why one rule is not enough
Commercial VPN apps are built to get past firewalls. When their own protocol is blocked they fall back to TCP or UDP 443, the same port as every web site, and some disguise the tunnel as ordinary HTTPS. No single rule stops all of them. What works is a combination of signature detection, port policy, DNS control and a person (or a tool) looking at what still gets through.
Layer 1: App Control
SonicOS App Control recognises VPN, proxy, Tor and remote access applications by their traffic signatures. Enable it on the crew zone and block the proxy and VPN categories. It needs the Application Visualization and Control licence (sold alone or in a security services bundle); without an active licence the signatures are not updated and new VPN apps are not recognised.
For some VPN apps, SonicWall's own guides recommend client DPI-SSL together with App Control. Client DPI-SSL only works if every device trusts the firewall's certificate, which is rarely realistic on personal crew phones, and apps with certificate pinning break or bypass it. Without it, App Control still catches part of the VPN traffic, but not all of it. That is why the next layers matter.
Layer 2: Port policy, with care
Block the native VPN protocols outbound from the crew zone:
- OpenVPN: UDP 1194 (its default port)
- WireGuard: UDP 51820 (its default port)
- PPTP: TCP 1723 and GRE (IP protocol 47)
These are default ports. Commercial VPN apps often use others, so port blocking catches the simple cases only. L2TP is normally carried inside IPsec, so on the wire it looks like IPsec traffic, not like its own port.
Do not blanket-block IPsec (UDP 500 and 4500). Wi-Fi Calling on iPhone and Android uses an IPsec tunnel to the mobile operator, and blocking those ports cuts off the crew's normal phone calls home. Handle IPsec VPNs through App Control and the log instead.
Blocking QUIC (UDP 443) from the crew zone is worth considering. SonicWall recommends it so that web traffic stays inspectable: browsers fall back to standard HTTPS over TCP, which App Control and the content filter can see.
Layer 3: DNS
Let crew devices use only the ship's DNS server, and block outbound DNS (TCP and UDP 53) to anything else. Then block DNS over TLS (TCP 853). DNS over HTTPS to public resolvers is harder, because it is plain HTTPS; block the well-known resolver addresses. Encrypted DNS is not a VPN, but it bypasses the ship's DNS filter, so it is worth knowing which devices use it.
Layer 4: Read what still passes
After the first three layers most VPN attempts are blocked, and the firewall log shows them as blocked. The ones that matter are the ones that were not. In practice they look like this:
- long-lived connections carrying steady data to a single foreign address, often a hosting provider rather than a known service;
- tunnels on ports of old services that nobody uses any more, such as UDP or TCP 23, or UDP on 22, 80, 25 or 110;
- a device that downloads several gigabytes a day while its owner's App Control detections keep repeating.
Send the firewall's syslog to a PC on board and look at it per device, not per rule. A device with one blocked attempt is not a problem. A device whose traffic passed for six hours on a disguised port is.
What to do with a device that keeps tunnelling
Removing it from the network creates a support call and an angry crew member. A better answer is a quarantine group: an Address Group with its own access rule and a small Bandwidth Object, enough for WhatsApp messages and nothing else. Move the device there, tell the owner why, and move it back when the VPN is gone. WhatsApp, FaceTime and Teams calls and Wi-Fi Calling should never be counted as VPN use.
Tell the crew first
Write the rule into the crew internet policy and say it at the safety meeting: VPNs are not allowed on the crew network because they take the bandwidth everybody shares. Enforcement is much easier when nobody is surprised.
Doing it with Device Manager for SonicWall
Layer 4 is the part that takes time on board. Device Manager for SonicWall collects the firewall syslog on a Windows PC and gives every device a VPN probability from App Control detections, VPN provider sites, protocols, disguised ports, the owner and reverse DNS of the server and the traffic pattern. It can move a device to a quarantine group by itself or ask first, and undo the move later. See the full list of alarms and actions.
All shipboard IT guides · Razvan Malciu, shipboard IT officer