A four-bedroom rental villa in the Cretan hills, a pool, a guest annex 40 metres down the garden, no fibre within reach, and an owner who lives abroad. The Wi-Fi is in every review, the guests change every Saturday, and nobody is on site when something breaks. We build it on MikroTik and Starlink in 10 tested steps.
Full network · all steps built
highlighted = lines added in the selected step · earlier steps shown plain · later steps hidden
This is part 6 of the Build series, and the one closest to everyday installation work in Crete. Most of the island's rental villas sit where fibre doesn't reach and VDSL tops out at a few Mb/s, so Starlink has become the default. A villa network looks like a home network, but it has a business's problems: paying guests who judge the stay by the Wi-Fi, an owner whose devices and smart home must stay private, and no IT person within an hour's drive.
The design leans on three ideas: treat each booking as one trusted group but never trust the next one, manage everything remotely through a tunnel the villa dials out itself, and make every component recover from a power cut without anyone touching it.
wifi package, :rndstr)01
A fictional but very typical Cretan villa: rented weekly from May to October, used by the owner's family a few weeks a year, empty in winter.
The main house has a living area, kitchen and four bedrooms on two floors, each bedroom with a smart TV. The pool and garden are where guests spend the day, phones in hand. A guest annex with its own bedroom sits 40 m down the garden. The owner keeps a locked office with a PC and a NAS of family photos. The smart home runs the alarm, smart locks (guests get door codes per booking), pool controller, irrigation and gate. Four exterior cameras cover the gate, driveway and pool area. Internet is Starlink; the only alternative is mobile. The installer manages it all from Heraklion.
| Requirement | Where it comes from, and what it forces |
|---|---|
| R1 Wi-Fi everywhere | Guests review the Wi-Fi by the pool and in the annex, not in the utility room. Indoor APs, an outdoor AP at the pool, and a link to the annex. |
| R2 Owner & smart home private | Guests must never reach the owner's office, the alarm, the locks or the cameras. The smart home must keep working when guests do strange things on the Wi-Fi. |
| R3 A new key per booking | Last week's guests shouldn't be able to use the Wi-Fi from the road outside. The guest key changes at every checkout, automatically. |
| R4 Stay online | Starlink drops in storms or when obstructed. A 4G backup keeps guests online; camera uploads and smart-home clouds wait. |
| R5 Good on a variable link | Starlink's capacity changes minute by minute. Guests on video calls (remote workers book villas too) need low latency even while someone downloads. |
| R6 Remote management | Starlink and 4G are both behind carrier NAT. Management must work without any inbound connection. |
| R7 Power cuts | Rural grid cuts are routine in summer storms. Everything rides through short cuts and comes back by itself after long ones. |
| R8 Guest privacy | Cameras are exterior only, disclosed in the listing, and unreachable from the guest network. Booking platforms ban indoor cameras outright. |
02
Each one is a trade-off between what a villa is and what a network textbook assumes.
A café isolates every guest device from every other one. A villa is rented by one family or one group of friends at a time, and they want to cast from their phones to the TVs. So the guest VLAN has no client isolation; the TVs sit in it on purpose. The isolation that matters is between bookings, and that's handled by changing the Wi-Fi key at every checkout (step 8).
Starlink gives 150–250 Mb/s down here; the 4G signal on the hill gives 20–40. The roles follow the numbers. The backup carries guests (shaped) but refuses camera and smart-home cloud uploads, which would only compete with the guests for a small pipe.
The annex is 40 m away across a garden with a stone wall. Trenching for a cable costs more than the whole network and wrecks the garden. A pair of wAP 60G radios gives a gigabit-class, line-of-sight bridge that carries the VLAN trunk. At 40 m, rain fade is irrelevant; the only enemy is a growing tree, which the annual service visit checks.
The other Build posts use queue trees with explicit classes. That works when the line rate is fixed. Starlink's isn't, and a villa has no IT person to retune queues. CAKE (a queue discipline built into RouterOS 7) shares bandwidth fairly per host, keeps latency low for small flows, and with its NAT mode it sees the real inside hosts behind masquerade. One queue per direction, set slightly under Starlink's typical evening capacity.
03
Five VLANs. A villa doesn't need more; it needs these five to never leak into each other.
| VLAN · subnet | Who lives here · notes |
|---|---|
| 10 OWNER · 10.70.10.0/24 | Owner's office PC .10, NAS .11, owner's phones and laptops on hidden SSID VILLA-Owner. |
| 20 GUEST · 10.70.20.0/24 | Guest Wi-Fi VILLA-Guest (key rotated per booking) and the four TVs .31–.34 (wired). |
| 30 SMART-HOME · 10.70.30.0/24 | Alarm panel .20, pool controller .21, irrigation/gate .22, smart-lock bridge .23. Reservations. |
| 40 CCTV · 10.70.40.0/24 | Four exterior cameras .21–.24, recording to the camera vendor's cloud. |
| 99 MGMT · 10.70.99.0/24 | R1 .1, SW-UTIL .11, APs .21–.24, 60 GHz radios .31–.32. WireGuard to the operator hub: 10.250.0.0/24. |
| WAN | ether1: Starlink in bypass mode (DHCP, 100.64.0.0/10 carrier NAT). ether2: 4G LtAP in passthrough (DHCP, carrier NAT). |
04
Rows start, columns receive. Default deny. The guest row is short on purpose.
Two cells are unusual for this series. Guests → Guests is open, because one booking is one group (decision 1). Owner → Guests is limited to casting to the TVs, so the owner's family can use them when they stay, without the owner's devices being reachable from the guest side.
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 everywhere | step 3 | two indoor cAP ax, outdoor wAP ax at the pool, 60 GHz bridge + cAP in the annex | "Walk the property" drill, section 15 |
| R2 Owner & smart home private | step 3 · step 4 | VLANs 10/20/30/40; forward chain; smart home on its own SSID | "Guest sweep" drill |
| R3 A new key per booking | step 8 | rotate-guest-psk script + Saturday scheduler; key never logged | "Checkout" drill |
| R4 Stay online | step 5 · step 6 | Starlink bypass + DHCP-script probe route; 4G at distance 2; NO4G list | "Starlink out" drill |
| R5 Good on a variable link | step 7 | CAKE per host with NAT mode, set under evening capacity | "Busy evening" drill |
| R6 Remote management | step 9 | WireGuard dial-out with keepalive; netwatch alerts to the hub | "Remote care" drill |
| R7 Power cuts | step 10 | UPS with auto-restart; nothing depends on boot order | "Power cut" drill |
| R8 Guest privacy | step 1 · step 4 | exterior cameras only; V40 unreachable from V20 | "Privacy" drill |
The build
Wired devices first, Starlink last but one, remote care at the end. Every step ends with a checkpoint.
Ten steps: the utility switch, the router, Wi-Fi and the annex link, the firewall, Starlink, the 4G backup, CAKE, per-booking keys, remote management, and power with backups. Configure on site with a laptop on the management VLAN, and use Safe Mode (Ctrl+X) for every bridge change. The next time you're on site might be next spring.
05 · Step 1 of 10
Cameras, the smart-home hubs, the TVs and the owner's office on one PoE switch in the utility room.
▲ Show step 1 in the interactive topology · see what this step adds, and click any device for its config
/system identity set name=SW-UTIL /interface bridge add name=bridge vlan-filtering=no /interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged comment="uplink R1 (10G DAC)" add bridge=bridge interface=ether1 pvid=40 comment="camera gate" # … ether2-4: driveway, pool x2 add bridge=bridge interface=ether5 pvid=30 comment="alarm panel" add bridge=bridge interface=ether6 pvid=30 comment="pool controller" add bridge=bridge interface=ether7 pvid=30 comment="irrigation + gate" add bridge=bridge interface=ether8 pvid=30 comment="smart-lock bridge" add bridge=bridge interface=ether9 pvid=20 comment="TV living room" # … ether10-12: bedroom TVs add bridge=bridge interface=ether13 pvid=10 comment="owner's office" /interface bridge vlan add bridge=bridge vlan-ids=10,20,30,40 tagged=sfp-sfpplus1 add bridge=bridge vlan-ids=99 tagged=bridge,sfp-sfpplus1 /interface vlan add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.70.99.11/24 interface=v99-mgmt /ip route add gateway=10.70.99.1 /interface ethernet poe set ether5,ether6,ether7,ether8,ether9,ether10,ether11,ether12,ether13 poe-out=off /interface ethernet disable ether14,ether15,ether16,ether17,ether18,ether19,ether20,ether21,ether22,ether23,ether24 /interface bridge set bridge vlan-filtering=yes
PoE stays on for the four camera ports only. The TVs are wired on purpose: streaming 4K to four bedrooms over Wi-Fi would use the airtime guests' phones need. The owner's office cable runs to a locked room, so a guest can't plug into it.
/interface bridge vlan print: 40 on ether1–4, 30 on ether5–8, 20 on ether9–12, 10 on ether13, all tagged on sfp-sfpplus1.06 · Step 2 of 10
An RB5009 with PoE on every port: it routes, powers the APs, and runs the Wi-Fi controller.
▲ Show step 2 in the interactive topology · see what this step adds, and click any device for its config
/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="SW-UTIL" add bridge=bridge interface=ether3 pvid=99 comment="cAP ax living (trunk)" add bridge=bridge interface=ether4 pvid=99 comment="cAP ax upstairs (trunk)" add bridge=bridge interface=ether5 pvid=99 comment="pool wAP ax (trunk)" add bridge=bridge interface=ether6 pvid=99 comment="wAP 60G house end (trunk to annex)" /interface bridge vlan add bridge=bridge vlan-ids=10,20,30 tagged=bridge,sfp-sfpplus1,ether3,ether4,ether5,ether6 add bridge=bridge vlan-ids=40 tagged=bridge,sfp-sfpplus1 add bridge=bridge vlan-ids=99 tagged=bridge,sfp-sfpplus1 /interface vlan add name=v10-owner interface=bridge vlan-id=10 add name=v20-guest interface=bridge vlan-id=20 add name=v30-home interface=bridge vlan-id=30 add name=v40-cctv interface=bridge vlan-id=40 add name=v99-mgmt interface=bridge vlan-id=99 /ip address add address=10.70.10.1/24 interface=v10-owner add address=10.70.20.1/24 interface=v20-guest add address=10.70.30.1/24 interface=v30-home add address=10.70.40.1/24 interface=v40-cctv add address=10.70.99.1/24 interface=v99-mgmt # one pool + server + network per VLAN; guests get short leases /ip dhcp-server add name=d-guest interface=v20-guest address-pool=p-guest lease-time=2h /ip dhcp-server network add address=10.70.20.0/24 gateway=10.70.20.1 dns-server=10.70.20.1 # … owner, smart home (reservations), CCTV (reservations), mgmt /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 AP ports are trunks: management untagged on VLAN 99 (so CAPsMAN can find the APs), with VLANs 10, 20 and 30 tagged for the SSIDs. The 60 GHz radio gets the same trunk, because it's carrying the annex AP's traffic. DNS upstream is Quad9, not Cloudflare, because 1.1.1.1 becomes the Starlink probe in step 5.
/interface ethernet poe print on R1: the APs and the 60 GHz radio are powered.07 · Step 3 of 10
Two indoor APs, one at the pool, one in the annex at the far end of a 60 GHz bridge, all managed from R1.
▲ Show step 3 in the interactive topology · see what this step adds, and click any device for its config
# house end /interface w60g set wlan60-1 mode=bridge ssid=villa-annex password="********" frequency=auto disabled=no /interface bridge add name=bridge /interface bridge port add bridge=bridge interface=ether1 /interface bridge port add bridge=bridge interface=wlan60-1 # annex end: same, with mode=station-bridge; its ether1 feeds the annex cAP ax
The 60 GHz radios' bridges don't filter VLANs: they pass the trunk through unchanged, so the annex AP sees exactly what the house APs see. Each radio has a management address in VLAN 99 (a VLAN interface on its bridge), and both show up in the operator's monitoring like any other device.
/interface wifi security add name=sec-guest authentication-types=wpa2-psk,wpa3-psk passphrase="replaced-at-every-checkout" add name=sec-owner authentication-types=wpa2-psk,wpa3-psk passphrase="********" add name=sec-home authentication-types=wpa2-psk passphrase="********" /interface wifi datapath add name=dp-guest bridge=bridge vlan-id=20 add name=dp-owner bridge=bridge vlan-id=10 add name=dp-home bridge=bridge vlan-id=30 /interface wifi configuration add name=cfg-guest ssid=VILLA-Guest security=sec-guest datapath=dp-guest country=Greece add name=cfg-owner ssid=VILLA-Owner security=sec-owner datapath=dp-owner country=Greece hide-ssid=yes add name=cfg-home ssid=VILLA-Home security=sec-home datapath=dp-home country=Greece hide-ssid=yes /interface wifi capsman set enabled=yes interfaces=v99-mgmt /interface wifi provisioning add action=create-dynamic-enabled supported-bands=5ghz-ax master-configuration=cfg-guest slave-configurations=cfg-owner add action=create-dynamic-enabled supported-bands=2ghz-ax master-configuration=cfg-guest slave-configurations=cfg-owner,cfg-home
The smart-home SSID exists only on 2.4 GHz and is WPA2 only, because that's what thermostats, sensors and the gate opener's Wi-Fi modules support. Keeping them off the guest SSID means a booking's key rotation (step 8) never disconnects the pool pump.
/interface wifi registration-table print shows a phone roaming living room → pool → annex./interface w60g monitor wlan60-1: connected, PHY rate in the Gb/s range.08 · Step 4 of 10
Guests reach the internet and the TVs. The owner reaches everything that's theirs. The smart home reaches its clouds and nothing else.
/interface list add name=LAN add name=WAN add name=MGMT /interface list member add list=MGMT interface=v99-mgmt # … every v* interface into LAN /ip firewall address-list add list=TVS address=10.70.20.31-10.70.20.34 /ip firewall filter add chain=input action=accept connection-state=established,related,untracked add chain=input action=drop connection-state=invalid add chain=input action=accept protocol=icmp add chain=input action=accept in-interface-list=MGMT add chain=input action=accept in-interface-list=LAN protocol=udp dst-port=53,67 add chain=input action=accept in-interface-list=LAN protocol=tcp dst-port=53 add chain=input action=drop log=yes log-prefix=IN-DROP add chain=forward action=accept connection-state=established,related,untracked add chain=forward action=drop connection-state=invalid add chain=forward action=accept in-interface=v10-owner out-interface=v30-home comment="owner's smart-home apps" add chain=forward action=accept in-interface=v10-owner out-interface=v40-cctv comment="owner views cameras" add chain=forward action=accept in-interface=v10-owner dst-address-list=TVS comment="owner casts to the TVs" add chain=forward action=accept in-interface=v10-owner out-interface-list=WAN add chain=forward action=accept in-interface=v20-guest out-interface-list=WAN add chain=forward action=accept in-interface=v30-home out-interface-list=WAN add chain=forward action=accept in-interface=v40-cctv out-interface-list=WAN add chain=forward action=accept in-interface-list=MGMT add chain=forward action=drop log=yes log-prefix=FWD-DROP # let the owner's phone discover the TVs across VLANs (RouterOS 7.16+) /ip dns set mdns-repeat-ifaces=v10-owner,v20-guest
Repeating mDNS between the owner and guest VLANs means guests' phones can also see the names of the owner's devices that advertise themselves (a NAS, a printer). They still can't connect, because there's no rule from VLAN 20 to VLAN 10, but the names leak. If that bothers the owner, leave the repeater off and let the owner cast from a device that joins VILLA-Guest during family stays.
09 · Step 5 of 10
The Starlink router steps aside, R1 gets the carrier-NAT address directly, and a DHCP script keeps the failover probe pointed at the right gateway.
▲ Show step 5 in the interactive topology · see what this step adds, and click any device for its config
/interface list member add list=WAN interface=ether1
/ip route
add dst-address=1.1.1.1/32 gateway=100.64.0.1 scope=10 comment="probe via starlink"
add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=1 comment="main: starlink"
add dst-address=192.168.100.1/32 gateway=ether1 comment="dish status page"
/ip dhcp-client add interface=ether1 add-default-route=no use-peer-dns=no comment="Starlink (bypass)" script={
:if ($bound=1) do={
/ip route set [find comment="probe via starlink"] gateway=$"gateway-address"
}
}
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WANIn bypass mode the Starlink router only powers the dish and hands its DHCP lease straight to R1. Starlink's gateway address can change after a reconnect, so the probe route can't be static. The DHCP client's script rewrites it at every lease. That's the same technique as in the Starlink failover post, which covers it in more depth. The extra route to 192.168.100.1 keeps the dish's status page reachable from the owner's and operator's devices, which is the quickest way to see obstruction and outage history remotely.
Starlink residential addresses are in 100.64.0.0/10: carrier-grade NAT, no inbound connections, ever. Nothing in this design needs inbound (step 9 dials out). Starlink also hands out IPv6 prefixes; this post keeps the villa IPv4-only for simplicity. If you add IPv6, remember that every firewall rule above needs an IPv6 twin, or guests on IPv6 bypass the matrix entirely (see IPv6 on RouterOS).
/ip dhcp-client print: bound, 100.64.x.x; /ip route print where comment~"probe" shows the same gateway.10 · Step 6 of 10
When Starlink is out, guests stay online at a slower speed. Cameras and the smart home's clouds wait.
▲ Show step 6 in the interactive topology · see what this step adds, and click any device for its config
! R1 — ISR 1100 with built-in LTE: the LTE interface is its own zone, ! and only the guest and owner zones get a pair to it (cameras and smart home don't) zone security LTE interface Cellular0/2/0 zone-member security LTE zone-pair security ZP-GUEST-LTE source GUEST destination LTE service-policy type inspect PM-OUT zone-pair security ZP-OWNER-LTE source OWNER destination LTE service-policy type inspect PM-OUT ! guests on LTE: police 10 Mb/s in an output policy on Cellular0/2/0
/ip dhcp-client add interface=ether2 default-route-distance=2 use-peer-dns=no comment="4G LtAP (passthrough)" /interface list member add list=WAN interface=ether2 # cameras and smart-home clouds never use 4G /interface list add name=NO4G /interface list member add list=NO4G interface=v30-home add list=NO4G interface=v40-cctv /ip firewall filter add chain=forward action=reject reject-with=icmp-network-unreachable \ in-interface-list=NO4G out-interface=ether2 place-before=0 comment="no camera or IoT uploads on 4G" # guests on 4G: 10 Mb/s down, 3 Mb/s up, shared fairly /ip firewall mangle add chain=forward action=mark-packet new-packet-mark=g4-down in-interface=ether2 out-interface=v20-guest passthrough=no add chain=forward action=mark-packet new-packet-mark=g4-up in-interface=v20-guest out-interface=ether2 passthrough=no /queue tree add name=guest-4g-down parent=global packet-mark=g4-down max-limit=10M queue=pcq-download-default add name=guest-4g-up parent=global packet-mark=g4-up max-limit=3M queue=pcq-upload-default
Unlike the coffee shop, guests aren't cut off on the backup. They paid for a stay with Wi-Fi, and an evening without it is a bad review. They get a fair, slower share; the cameras' continuous cloud uploads, which would eat a 4G plan in a day, are the ones refused. The alarm panel has its own built-in cellular path for alarm calls, so it doesn't depend on this.
11 · Step 7 of 10
One queue per direction that keeps video calls smooth while someone downloads, without anyone tuning classes.
! R1 — no CAKE on IOS: a shaper with fair-queue gives per-FLOW fairness, ! not per-host fairness behind NAT. Set it just under typical evening capacity. policy-map STARLINK-CHILD class class-default fair-queue policy-map STARLINK-OUT class class-default shape average 20000000 service-policy STARLINK-CHILD interface GigabitEthernet0/0/0 service-policy output STARLINK-OUT
/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 add chain=forward action=mark-packet new-packet-mark=from-starlink \
in-interface=ether1 passthrough=no
/queue tree
add name=starlink-up parent=ether1 queue=cake-up max-limit=20M
add name=starlink-down parent=global packet-mark=from-starlink queue=cake-down max-limit=180Mdual-srchost / dual-dsthost make CAKE fair per host first and per flow second. One guest's twenty download streams don't beat another guest's single video call. cake-nat=yes on the upload side is the important flag: by the time a packet reaches ether1 it has been masqueraded to Starlink's address, and NAT mode lets CAKE look up the original inside host anyway. That's the problem the gaming center had to work around with fq-codel. On the download side, the queue sees the inside address already, because un-NAT happens before routing.
CAKE only controls latency if the bottleneck is in R1, which means the max-limit must be below what Starlink delivers. Too high, and the queue builds in Starlink's equipment where CAKE can't manage it. Too low, and you throw capacity away. Look at the Starlink app's speed history for typical evening throughput (the busiest time), and set roughly 85–90% of that. Revisit it at the annual service visit; capacity in an area changes as satellites and users are added. As elsewhere in this series, no FastTrack: fast-tracked packets would skip CAKE.
/queue tree print stats: drops on starlink-down while the download runs.12 · Step 8 of 10
At checkout, the old Wi-Fi key stops working and the manager gets the new one. No one has to remember to do it.
! Cisco has no on-box random key + e-mail. The usual pattern is a small scheduled ! script on the operator's hub that generates the key and pushes one line to the ! wireless controller (over SSH or RESTCONF), then mails the manager: wlan VILLA-Guest 1 VILLA-Guest security wpa akm psk set-key ascii 0 <new-14-character-key> ! changing the key re-keys the WLAN and disconnects the previous guests' devices
/tool e-mail set server=smtp.mail.example port=587 tls=starttls user=villa-r1@mail.example password=********
/system script add name=rotate-guest-psk source={
:local key [:rndstr length=14 from="abcdefghjkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ23456789"]
/interface wifi security set [find name=sec-guest] passphrase=$key
/tool e-mail send to="manager@villa.example" subject="VILLA-Guest key for the next booking" \
body=("Network: VILLA-Guest\nKey: " . $key . "\nPrint it on the welcome card.")
:log warning "guest Wi-Fi key rotated"
}
/system scheduler add name=checkout-rotate start-date=2026-11-07 start-time=11:00:00 interval=7d \
on-event=rotate-guest-pskWeekly Saturday-to-Saturday rentals make the schedule trivial. For bookings with other dates, the manager asks the operator to run the script, or a booking-system webhook triggers it through the management tunnel. The character set leaves out look-alikes (0/O, 1/l/I), so the key can be typed from a printed card. The log line records that the key changed, never the key itself.
Changing the security profile makes CAPsMAN re-provision the APs, and every guest device reconnects with the new key or not at all. That's the point at checkout, but it also means: don't run it while guests are still there, and make sure the TVs are wired (they are), so they don't need the new key typed in every week. The smart-home devices sit on their own SSID with its own key, so the rotation never touches them.
/system script run rotate-guest-psk: a phone on the old key disconnects and can't rejoin; the manager's mailbox has the new key; the log shows "rotated" without the key.13 · Step 9 of 10
The villa calls the operator, not the other way round. Then it reports when Starlink drops.
▲ Show step 9 in the interactive topology · see what this step adds, and click any device for its config
/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.250.0.0/24 persistent-keepalive=25s
/ip address add address=10.250.0.21/24 interface=wg-ops
/interface list member add list=MGMT interface=wg-ops
/system logging action add name=hub target=remote remote=10.250.0.1
/system logging add topics=warning action=hub
/tool netwatch add host=1.1.1.1 interval=30s type=simple \
down-script=":log warning \"Starlink path DOWN\"" up-script=":log warning \"Starlink path UP\""Both of the villa's internet paths are behind carrier NAT, so only an outgoing tunnel works, exactly as in the coffee shop. With the keepalive, the tunnel survives a switch to 4G and reconnects by itself. Warning-level log lines (Starlink up/down, key rotations, firewall drops if you want them) go to the hub, so the operator sees an outage before the guests write about it. For metrics and dashboards across many villas, see observability.
14 · Step 10 of 10
Summer storms cut the power. The network should ride through short cuts and come back by itself after long ones.
| Item | What and why |
|---|---|
| UPS | A 1,000 VA line-interactive UPS carries Starlink (~50–75 W), R1 with its PoE APs, SW-UTIL and the 4G router (~150 W total) for about 45 minutes. Set it to restart loads automatically when power returns. |
| Boot order | No order needed: R1 waits for the DHCP leases, the DHCP script fixes the probe route, the tunnel dials out by itself. Test it by pulling the plug on the whole closet. |
| Surge | Outdoor cables (pool AP, cameras, dish) are the lightning path into the house. Use outdoor-rated cable and surge protectors at the building entry. |
| Config backups | Nightly /export uploaded to the hub over the tunnel with /tool fetch, as in the coffee shop. A replacement RB5009 is one import away. |
| Hardening | Management services only from the MGMT list (VLAN 99 + the tunnel), MAC-Winbox and neighbour discovery limited to MGMT, the default admin account disabled, DHCP snooping on SW-UTIL with the uplink trusted (see hardening). |
15
Run these at handover, write the results in the villa's documentation, and repeat the power and failover drills before every season.
| Drill (requirement) | What must happen |
|---|---|
| Walk the property (R1) | A phone on a video call walks from a bedroom to the pool to the annex without dropping. |
| Guest sweep (R2) | From VILLA-Guest, a scan finds only the gateway and the TVs. The alarm, locks, cameras and owner's office don't answer. |
| Checkout (R3) | The Saturday rotation disconnects the old key and delivers the new one; smart-home devices stay up. |
| Starlink out (R4) | Guests continue on 4G at ≤10 Mb/s; cameras' cloud uploads stop; the hub logs DOWN and UP. |
| Busy evening (R5) | A large download plus a video call: the call stays clear. |
| Remote care (R6) | The operator reaches R1 through the tunnel over Starlink and over 4G. |
| Power cut (R7) | Short cut: nothing drops. Full cut and restore: back online without anyone on site. |
| Privacy (R8) | No camera covers an indoor or bathroom area; the camera VLAN is unreachable from guests. |
16
What the network can't do on its own, and what covers each gap.
17
The routing, failover, queues and scripts run on CHR. Starlink, radios and PoE don't.
| This post | In the lab |
|---|---|
| R1 | A CHR with two WAN interfaces fed by two "ISP" CHRs that hand out 100.64.x addresses by DHCP. Change the gateway on the first ISP to test the DHCP script. |
| SW-UTIL, 60 GHz bridge | CHR bridges; a plain virtual link stands in for the 60 GHz pair. |
| Key rotation | Point /tool e-mail at a test SMTP server (MailHog or similar) and check what arrives. |
| Wi-Fi | Skip it, or tag VMs into VLANs 10, 20 and 30. |
18
Indicative EU street prices, late 2026, excluding VAT. Starlink hardware and subscription are separate.
| Item | Indicative (EUR, ex VAT) |
|---|---|
| R1 · RB5009UPr+S+IN (PoE out) | 260 – 320 |
| SW-UTIL · CRS328-24P-4S+ + DAC | 440 – 560 |
| 2× cAP ax (house) + 1× cAP ax (annex) | 300 – 380 |
| wAP ax (pool, outdoor) | 130 – 160 |
| 2× wAP 60G (annex bridge) | 180 – 260 |
| 4G backup · LtAP-class LTE router | 120 – 200, plus a data SIM |
| UPS 1,000 VA + outdoor surge protection | 250 – 400 |
| Network total | ≈ 1,700 – 2,300, plus cabling and the Starlink kit |
Appendix
Same villa and VLANs on Cisco's small-branch line. The Cisco tabs on the config blocks above show where it differs; this appendix covers the rest.
| Role | This post → Cisco |
|---|---|
| R1 + 4G | RB5009UPr + LtAP → ISR 1100 with built-in LTE |
| SW-UTIL (PoE) | CRS328-24P-4S+ → Catalyst 1000-24FP |
| Wi-Fi | cAP ax / wAP ax + CAPsMAN → Catalyst indoor and outdoor APs with the embedded controller |
| Annex link | wAP 60G pair → a third-party 60 GHz bridge, or Cisco industrial wireless backhaul |
| Indicative total | ≈ 1,700 – 2,300 → ≈ 6,000 – 9,000 EUR ex VAT |
| Feature | This post → Cisco |
|---|---|
| Starlink failover | DHCP-client script + recursive routes → ip address dhcp, IP SLA + track |
| Backup only for some zones | NO4G reject rule → LTE in its own zone with pairs for guests and owner only |
| Fair sharing | CAKE (per host, NAT-aware) → fair-queue under a shaper (per flow) |
| Per-booking key | on-box :rndstr + e-mail → script on the operator's hub pushing the key to the controller |
| Remote management | WireGuard dial-out → FlexVPN client to the hub |
| mDNS for casting | mdns-repeat-ifaces → Service Discovery Gateway |
Two things get worse on Cisco here. There is no CAKE, so fairness is per flow rather than per host, and one guest with many downloads can still crowd out a video call. And the per-booking key needs an off-box script, because the router can't generate and send it by itself. One thing gets simpler: the ISR has LTE built in.
For a single villa, MikroTik is the better fit. Cisco makes sense when a rental company already runs Cisco across many properties.
Takeaways
This is part 6 of the Build series. Earlier: the law firm, the gaming center, the coffee shop, the supermarket, the medical clinic. Next: the festival.
I install Starlink and build villa networks like this one across Crete: Wi-Fi that reaches the pool and the annex, guest keys that change by themselves, and remote care so problems get fixed before your guests notice.
Starlink installation in Crete →