A working harbour on the Cretan coast: eighty berths on four floating pontoons, liveaboards who stay for months, transients who arrive at dusk and leave at dawn, a fuel dock, a chandlery, and a capitaneria office that runs the booking system and takes the money. The sea eats copper and draws lightning, and the paying customers are strangers on boats a hundred metres out over the water. We build it on MikroTik in 10 tested steps.
Full network · all steps built
highlighted = lines added in the selected step · earlier steps shown plain · later steps hidden
Download the full config: MikroTik .rsc · Cisco IOS .txt — illustrative, review before use
This is part 11 of the Build series, and the one that fights the environment hardest. A marina is a small ISP sitting on a pier: the paying customers are strangers on boats out over the water, the plant runs down floating pontoons that move and corrode, and the two things that must never stop — card payments at the fuel dock and the shore-power that keeps bilge pumps running — share a site with a public hotspot for eighty boats.
The design leans on three ideas: carry everything to the pontoons on fibre, not copper, so the sea can't bridge a fault or a surge back into the office; treat every boat as a stranger and bill it like one; and keep the money and the operational systems on their own islands that the guest Wi-Fi can't touch even when it's full.
wifi package, User Manager v5, CAKE)01
A fictional but very typical Cretan marina: a sheltered harbour, eighty berths, open all year, busiest from Easter to October.
Four floating pontoons (A–D) hold eighty berths, from small day-boats to a few forty-metre yachts. A stone quay runs along the shore with the capitaneria office (booking system, VoIP, staff PCs), a chandlery and café with a till, and a fuel dock at the end of the breakwater with its own card terminal. Each berth has a shore-power pedestal with a metered socket and water. Liveaboards stay for months and work from their boats; transients arrive in the evening and want Wi-Fi and a shower. Cameras watch the pontoon heads, the fuel dock and the gate. Internet is fibre to the office, with 5G as backup. The installer manages it from Heraklion.
| Requirement | Where it comes from, and what it forces |
|---|---|
| R1 Wi-Fi to every berth | Boats are 30–120 m out over open water, behind masts and rigging. Sector antennas on the pontoon heads, on a band that carries over water. |
| R2 Every boat is a stranger | Unlike a villa, no two berths are one group. Client isolation on the berth network, and a credential per berth, not one shared key. |
| R3 Metered, billed access | Wi-Fi is a product the marina sells. Per-berth vouchers with a rate cap and a quota, issued and accounted on equipment the marina owns. |
| R4 Payments never share fate | The fuel dock and chandlery take cards. That VLAN talks only to the acquirer — not to the LAN, not to the hotspot, not to the internet at large. |
| R5 Staff and payments stay online | A busy hotspot must never slow a card authorisation or a VoIP call. Fibre primary, 5G backup, and the berths shaped hard on the backup. |
| R6 Survive the sea | Salt corrodes, masts draw lightning, and runs are long. Fibre down the pontoons (no copper over water), surge protection at every entry, replaceable outdoor boxes. |
| R7 Operational safety | Shore-power metering and the fuel controller are operational systems. They sit on their own VLAN, reachable only by staff, never by a boat. |
| R8 Remote management | The harbour's fibre and the 5G are both behind carrier NAT. Management dials out; a dead pontoon must raise an alert, not wait for a complaint. |
02
Each one is where a marina stops behaving like the other networks in this series.
The villa treats one booking as one trust group and lets devices see each other. A marina is the opposite: the boat in A17 and the boat in A18 are two unrelated customers who happen to share an antenna. So the berth network has client isolation on, and access is sold per berth as a voucher, not handed out as one shared key that leaks down the dock.
Copper between the shore and a floating pontoon is a bad idea three ways: the run is long, the two ends sit at different ground potentials over salt water (galvanic current), and a mast is a lightning rod wired straight back to your office switch. Single-mode fibre solves all three — it carries hundreds of metres, it's a dielectric so there's no galvanic path and no surge conductor, and PoE for the antenna is generated locally in the pontoon box.
Over open water with masts in the way, reach beats throughput. 2.4 GHz travels further and diffracts around rigging better than 5 GHz, and a boat only needs enough for streaming and video calls, not a gigabit. Sector antennas on each pontoon head aim down the fairway so the signal follows the line of boats instead of spraying across the harbour.
A cloud captive-portal is one more thing that breaks when the WAN does — and it puts the customer list on someone else's server. RouterOS runs the Hotspot and User Manager on the router itself: vouchers, quotas and per-berth accounting live on hardware the marina owns, and a boat that's already logged in keeps working through a WAN outage.
03
Six VLANs. The berth VLAN is a /22 because a full marina plus guests is a lot of phones; the rest are small and quiet.
| VLAN · subnet | Who lives here · notes |
|---|---|
| 10 STAFF · 10.80.10.0/24 | Office PCs, the berth-management/booking server .20, VoIP phones. Runs the marina. |
| 20 BERTH · 10.80.20.0/22 | The metered hotspot, SSID Marina-WiFi, client-isolated. Pool 10.80.20.10–10.80.23.254. |
| 30 OT · 10.80.30.0/24 | Shore-power pedestals & meters, the fuel-dock controller, AIS receiver and weather station. |
| 40 CCTV · 10.80.40.0/24 | Cameras at the pontoon heads, the fuel dock, the gate and the boatyard. Reservations. |
| 50 PAY · 10.80.50.0/24 | Card terminals: fuel dock and chandlery. Sealed — reaches the acquirer and nothing else. |
| 99 MGMT · 10.80.99.0/24 | R1 .1, SW-CORE .11, pontoon boxes .21–.24, APs. WireGuard to the operator hub: 10.251.0.0/24. |
| WAN | ether1: fibre (DHCP, carrier NAT). ether2: 5G in passthrough (DHCP, carrier NAT). |
04
Rows start, columns receive. Default deny. Payment reaches one destination; the berths reach only the sea of the internet.
Two cells carry the design. Payment → Internet is limited to the acquirer's hosts on 443 and nothing else, so a compromised till can't be a pivot. Berths → Berths is denied: client isolation means the boat next door is as unreachable as a boat in another harbour, which is the opposite of the villa's rule and the whole point of selling access per berth.
04b
Every requirement from the brief, the steps that implement it, the config that does it, and the test that proves it.
| Requirement | Implemented in | Key config | Proven by |
|---|---|---|---|
| R1 Wi-Fi to every berth | step 4 | 2.4 GHz sector APs, CAPsMAN, one SSID over the fairway | "Walk the pontoons" drill |
| R2 Every boat a stranger | step 4 · step 5 | client isolation on V20; per-berth vouchers | "Neighbour sweep" drill |
| R3 Metered, billed access | step 5 | Hotspot + User Manager, rate cap + quota per profile | "Voucher" drill |
| R4 Payments never share fate | step 6 | V50 forward rule: acquirer-only on 443; nothing else | "Payment isolation" drill |
| R5 Staff & payments online | step 7 · step 8 | fibre/5G failover; berth throttled on 5G; VoIP + card auth prioritised | "Busy pontoon" & "WAN out" drills |
| R6 Survive the sea | step 3 · step 10 | single-mode fibre; surge at entries; replaceable pontoon boxes | "Pull a pontoon box" drill |
| R7 Operational safety | step 6 | OT on V30, reachable only from staff V10 | "OT reach" drill |
| R8 Remote management | step 9 | WireGuard dial-out; netwatch per pontoon | "Remote care" drill |
The build
Rack and office first, water last, billing and backup at the end. Every step ends with a checkpoint.
Ten steps: the core switch, the router, fibre to the pontoons, Wi-Fi over the water, the hotspot and billing, the firewall, dual-WAN, fair-sharing, remote care, and power with hardening. Configure on the bench with the pontoon boxes before they go out over the water, and use Safe Mode (Ctrl+X) for every bridge change. A mistake at the end of a 120-metre pontoon in a gale is a different kind of mistake.
05 · Step 1 of 10
One PoE switch in the office rack: the staff, the booking server, the till and the gate camera, with trunks waiting for R1 and the pontoons.
▲ Show step 1 in the interactive topology · see what this step adds, and click any device for its config
! SW-CORE — Catalyst 9300-24P: office access + one trunk to R1, two fibre uplinks vlan 10,20,30,40,50,99 interface range GigabitEthernet1/0/1 - 3 description staff / berth-mgmt / VoIP switchport mode access switchport access vlan 10 interface GigabitEthernet1/0/8 description chandlery card terminal switchport access vlan 50 interface TenGigabitEthernet1/1/1 description uplink to R1 switchport mode trunk switchport trunk allowed vlan 10,20,30,40,50,99 interface range TenGigabitEthernet1/1/2 - 3 description fibre to pontoon-head switches switchport mode trunk switchport trunk allowed vlan 20,30,40,99 interface Vlan99 ip address 10.80.99.11 255.255.255.0 ip default-gateway 10.80.99.1 interface range GigabitEthernet1/0/9 - 24 shutdown
/system identity set name=SW-CORE # enforcement OFF now, ON at the end (lock-out safety) /interface bridge add name=bridge vlan-filtering=no /interface bridge port # uplink to R1 (10G) + two fibre runs to the pontoon-head switches add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged comment="R1" add bridge=bridge interface=sfp-sfpplus2 frame-types=admit-only-vlan-tagged comment="ptA/B" add bridge=bridge interface=sfp-sfpplus3 frame-types=admit-only-vlan-tagged comment="ptC/D" # office access ports: staff on V10, the chandlery till on the payment V50 add bridge=bridge interface=ether1 pvid=10 comment="staff PCs" add bridge=bridge interface=ether2 pvid=10 comment="berth-management server" add bridge=bridge interface=ether3 pvid=10 comment="VoIP" add bridge=bridge interface=ether8 pvid=50 comment="chandlery card terminal" /interface bridge vlan add bridge=bridge vlan-ids=10,20,30,40,50 tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3 add bridge=bridge vlan-ids=99 tagged=bridge,sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3 /interface vlan add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.80.99.11/24 interface=v99-mgmt /ip route add gateway=10.80.99.1 # a quay is a public place: dead-end every unused jack /interface ethernet disable ether9,ether10,ether11,ether12,ether13,ether14,ether15 /interface bridge set bridge vlan-filtering=yes
The core switch carries every office device and hands three trunks upward: one to R1, two to the fibre runs that will feed the pontoons. The chandlery till is the only office port on the payment VLAN, and it's a physically separate jack in a locked position behind the counter. As everywhere in this series, VLAN filtering goes on last, after the uplink is proven, so a typo can't lock you out of the rack.
/interface bridge vlan print: V10 on ether1–3, V50 on ether8, all tagged on the three SFP+ ports.06 · Step 2 of 10
A CCR2004 as router-on-a-stick: a gateway per VLAN, a big /22 pool for the boats, upstream DNS that doesn't clash with the failover probe.
▲ Show step 2 in the interactive topology · see what this step adds, and click any device for its config
! R1 — Catalyst 8200: SVIs as VLAN gateways; the berth SVI is a /22 ip routing vlan 10,20,30,40,50,99 interface Vlan10 ip address 10.80.10.1 255.255.255.0 interface Vlan20 ip address 10.80.20.1 255.255.252.0 interface Vlan30 ip address 10.80.30.1 255.255.255.0 interface Vlan40 ip address 10.80.40.1 255.255.255.0 interface Vlan50 ip address 10.80.50.1 255.255.255.0 interface Vlan99 ip address 10.80.99.1 255.255.255.0 ip dhcp excluded-address 10.80.20.1 10.80.20.9 ip dhcp pool BERTH network 10.80.20.0 255.255.252.0 default-router 10.80.20.1 dns-server 10.80.20.1 lease 0 1 ip name-server 9.9.9.9 149.112.112.112 ip dns server ntp server time.cloudflare.com
/system identity set name=R1 /interface bridge add name=bridge vlan-filtering=no /interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged comment="core" /interface bridge vlan add bridge=bridge vlan-ids=10,20,30,40,50 tagged=bridge,sfp-sfpplus1 add bridge=bridge vlan-ids=99 tagged=bridge,sfp-sfpplus1 /interface vlan # one interface per VLAN = router-on-a-stick; each is that VLAN gateway add name=v10-staff interface=bridge vlan-id=10 add name=v20-berth interface=bridge vlan-id=20 add name=v30-ot interface=bridge vlan-id=30 add name=v40-cctv interface=bridge vlan-id=40 add name=v50-pay interface=bridge vlan-id=50 add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.80.10.1/24 interface=v10-staff # /22 for berths: room for a full marina of boats plus their guests add address=10.80.20.1/22 interface=v20-berth add address=10.80.30.1/24 interface=v30-ot add address=10.80.40.1/24 interface=v40-cctv add address=10.80.50.1/24 interface=v50-pay add address=10.80.99.1/24 interface=v99-mgmt # the berth pool is handed out behind the hotspot (step 5); 1h leases /ip pool add name=p-berth ranges=10.80.20.10-10.80.23.254 /ip dhcp-server add name=d-berth interface=v20-berth address-pool=p-berth lease-time=1h /ip dhcp-server network add address=10.80.20.0/22 gateway=10.80.20.1 dns-server=10.80.20.1 # … staff, OT, CCTV and payment all use host reservations /ip dns set allow-remote-requests=yes servers=9.9.9.9,149.112.112.112 /system ntp client set enabled=yes servers=time.cloudflare.com /interface bridge set bridge vlan-filtering=yes
The CCR2004 has the headroom a marina's NAT table needs — a full hotspot is hundreds of devices behind one address. Each VLAN gets its .1 gateway; the berth VLAN is a /22 so a packed summer weekend plus every guest's phone still fits. The berth DHCP leases are short (an hour) because boats come and go all day. Upstream DNS is Quad9, leaving 1.1.1.1 free to become the failover probe in step 7.
07 · Step 3 of 10
Single-mode fibre out to each pontoon head, into an IP66 box that powers the antenna and the pontoon's wired plant.
▲ Show step 3 in the interactive topology · see what this step adds, and click any device for its config
! Pontoon A head — Catalyst IE3300 (IP-rated): SFP fibre uplink, PoE to the sector AP vlan 20,30,40,99 interface GigabitEthernet1/1 (SFP) description fibre to core switchport mode trunk switchport trunk allowed vlan 20,30,40,99 interface GigabitEthernet1/0/1 description sector AP (PoE trunk) switchport mode trunk switchport trunk native vlan 99 switchport trunk allowed vlan 20,99 interface GigabitEthernet1/0/2 description shore-power pedestals A switchport access vlan 30 interface GigabitEthernet1/0/3 description pontoon-head camera switchport access vlan 40 interface Vlan99 ip address 10.80.99.21 255.255.255.0
/system identity set name=SW-PONTOON-A /interface bridge add name=bridge vlan-filtering=no /interface bridge port # fibre back to SW-CORE: no copper over the water, so no galvanic path add bridge=bridge interface=sfp1 frame-types=admit-only-vlan-tagged comment="fibre to core" # the sector AP rides a trunk: mgmt V99 untagged, berth SSID on V20 add bridge=bridge interface=ether1 pvid=99 comment="sector AP (PoE, trunk)" # wired pontoon plant: shore-power pedestals (OT) and the pontoon-head camera add bridge=bridge interface=ether2 pvid=30 comment="shore-power pedestals A" add bridge=bridge interface=ether3 pvid=40 comment="pontoon-head camera" /interface bridge vlan add bridge=bridge vlan-ids=20,99 tagged=sfp1,ether1 add bridge=bridge vlan-ids=30,40 tagged=sfp1 /interface vlan add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.80.99.21/24 interface=v99-mgmt /ip route add gateway=10.80.99.1 # salt and lightning will kill this box one day; its config restores from the hub /interface bridge set bridge vlan-filtering=yes
This is the step that keeps the sea out of the office. Each pontoon head is a sealed outdoor box with an SFP fibre uplink and a small PoE switch; the fibre is a dielectric, so there is no copper bridging two different ground potentials over salt water and no metallic path for a mast strike to follow back to the rack. The box powers the sector antenna locally and picks up the pontoon's shore-power meters and camera. Treat it as a consumable: when salt or lightning eventually takes one, a replacement restores its config from the hub and is back in minutes.
Use outdoor, gel-filled or armoured single-mode with marine-rated conduit along the pontoon, and leave a service loop at the hinge where the pontoon moves against the shore — that flex point is where a cable dies first. Terminate with pre-polished connectors in the dry box, not in the open air over the water.
/interface ethernet monitor sfp-sfpplus2: link up, running at the fibre SFP's rate.08 · Step 4 of 10
Sector antennas on the pontoon heads, one open SSID over the fairway, a hidden one for staff — all pushed from R1.
▲ Show step 4 in the interactive topology · see what this step adds, and click any device for its config
! Catalyst 9800 embedded controller: an open 'webauth' WLAN + a hidden staff WLAN wlan Marina-WiFi 1 Marina-WiFi no security wpa security web-auth security web-auth authentication-list GUEST-RADIUS no shutdown wlan Marina-Staff 2 Marina-Staff security wpa psk set-key ascii 0 ******** security wpa akm psk no broadcast-ssid no shutdown wireless profile policy BERTH vlan 20 no shutdown ! the berth WLAN is 2.4 GHz only (radio policy) for reach over the water
/interface wifi datapath add name=dp-berth bridge=bridge vlan-id=20 add name=dp-staff bridge=bridge vlan-id=10 /interface wifi security # berth SSID is OPEN — the hotspot (step 5) does the authentication, not WPA add name=sec-open authentication-types="" disabled=no add name=sec-staff authentication-types=wpa2-psk,wpa3-psk passphrase="********" /interface wifi configuration # 2.4 GHz: it reaches further over open water and bends around masts better than 5 GHz add name=cfg-berth ssid=Marina-WiFi security=sec-open datapath=dp-berth country=Greece \ .channel.band=2ghz-ax add name=cfg-staff ssid=Marina-Staff security=sec-staff datapath=dp-staff country=Greece \ hide-ssid=yes /interface wifi capsman set enabled=yes interfaces=v99-mgmt # the sector antennas point down the fairway; one config provisions every pontoon AP /interface wifi provisioning add action=create-dynamic-enabled supported-bands=2ghz-ax \ master-configuration=cfg-berth slave-configurations=cfg-staff
One controller on R1 provisions every pontoon AP with the same two SSIDs: an open Marina-WiFi that the hotspot will gate in step 5, and a hidden WPA3 Marina-Staff for the harbour-master's tablet. The berth SSID runs on 2.4 GHz on purpose — over open water, with masts and rigging in the way, reach and diffraction matter more than the throughput 5 GHz would add. The sectors point down the fairway so the beam follows the line of boats.
A metal mast and a boom full of rigging sit right between the antenna and the cockpit where people use their phones. Mount the sector high on the pontoon-head pole so it looks over the near boats, accept that 2.4 GHz is congested (every boat's own hotspot is on it), and plan co-channel reuse across pontoons the way you would cells, not like one big AP.
/interface wifi registration-table print shows boats associating on each pontoon.09 · Step 5 of 10
The open SSID becomes a product: a voucher per berth, a rate cap, a fair quota, all issued and accounted on the router.
! IOS has no on-box billing. The marina pattern is ISE (or an external captive portal ! appliance) as the RADIUS/guest server, with the controller pointed at it: aaa new-model aaa authentication login GUEST-RADIUS group radius radius server ISE address ipv4 10.80.10.20 auth-port 1812 acct-port 1813 key ******** ! vouchers, quotas and per-berth accounting are created in ISE's guest portal, ! not in the switch; the walled garden (pre-auth ACL) permits the booking + card hosts.
# the captive portal lives on the berth gateway /ip hotspot profile add name=marina hotspot-address=10.80.20.1 dns-name=wifi.marina login-by=http-chap,cookie \ use-radius=yes /ip hotspot add name=berth interface=v20-berth address-pool=p-berth profile=marina # User Manager v5 is the RADIUS server, running on R1 itself → point RADIUS at loopback /radius add service=hotspot address=127.0.0.1 secret="********" /user-manager set enabled=yes /user-manager/router add name=self address=127.0.0.1 shared-secret="********" # a rate cap and a fair daily quota per boat; a week-long profile for a transient berth /user-manager/limitation add name=lim-berth rate-limit=20M/5M /user-manager/profile add name=berth-week name-for-users="7-day berth" validity=7d /user-manager/profile-limitation add profile=berth-week limitation=lim-berth # one voucher per slip, printed at the office on arrival; the code is never logged /user-manager/user add name=A17 password="<voucher>" shared-users=3 /user-manager/user add name=A17 attributes=... # bind to profile berth-week # walled garden: the booking page and the card host stay reachable before login /ip hotspot walled-garden add dst-host=book.marina.example action=allow add dst-host=*.acquirer.example action=allow
The hotspot turns the open Wi-Fi into something the office sells. User Manager — RouterOS's own RADIUS server — runs on R1 itself, so the customer list and the accounting never leave the marina's hardware, and a boat that has already logged in keeps working even if the WAN drops. The office prints a voucher per berth on arrival, tied to a profile that sets the stay length, the rate cap and a fair daily quota. The walled garden keeps the booking page and the card host reachable before anyone logs in, so a guest can pay for access and the fuel dock can take a card without a session.
Generate voucher codes with real randomness, hand them out on paper, and never write the code to the log or an e-mail body (log that a voucher was issued, not the code). Set shared-users to match a boat's realistic device count; one voucher for a whole pontoon is how a marina ends up running an open relay.
/ip hotspot active print and /user-manager/session print show the session and its accounting.10 · Step 6 of 10
Payment reaches the acquirer and nothing else. OT answers only to staff. Every boat gets the internet and no neighbours.
! R1 — Zone-Based Firewall. No zone-pair = dropped (default-deny). zone security STAFF zone security BERTH zone security OT zone security CCTV zone security PAY zone security WAN ! each inside VLAN joins its zone (interface VlanXX / zone-member security ...) class-map type inspect match-any CM-GEN match protocol tcp match protocol udp match protocol icmp policy-map type inspect PM-OUT class type inspect CM-GEN inspect class class-default drop ! payment reaches only the acquirer, on 443 ip access-list extended ACL-ACQ permit tcp any 203.0.113.0 0.0.0.255 eq 443 class-map type inspect match-all CM-ACQ match access-group name ACL-ACQ policy-map type inspect PM-ACQ class type inspect CM-ACQ inspect zone-pair security ZP-PAY-WAN source PAY destination WAN service-policy type inspect PM-ACQ ! staff -> OT, CCTV, WAN ; OT/CCTV/BERTH -> WAN only ; no pair = no path zone-pair security ZP-STAFF-OT source STAFF destination OT service-policy type inspect PM-OUT zone-pair security ZP-BERTH-WAN source BERTH destination WAN service-policy type inspect PM-OUT
/interface list add name=WAN add name=MGMT /interface list member add list=MGMT interface=v99-mgmt # a named host group: where the card terminals are allowed to talk /ip firewall address-list add list=ACQUIRER address=203.0.113.0/24 comment="card acquirer (example)" /ip firewall filter # input = TO the router; established back in, then judge only NEW add chain=input action=accept connection-state=established,related,untracked add chain=input action=drop connection-state=invalid add chain=input action=accept in-interface-list=MGMT # berths reach the router only for DNS/DHCP and the hotspot portal add chain=input action=accept in-interface=v20-berth protocol=udp dst-port=53,67 add chain=input action=accept in-interface=v20-berth protocol=tcp dst-port=53,64872,64873 add chain=input action=drop log=yes log-prefix=IN-DROP # forward = THROUGH the router; default-deny at the end add chain=forward action=accept connection-state=established,related,untracked add chain=forward action=drop connection-state=invalid # payment: the till VLAN reaches ONLY the acquirer, nothing on the LAN, nothing else out add chain=forward action=accept in-interface=v50-pay dst-address-list=ACQUIRER \ protocol=tcp dst-port=443 # staff run the marina: book boats, read the meters, watch the cameras add chain=forward action=accept in-interface=v10-staff out-interface=v30-ot add chain=forward action=accept in-interface=v10-staff out-interface=v40-cctv add chain=forward action=accept in-interface=v10-staff out-interface-list=WAN # OT and cameras reach only their own clouds (step 8 shapes them), never the LAN add chain=forward action=accept in-interface=v30-ot out-interface-list=WAN add chain=forward action=accept in-interface=v40-cctv out-interface-list=WAN # berths: the internet and nothing else — and never each other add chain=forward action=accept in-interface=v20-berth out-interface-list=WAN add chain=forward action=accept in-interface-list=MGMT add chain=forward action=drop log=yes log-prefix=FWD-DROP
The forward chain is the marina's property line. The payment VLAN is allowed exactly one thing — the acquirer on 443 — so a compromised terminal is a dead end, not a pivot onto the booking server or the hotspot. The operational VLAN (shore-power, fuel controller, AIS) answers only to staff on V10 and otherwise reaches just its vendors' clouds. The berths reach the internet and, by the absence of any rule and by client isolation, nothing and no one else on the network.
11 · Step 7 of 10
Fibre carries the harbour; 5G catches it when the fibre drops, with the hotspot throttled so staff and payments keep their share.
▲ Show step 7 in the interactive topology · see what this step adds, and click any device for its config
! R1 — fibre on Gi0/0/0 (DHCP), 5G on the cellular interface as the backup interface GigabitEthernet0/0/0 description fibre ip address dhcp ip nat outside ip sla 1 icmp-echo 1.1.1.1 frequency 5 ip sla schedule 1 life forever start-time now track 1 ip sla 1 reachability ip route 0.0.0.0 0.0.0.0 dhcp 1 track 1 ip route 0.0.0.0 0.0.0.0 Cellular0/2/0 2 ip access-list standard NAT-ALL permit 10.80.0.0 0.0.255.255 ip nat inside source list NAT-ALL interface GigabitEthernet0/0/0 overload ! police the berth VLAN down hard when it rides the cellular backup
/interface list member add list=WAN interface=ether1 /interface list member add list=WAN interface=ether2 /ip dhcp-client add interface=ether1 add-default-route=no use-peer-dns=no comment="fibre" # 5G as a passthrough modem; its default route sits at a worse distance (backup) /ip dhcp-client add interface=ether2 default-route-distance=2 use-peer-dns=no comment="5G" /ip route # recursive main route: reachable only while the probe through fibre answers add dst-address=1.1.1.1/32 gateway=ether1 scope=10 comment="probe via fibre" add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=1 \ comment="main: fibre" /ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN # on 5G, the hotspot (berth Wi-Fi) is throttled hard; staff, payments and VoIP are not /ip firewall mangle add chain=forward action=mark-packet new-packet-mark=berth-5g \ in-interface=v20-berth out-interface=ether2 passthrough=no /queue tree add name=berth-on-5g parent=global packet-mark=berth-5g max-limit=15M \ queue=pcq-download-default
Fibre is the primary path with a recursive route whose health is a ping through the fibre gateway; 5G sits behind it at a worse distance and takes over on failure. The difference from the villa is who gets protected: here the guests are the ones squeezed on the backup. When the harbour runs on 5G, the berth hotspot is throttled to a trickle so that a card authorisation, a VoIP call to a chandler, and the booking system keep working. Paying boats stay connected, just slowly, which is the honest trade on a backup link.
12 · Step 8 of 10
CAKE shares the fibre fairly between boats; VoIP and card authorisations ride above the crowd.
! IOS: no CAKE. A shaper with fair-queue + an LLQ priority class for VoIP and card auth. class-map match-any PRIORITY match dscp ef match dscp af41 policy-map WAN-CHILD class PRIORITY priority percent 20 class class-default fair-queue policy-map WAN-OUT class class-default shape average 90000000 service-policy WAN-CHILD interface GigabitEthernet0/0/0 service-policy output WAN-OUT
# CAKE shares the fibre fairly per host first: one busy boat cannot starve the others /queue type add name=cake-up kind=cake cake-diffserv=diffserv4 cake-nat=yes cake-flowmode=dual-srchost add name=cake-down kind=cake cake-diffserv=diffserv4 cake-flowmode=dual-dsthost /ip firewall mangle # lift VoIP and card-auth into the priority tin so a full hotspot never delays them add chain=prerouting action=change-dscp new-dscp=46 src-address=10.80.10.0/24 \ protocol=udp dst-port=10000-20000 comment="VoIP RTP" add chain=prerouting action=change-dscp new-dscp=34 src-address=10.80.50.0/24 \ comment="card auth" add chain=forward action=mark-packet new-packet-mark=from-fibre in-interface=ether1 \ passthrough=no /queue tree add name=wan-up parent=ether1 queue=cake-up max-limit=90M add name=wan-down parent=global packet-mark=from-fibre queue=cake-down max-limit=450M
CAKE gives per-host fairness, so one liveaboard pulling a system update can't starve forty other boats, and its NAT mode sees the real inside host behind the masquerade. On top of that, the two flows that must never wait — VoIP from the office and card authorisations from the payment VLAN — are marked into CAKE's priority tin, so even a saturated hotspot doesn't add a beat of delay to a phone call or a card tap. Set the limit just under the fibre's real throughput, because CAKE only controls latency when the queue lives in R1.
/queue tree print stats: drops on wan-down under load; the priority tin stays near-empty.13 · Step 9 of 10
The marina dials out to the operator. Then it reports a dead pontoon before a sailor does.
▲ Show step 9 in the interactive topology · see what this step adds, and click any device for its config
! R1 — FlexVPN client dials out to the operator hub through the harbour's NAT crypto ikev2 profile TO-HUB match identity remote fqdn hub.example.net identity local fqdn marina-r1.example.net authentication local rsa-sig authentication remote rsa-sig pki trustpoint OP-CA interface Tunnel1 ip address 10.251.0.31 255.255.255.0 tunnel source GigabitEthernet0/0/0 tunnel destination dynamic tunnel protection ipsec profile TO-HUB logging host 10.251.0.1 logging trap warnings event manager applet WAN-DOWN event track 1 state down action 1 syslog msg "fibre DOWN"
/interface wireguard add name=wg-ops listen-port=13231
/interface wireguard peers add interface=wg-ops comment="operator hub" \
public-key="<hub public key>" endpoint-address=hub.example.net endpoint-port=51820 \
allowed-address=10.251.0.0/24 persistent-keepalive=25s
/ip address add address=10.251.0.31/24 interface=wg-ops
/interface list member add list=MGMT interface=wg-ops
/system logging action add name=hub target=remote remote=10.251.0.1
/system logging add topics=warning action=hub
# watch the fibre path and every pontoon switch; a dead pontoon is a silent outage
/tool netwatch add host=1.1.1.1 interval=30s type=simple \
down-script=":log warning \"fibre DOWN\"" up-script=":log warning \"fibre UP\""
/tool netwatch add host=10.80.99.21 interval=60s type=simple \
down-script=":log warning \"Pontoon A offline\""Both WANs are behind carrier NAT, so management is an outgoing WireGuard tunnel to the operator's hub, exactly as in the coffee shop. With the keepalive it survives the switch to 5G and reconnects itself. The valuable addition here is a netwatch per pontoon: a flooded or lightning-struck pontoon box goes quiet, and the operator sees Pontoon A offline in the hub's log — an outage that would otherwise surface as a liveaboard walking up the dock to complain.
14 · Step 10 of 10
A harbour cuts power, draws lightning and breathes salt. The network rides through the first, survives the second, and is built to be repaired after the third.
| Item | What and why |
|---|---|
| UPS | A line-interactive UPS in the rack carries R1, SW-CORE and the 5G modem through the brown-outs a harbour sees when big boats draw shore power. Set it to restart loads automatically when power returns. |
| Lightning & surge | The pontoon masts are the tallest things for a mile. Fibre keeps a strike off the data path; still fit surge protection on the shore-power feed into every pontoon box, and bond the box to the pontoon's earth. |
| Salt & ingress | IP66/67 enclosures, stainless fixings, dielectric grease on every outdoor connector, and drip loops so water runs off the cable, not into the gland. Budget a service visit before each season. |
| Replaceable pontoon boxes | Keep a spare box pre-staged. A swap pulls its config from the hub and it rejoins in minutes; nothing depends on hand-tuning out on the water. |
| Hardening | Management only from the MGMT list (V99 + the tunnel), the default admin disabled, DHCP snooping on SW-CORE with the uplink trusted, and the hotspot's RADIUS secret and voucher store kept off any synced or world-readable location (see hardening). |
15
Run these at handover, write the results in the marina's documentation, and repeat the WAN and power drills before each season.
| Drill (requirement) | What must happen |
|---|---|
| Walk the pontoons (R1) | A phone on a video call walks the length of each pontoon without dropping; the far berth is usable. |
| Neighbour sweep (R2) | From Marina-WiFi, a scan finds only the gateway. No other boat, camera, meter or till answers. |
| Voucher (R3) | A voucher logs in, applies its rate cap and quota, and expires at the end of the stay; the code never appears in a log. |
| Payment isolation (R4) | From the till VLAN, only the acquirer answers on 443; the LAN and the rest of the internet do not. |
| Busy pontoon & WAN out (R5) | Under a saturated hotspot, a card auth and a VoIP call stay fast; on 5G, berths throttle and payments don't. |
| Pull a pontoon box (R6) | Swapping in the spare restores from the hub; the pontoon is back within minutes with nobody re-typing config. |
| OT reach (R7) | Staff reach the shore-power controller and the fuel dock; a boat on the berth VLAN cannot. |
| Remote care (R8) | The operator reaches R1 through the tunnel over fibre and over 5G; a dead pontoon raises a log alert. |
16
What the network can't do on its own, and what covers each gap.
17
I test networks like this for a living. Here's what I'd try against a marina full of strangers on boats, and why each one is a decision rather than an oversight.
18
The routing, the hotspot, billing, failover and queues all run on CHR. The fibre, the sectors and salt water don't.
| This post | In the lab |
|---|---|
| R1 + dual-WAN | A CHR with two WAN links fed by two "ISP" CHRs handing out carrier-NAT addresses; pull one to test the recursive failover. |
| Hotspot + User Manager | Fully testable on CHR: create a profile and a voucher, connect a VM to V20, and watch the portal, the rate cap and the accounting. |
| Pontoon boxes, fibre | CHR bridges; a plain virtual link stands in for each fibre run. |
| Sector Wi-Fi | Skip it, or tag VMs into V20 to stand in for boats. |
19
Indicative EU street prices, late 2026, excluding VAT. Fibre, conduit and the marine install labour dwarf the electronics and vary by harbour.
| Item | Indicative (EUR, ex VAT) |
|---|---|
| R1 · CCR2004-16G-2S+ | 380 – 480 |
| SW-CORE · CRS328-24P-4S+ + DAC | 440 – 560 |
| 4× pontoon box (netPower 16P + IP66 enclosure + SPD) | 300 – 420 each |
| 4× 2.4 GHz sector AP (mANTBox-class) | 150 – 220 each |
| 5G backup (Chateau 5G ax) | 220 – 320, plus a data SIM |
| UPS + per-pontoon surge protection | 400 – 700 |
| Electronics total | ≈ 3,500 – 5,500, plus single-mode fibre, marine conduit and install |
Appendix
Same marina and VLANs on Cisco's line. The Cisco tabs on the config blocks above show where it differs; this appendix covers the rest.
| Role | This post → Cisco |
|---|---|
| R1 + 5G | CCR2004 + Chateau 5G → Catalyst 8200 with a cellular module |
| SW-CORE (PoE) | CRS328-24P-4S+ → Catalyst 9300-24P |
| Pontoon boxes | netPower → Catalyst IE3300 rugged, IP-rated switches |
| Sector Wi-Fi | mANTBox → Catalyst outdoor APs / Ultra-Reliable Wireless Backhaul |
| Billing / captive portal | Hotspot + User Manager → ISE guest portal (a separate appliance/licence) |
| Indicative total | ≈ 3,500 – 5,500 → ≈ 16,000 – 26,000 EUR ex VAT |
The billing is the big divergence. RouterOS runs the hotspot, the RADIUS server and the voucher store on the router you already bought; the Cisco equivalent is ISE (or a third-party captive-portal appliance) as a separate box with its own licence, and the accounting lives there instead of on the marina's router. And there is no CAKE, so per-boat fairness becomes a shaper with fair-queue plus an LLQ class for VoIP and card auth.
For a single marina, MikroTik is the clear fit. Cisco makes sense only when a port authority already standardises on it across many harbours.
Takeaways
This is part 11 of the Build series. Earlier: the café chain, the holiday villa, the festival, the off-grid farm. The marina is the one that fights salt water and lightning for a living.
I build marina networks like this one: metered Wi-Fi that reaches the far berth, a sealed money-path at the fuel dock, shore-power and cameras kept apart, fibre that keeps the sea out of your rack, and remote care so a dead pontoon is a message, not a complaint.
Network & IT consulting in Crete →