Integrating Nile Zero Trust Fabric with Upstream Routers & Firewalls

Transcript:

  1. Overview & Architecture

Welcome. This session covers how the zero trust fabric integrates with your upstream router or firewall. We'll go through the reference topology, activating the ZTF gateways with the Nile mobile app, the addressing the ZTF needs, how routes are advertised to your network, and the ports and protocols your firewall must allow. By the end, you'll understand what you need to prepare before a Nile deployment, and what Nile handles automatically.

The Zero Trust Fabric or ZTF can connect to the Nile cloud in two ways: through an upstream router or firewall, or directly over a WAN circuit using the Nile edge service. In both cases, the connection point is the ZTF gateway. That's the Nile access or distribution switch at the layer 3 boundary between the ZTF and the outside network.

In a router or firewall integration, four points define the design:

  • Active-Active Pair: First, ZTF gateways are deployed in pairs and run active active. Both carry traffic at the same time, so there's no idle standby link.

  • Default Gateway: Second, the ZTF gateway is the default gateway for all Nile elements, access switches, access points, and sensors.

  • OSPF Integration: Third, OSPF is the preferred routing protocol, and it needs no configuration on the ZTF. The gateway listens for OSPF hello messages from your router or firewall and learns the parameters it needs from them including area timers and authentication. You configure OSPF on your side and the ZTF adapts to it.

  • Static Routing & ECMP: Fourth, if OSPF isn't used, the ZTF gateway uses static routes with equal-cost multi-path or ECMP to spread traffic across both uplinks. Once the gateway has learned its routes, it starts forwarding traffic.

2. Nile Edge Service Option

The second option is the Nile Edge service, an add-on to the Nile access service that runs on the same Nile hardware. With Nile Edge service, the ZTF gateway plugs directly into a WAN circuit such as Comcast, AT&T, or any other dedicated internet access provider.

The WAN address can be a static IP or one assigned by the ISP over DHCP. In this design, the gateway performs NAT and firewalling, load balances traffic across multiple WAN circuits, and builds IPSec tunnels to the customer's data center. The rest of this session focuses on integrating with a customer-owned router or firewall.

3. ZTF Gateway Activation & Physical Provisioning

ZTF gateways are activated with the Nile mobile app, not through a serial console or a management port. The Nile design process is fully automated. Every Nile element destined for a site already has a host name assigned and activation binds a physical factory shipped device to that host name.

In this example, the installer selects mous.as.2, one of the two access switches that will become ZTF gateways. With the device selected, the installer taps activate. This designates the access switch as a ZTF gateway. It will now accept the uplink and subnet parameters that bring the rest of the network online.

The app then opens the camera to identify the physical device. Every Nile switch access point and sensor has a unique QR code printed on the chassis. The installer points the camera at the QR code on the switch. When the scan completes, the app links the serial number of that switch to its planned host name. The installer never types a serial number or MAC address, which removes a common source of deployment errors.

4. Network Addressing & Parameters

Next, the installer enters the parameters the ZTF gateway needs to bring up the rest of the network.

  1. Uplink IP Addresses: Each uplink is a point-to-point layer 3 link to the router or firewall using a /30 subnet. In this example, the uplink on interface 48 uses 172.16.0.6/30 with the router site at 172.16.0.5 as its default gateway. The uplink on interface 47 uses 172.16.0.14/30 with the second router at 172.16.0.13 as its default gateway. A single uplink is supported but two are recommended for redundancy. The same steps are then repeated for the second gateway (as.1).

  2. ZTF Subnet: The second parameter is the ZTF subnet, here 172.16.1.0/24. The ZTF gateway uses this subnet to assign IP addresses to the Nile infrastructure, access switches, and access points. Size it for the full buildout of the site, not only day one device counts.

  3. Sensor Subnet: The third parameter is the sensor subnet, here 172.16.2.0/24. Nile sensors are active monitoring devices that behave like end clients on the network. So they get their own subnet separate from the infrastructure.

With the uplinks ZTF subnet and sensor subnet defined, the app sends the configuration to the ZTF gateway over Bluetooth. The switch doesn't need network connectivity to receive its initial configuration.

5. Bringing the Infrastructure Online

Once both ZTF gateways are active, the rest of the network is simple to bring up. Every other access switch, access point, and sensor is activated only by scanning its QR code. They need no further configuration.

  • Internal DHCP: First, the ZTF gateway runs a DHCP server for the ZTF and sensor subnets (172.16.1.0/24 and 172.16.2.0/24). This DHCP service is internal to Nile infrastructure. It doesn't serve enduser devices. For end users, you can use the Nile DHCP service or your own DHCP servers.

  • Default Routing: Second, every Nile element gets an address from this pool and uses the ZTF gateway as its default gateway to reach the Nile cloud.

  • Route Advertisement: Third, the ZTF gateway advertises both subnets to your router or firewall over OPF, so your network learns the return path automatically.

The process is the same at any scale. Two switches with 10 access points or 100 switches with a thousand access points need the same effort. Only the two ZTF gateways are provisioned via the mobile app.

6. Segment Management & Policy Enforcement Models

With the infrastructure online, the administrator manages the network from the Nile portal. Segmentation, authentication methods, and subnet assignments are all defined there.

In this example, there are four segments:

  • Employee: 10.1.1.0/24

  • Guest: 10.2.2.0/24

  • Printer: 10.3.0.0/24

  • Camera: 10.4.4.0/24

The integration flow operates as follows:

  1. The administrator sets the ZTF as the default gateway for each segment in the Nile portal.

  2. All wired and wireless device traffic is tunnneled to the headend within the ZTF.

  3. The ZTF gateway advertises the four segment subnets to the upstream router or firewall over OPF.

  4. The ZTF routes this traffic to the upstream firewall or router.

You choose where security policy is enforced. There are three models:

  • Model 1 (Nile Only): The Nile Trust engine handles all firewalling both east west between devices inside the ZTF and north south to and from the outside network. No additional firewall hardware is needed.

  • Model 2 (Upstream Firewall Only): Your upstream firewall handles all east, west, and north south traffic. Every flow, including traffic between devices inside the ZTF, is sent to the firewall, so policy stays with your existing security stack.

  • Model 3 (Hybrid Enforcement): You divide enforcement between the Nile trust engine and your firewall however you need (e.g., by segment, by traffic direction, or by application).

7. Routing Table Validation & Firewall Requirements

This is a sample routing table from the customer's router showing the result of this integration. The entries marked with the O and i flag are OPF intra area routes learned from the ZTF gateway through its point-to-point uplinks. You see the ZTF subnets alongside the directly connected and static routes. The router learned them dynamically with no static routes configured on either side. Use this output as a reference when you validate a deployment. If the Nile subnets don't appear as OPF routes, check the OPF agency on the uplink interfaces first.

To activate and be managed, the ZTF must reach the Nile cloud. All of these rules are outbound only. The ZTF starts every connection from inside your network. So no inbound ports or protocols have to be opened on your firewall.

The firewall must allow three outbound services:

  1. Outbound HTTPS (TCP 443): To the Nile cloud. The destination URLs vary by region and static IP addresses are available on request if your policy needs IP based rules.

  2. Outbound DNS (UDP 53): To resolve the Nile cloud URLs. The defaults are 8.8.8.8 and 8.8.4.4.

  3. Outbound NTP (UDP 123): For time synchronization across all Nile elements. The defaults are time.google.com and pool.ntp.org.

You can point DNS and NTP at your own servers. Keep in mind that these rules cover ZTF activation and management only. Enduser traffic may need more protocols such as radius for authentication or DHCP relay to your own servers depending on how your segments are designed.

8. Summary

To summarize, the ZTF connects to your router or firewall through a pair of active active ZTF gateways. Routes are exchanged over OPF with no configuration on the Nile side or through static routes with ECMP. Activation is done once on two gateways with the Nile mobile app. Every other element is added by scanning its QR code.

Policy can be enforced by your firewall, by the Nile trust engine, or by both together. Only three outbound services need to be allowed for the ZTF to reach the Nile cloud and no inbound ports need to be opened. With Nile edge service, the same gateways can also connect directly to your WAN circuits. Keep this reference topology and checklist handy as you plan your deployment.

Thank you for watching.