Skip to main content

Search

Cloudi-Fi Knowledge Base

Location Management

Mahfoud
  • Updated

In Cloudi-Fi, a location serves as a central concept to logically or physically separate network environments and apply specific captive portal, terms of service, and access control policies. Whether it’s a retail store, a corporate office, a guest Wi-Fi segment, or an IoT subnet, each location acts as a policy anchor that defines how user traffic is identified, redirected, and secured.

Locations allow Cloudi-Fi to:

  • Map and track traffic origin to align with local regulations

  • Apply tailored captive portal experiences

  • Enable analytics and monitoring by place or region

This documentation explains what a location is, how to create one, the supported types, integration-specific constraints, and the detailed format validation rules for each field.

1. Overview: What is a Location in Cloudi-Fi?

In Cloudi-Fi, a location is a logical or physical representation of a network zone, used to apply specific captive portal and access control policies. Locations define how and where traffic originates, enabling precise management, segmentation, and user experience customization.

A location can be:

  • A physical branch, store, or department, such as a Meraki network or a group of APs

  • A logical subnet in segmented networks (e.g., based on service type, VLANs, or internal zones)

  • A traffic identifier for integration with secure web gateways (e.g., via IPsec, GRE, or FQDN)

  • A virtual site, where traffic from multiple sub-sites is aggregated under one tunnel but differentiated by private IP ranges (e.g., MPLS-based multi-site WANs)

By configuring locations, organizations can:

  • Assign custom captive portals per site or department

  • Segment traffic for analytics or policy enforcement

  • Map sub-sites within VPN or SD-WAN topologies

  • Integrate seamlessly with cloud-based security services

Each location type serves a different deployment scenario—whether using redirect URLs, IP-based tunneling, or IP segmentation—ensuring flexibility across cloud-native, hybrid, and legacy network architectures.

2. How to Create a Location in Cloudi-Fi

  • Log in to the Cloudi-Fi Admin console.

  • Navigate to Locations.

  • Click "Add Location".

  • Set Name

  • Select a location type:

    • Redirect URL

    • GRE (Zscaler only)

    • IPsec IP-Based (Zscaler only)

    • FQDN (Zscaler only)

    • Virtual Location (Zscaler only)

  • Select Country
  • Select Timezone
  • Select Portal or set default
  • Select Terms and policies or set default

Cloudi-Fi UI create new location.png

  • Enter the required field(s) based on the selected location type.

  • Save

Cloudi-Fi select location identifier.png

3. Location Types & Constraints

Note: The following location types are valid only for Zscaler-based integrations:

  • GRE

  • IPsec IP-Based

  • FQDN

  • Virtual Location

Network Parameters Explained:

  • Hash Key: An auto-generated unique identifier used primarily in Redirect URL scenarios where no other identifier is specified.

  • IP Address: Public IP address of the gateway — used in Redirect URL, IPsec IP-Based, and GRE configurations.

  • MAC Address: Physical address of the access point device or firewall — mostly used in Redirect URL-based identification.

  • Vendor ID: Identifier string based on equipment type or traffic source — applicable to Redirect URL configurations.

  • FQDN: Fully Qualified Domain Name used to distinguish locations in FQDN-based Zscaler integrations.

1. Redirect URL

  • Required Fields: Optional input (Hash Key, IP Address, MAC Address, or Vendor ID)

  • Constraints:

    • Must specify only one identifier.

    • If provided, the value must be unique.

    • If left blank, a unique hash key is auto-generated.

  • Use Case: Used in redirection-based captive portal deployments (e.g., Cisco WLC, Aruba, Cisco Meraki, FortiGate).

2. GRE (Generic Routing Encapsulation) (Zscaler only)

  • Required Fields: GRE tunnel definition

  • Constraints:

    • Must include one valid GRE tunnel (source & destination IP).

    • Tunnel must be unique.

    • Use Case: Used in a Zscaler deployment

3. IPsec IP-Based (Zscaler only)

 

  • Required Fields: One valid IPv4 address

  • Constraints:

    • Must be a valid and unique IPv4 address.

  • Use Case: For IPsec VPN-based traffic transport in a Zscaler integration.

  • Example: Retail branch office connects via IPsec to secure guest traffic.

4. FQDN (Fully Qualified Domain Name) (Zscaler only)

  • Required Fields: Optional (FQDN)

  • Constraints:

    • If provided, the FQDN must be unique.

    • If not, Cloudi-Fi generates one automatically (e.g., store1@company.cloudi-fi.net).

  • Use Case: Ideal for SD-WAN or cloud-native setups with Zscaler integration

5. Virtual Location (Zscaler only)

  • Required Fields: Private IP range

  • Constraints:

    • Must be within private IP ranges (RFC 1918):

      • 10.0.0.0/8

      • 172.16.0.0/12

      • 192.168.0.0/16

    • Must be unique.

  • Use Case: Used when no tunnel or redirect is in place. Helps identify traffic by source IP.

  • Example: A factory floor uses different private subnets to split production zones.