Walled Garden

Walled Garden

The walled garden allows unauthenticated HotSpot clients to reach specific destinations without logging in. Typical uses include allowing access to the login page assets, payment gateways, social login providers, and OS captive portal detection endpoints.

RouterOS provides two independent walled garden rule sets:

Rule Set	Path	Layer	Use Case
HTTP walled garden	/ip hotspot walled-garden	L7 (HTTP inspection)	Plain HTTP sites, by hostname and path
IP walled garden	/ip hotspot walled-garden ip	L3/L4 (IP/protocol/port)	HTTPS sites, DNS servers, any protocol

HTTP Walled Garden

The HTTP walled garden inspects plain HTTP requests and can match by hostname, URL path, HTTP method, and source address. It only applies to unencrypted HTTP traffic (port 80).

Parameters

Parameter	Description	Default
action	allow or deny traffic matching this rule	allow
comment	Descriptive label	—
dst-host	Destination hostname to match; supports wildcards (*.example.com)	—
dst-port	Destination TCP port	—
method	HTTP method to match (GET, POST, etc.)	— (any)
path	URL path prefix to match	—
server	Limit rule to a specific HotSpot server name	— (all)
src-address	Source IP address or subnet	—

Rules are evaluated top-to-bottom; the first matching rule applies. Rules without a matching criterion apply to all traffic.

Basic Examples

# Allow entire domain
/ip hotspot walled-garden
add dst-host=*.example.com action=allow comment="Company site"

# Allow a specific domain
/ip hotspot walled-garden
add dst-host=payment.stripe.com action=allow comment="Stripe payment"

# Allow a CDN path used by the login page
/ip hotspot walled-garden
add dst-host=cdnjs.cloudflare.com path=/ajax/libs/jquery/* action=allow

# Deny access to a competitor site even before login
/ip hotspot walled-garden
add dst-host=*.competitor.com action=deny comment="Block competitor"

Wildcard Matching

The dst-host field uses glob-style wildcards:

• *.example.com — matches any subdomain of example.com (e.g., www.example.com, cdn.example.com)
• example.com — matches only example.com (not subdomains)
• * — matches all hostnames

Note

HTTP walled garden rules only apply to plain HTTP (port 80). Any HTTPS destination that must be reachable before login requires an IP walled garden rule.

IP Walled Garden

The IP walled garden operates at L3/L4, passing or blocking traffic based on IP address, protocol, and port. It applies to all traffic — including HTTPS — making it the only option for HTTPS destinations.

Parameters

Parameter	Description	Default
action	accept or drop	accept
comment	Descriptive label	—
dst-address	Destination IP address or subnet	—
dst-port	Destination port or range	—
protocol	IP protocol (tcp, udp, icmp, etc.)	— (any)
server	Limit rule to a specific HotSpot server name	— (all)
src-address	Source IP address or subnet	—
src-port	Source port or range	—

Basic Examples

# Allow specific IP for HTTPS (e.g., payment gateway)
/ip hotspot walled-garden ip
add dst-address=203.0.113.50 action=accept comment="Payment gateway"

# Allow DNS to a specific server before login
/ip hotspot walled-garden ip
add dst-address=1.1.1.1 protocol=udp dst-port=53 action=accept comment="Cloudflare DNS"

# Allow all traffic to a subnet (e.g., local NAS for onboarding)
/ip hotspot walled-garden ip
add dst-address=192.168.10.0/24 action=accept comment="Onboarding resources"

# Allow ICMP (ping) to the router gateway
/ip hotspot walled-garden ip
add dst-address=10.5.50.1 protocol=icmp action=accept comment="Ping gateway"

HTTPS Destinations Before Login

HotSpot cannot inspect or redirect HTTPS traffic transparently. When an unauthenticated client visits an HTTPS URL, the router cannot intercept the TLS handshake — the connection either fails or bypasses the portal entirely.

To allow HTTPS destinations pre-login, you must:

1. Resolve the destination IP addresses.
2. Add those IPs to the IP walled garden.

# Step 1: resolve IPs for the destination (example: stripe.com)
# Do this from a workstation: dig +short stripe.com

# Step 2: add all returned IPs
/ip hotspot walled-garden ip
add dst-address=54.187.174.169 action=accept comment="stripe.com"
add dst-address=54.241.191.232 action=accept comment="stripe.com"

Caution

HTTPS destinations with CDN-backed IPs change frequently. Static IP entries may break when the CDN updates its IP pool. For payment gateways that provide a dedicated IP range, use that range rather than resolved addresses.

OS Captive Portal Detection

Modern operating systems send HTTP probes to known URLs to detect captive portals. If these probes succeed (return expected responses), the OS concludes there is no portal and suppresses the captive portal browser. If they fail or redirect, the OS pops up the mini-browser.

RouterOS HotSpot intercepts these HTTP probes and redirects them to the login page, which causes the OS to detect the portal correctly. However, the OS-specific URLs must be reachable via HTTP (not HTTPS) to work. Ensure no firewall rules block them before HotSpot processes them.

Platform-Specific Endpoints

OS	Domain	Notes
iOS / macOS	captive.apple.com	Apple uses HTTPS for newer checks; the HTTP probe is http://captive.apple.com/hotspot-detect.html
Android	connectivitycheck.gstatic.com	Also clients3.google.com, connectivitycheck.android.com
Windows	www.msftncsi.com, dns.msftncsi.com	NCSI test fetches http://www.msftncsi.com/ncsi.txt
Windows 10+	www.msftconnecttest.com	Fetches /connecttest.txt expecting Microsoft Connect Test

These domains are automatically intercepted by HotSpot’s HTTP redirect engine. No additional walled garden rules are needed for the HTTP probes themselves — the HotSpot login redirect counts as a valid captive portal response.

For iOS and Android, if you want the captive portal mini-browser to open immediately, ensure your login page responds quickly at the redirected URL.

Common Walled Garden Patterns

Payment Gateway Access

Allow traffic to a payment provider before login (required for voucher-based portals):

# HTTP rules for payment provider
/ip hotspot walled-garden
add dst-host=checkout.stripe.com action=allow comment="Stripe checkout"
add dst-host=js.stripe.com action=allow comment="Stripe JS"

# IP rules for HTTPS (resolve stripe.com IPs first)
/ip hotspot walled-garden ip
add dst-address=54.187.174.169 action=accept comment="Stripe IP 1"
add dst-address=54.241.191.232 action=accept comment="Stripe IP 2"

Social Login (e.g., Facebook, Google)

# HTTP walled garden for OAuth endpoints
/ip hotspot walled-garden
add dst-host=*.facebook.com action=allow comment="Facebook login"
add dst-host=*.fbcdn.net action=allow comment="Facebook CDN"
add dst-host=accounts.google.com action=allow comment="Google login"
add dst-host=*.googleapis.com action=allow comment="Google APIs"

Note

Social login over HTTPS still requires IP walled garden entries for the OAuth provider’s IPs.

Windows Activation and Update

/ip hotspot walled-garden
add dst-host=*.microsoft.com action=allow comment="Microsoft services"
add dst-host=*.windowsupdate.com action=allow comment="Windows Update"
add dst-host=*.msftncsi.com action=allow comment="Windows NCSI"

DNS Pre-Authentication

Allow DNS queries before login so clients can resolve the login page hostname:

/ip hotspot walled-garden ip
add dst-address=10.5.50.1 protocol=udp dst-port=53 action=accept \
    comment="DNS to gateway (login page resolution)"
add dst-address=1.1.1.1 protocol=udp dst-port=53 action=accept \
    comment="Cloudflare DNS fallback"

Per-Server Rules

When running multiple HotSpot servers, scope rules to a specific server using the server parameter:

/ip hotspot walled-garden
add dst-host=*.hotel-partners.com action=allow server=hs-lobby \
    comment="Hotel partner sites (lobby only)"

/ip hotspot walled-garden ip
add dst-address=192.0.2.100 action=accept server=hs-conference \
    comment="Conference AV system"

Dynamic Walled Garden via RADIUS

RADIUS can push per-session walled garden entries using MikroTik vendor-specific attributes (VSAs). This allows different users to have different walled garden rules without static configuration.

RADIUS Attribute	Format	Description
Mikrotik-Walled-Garden-Fqdn	hostname	Domain to allow (HTTP walled garden)
Mikrotik-Walled-Garden	action:src-addr:dst-addr:proto:src-port:dst-port	IP walled garden rule

Example FreeRADIUS user definition:

premium-user Cleartext-Password := "secret"
    Mikrotik-Walled-Garden-Fqdn := "*.streaming.example.com",
    Mikrotik-Walled-Garden := "accept:0.0.0.0/0:192.0.2.0/24:6:0:443"

Troubleshooting

Walled garden rule not working for HTTPS

• HTTP walled garden rules cannot match HTTPS traffic. Add equivalent IP walled garden rules for HTTPS destinations.

Login page assets not loading

• If the login page references external CSS/JS (e.g., from a CDN), add those CDN hostnames to the HTTP walled garden.

OS shows “no internet” but portal exists

• The OS captive portal probe was blocked before HotSpot could intercept it. Check for firewall rules running before HotSpot’s redirect that might be dropping traffic.

HTTPS site unreachable before login despite IP rule

• Verify the destination IP is correct and hasn’t changed (CDNs rotate IPs). Re-resolve and update the entry.
• Confirm action=accept (not action=allow — IP walled garden uses accept/drop).

View active walled garden rules

# HTTP rules
/ip hotspot walled-garden print

# IP rules
/ip hotspot walled-garden ip print

# Active sessions with walled garden bypass
/ip hotspot host print where bypassed=yes

Related Documentation

• HotSpot Overview — Complete HotSpot setup guide
• User Profiles — Session limits and bandwidth policies
• Firewall Filter — Firewall rules that interact with HotSpot