Policies

Policies decide which peers can talk to each other. A peer reaches another peer, or a network behind a routing peer, only when an enabled policy allows it. Each policy names source and destination groups, the protocol and ports, and optionally the routed networks and the posture checks the source device must pass.

You manage policies under Network > Policies. Owners and admins see the page; regular users see You don't have access to Policies.

How it works

• A policy holds one or more rules and optional posture checks. A rule allows traffic from Source groups to Destination groups for a protocol, optionally limited to ports and to routed networks.
• Rules only allow. There is no deny rule and no order of evaluation: what is allowed is the sum of all enabled rules. Everything else is dropped.
• A new account has one policy, Default: All to All, protocol ALL, both directions. While Default is enabled every peer reaches every peer on every port, so a restrictive policy has no visible effect until you disable or delete Default.
• The peer that opens a connection checks its rules; the receiving peer accepts the traffic over the tunnel. After a change, peers receive the new rules within about 30 seconds. Run netzilo refresh on a device to fetch them at once.
• Every allowed and every blocked connection attempt is recorded under Activity > Events: peer.access.granted names the policy that allowed it, peer.access.blocked names the posture check that failed and why.

Groups

Policies work on groups, not on single peers. A group is a set of peers, much like a tag.

• A peer can be in several groups. The group All contains every peer and cannot be changed or deleted.
• You create a group wherever the dashboard asks for groups: type a new name in the group selector and press Enter. The group is created when you save.
• Peers get into groups in four ways: by hand on the peer's page, through the auto-assigned groups of the setup key they enrolled with (see Auto-assigned groups), through the user's auto-assigned groups, or from your identity provider's group claims.
• You see where each group is used, and delete groups that nothing uses, under Settings > Groups. See Groups.

Create a policy

Go to Network > Policies and click Add Policy. The dialog has three tabs: Policy, Posture Checks and Name & Description. Click Continue to move from one tab to the next.

Policy tab: the rules

Each rule is a section whose header sums it up, for example ALLOW TCP, Developers to Connectors, Ports: 5432, Routes: 10.20.5.0/24. Click the header to open or close the rule.

Click Add Rule to add another rule to the same policy. The ⋮ menu of a rule has Duplicate, Move Up, Move Down and Delete. Moving rules only changes the order you see; it does not change what is allowed.

Continue stays disabled until every rule has a source, a destination and, for a one-way TCP or UDP rule, a port.

Posture Checks tab

Posture checks gate the source peer of every rule in the policy. A device that fails them gets none of the policy's rules, and the attempt is logged as peer.access.blocked with the reason.

Click Browse Checks to attach existing checks, or New Posture Check to create one. With at least one check attached, Posture Check Evaluation appears: All (the default) means every check must pass, Any means one passing check is enough. How to build checks is in Posture Checks.

Name & Description tab

Enter a Name of the Rule, which is the policy's name, and an optional description. Click Add Policy to save.

Edit rules as JSON

The </> button at the top right of the Policy tab switches to Policy Rules (JSON Format). Use it to copy rules between policies or to edit many rules at once. Each rule is an object with protocol, sources, direction (IN, OUT or BOTH), destinations, and optionally ports and routes. The eye button switches back to the visual editor.

The IN and OUT labels in JSON are the reverse of the arrows in the visual editor. After a bulk edit of one-way rules, switch back to the visual editor and check the arrows, then test the connection.

The editor refuses invalid input with messages such as JSON must be an array of rule objects, Rules must have both sources and destinations and TCP/UDP unidirectional rules must specify ports.

Restrict what a routed network exposes

A route publishes a whole network, for example 10.20.0.0/16, through a routing peer. To let a group reach only part of it:

1. On the route, put a group in Policy Groups (Optional), see Routes.
2. In a policy rule, set that group or the routing peers' group as Destination, the protocol and ports the users need, and the subnet in Routes, for example 10.20.5.0/24.

The users then reach only that subnet on those ports, although the route publishes the whole network.

Add peers to groups

A new group has no peers. To add a peer, go to Endpoint > Peers, open the peer, and pick the groups under Assigned Groups. Click Save Changes.

For servers, set the groups on the setup key instead, so every peer enrolled with it lands in the right group. See Setup Keys.

Move from Default to least privilege

1. Look at who reaches what today: filter Activity > Events for peer.access.granted.
2. Create groups per role and per resource, for example developers and dc-routers.
3. Create the specific policies. They change nothing while Default is enabled.
4. In a quiet hour, switch Default off with its Active switch. Watch peer.access.blocked events and user reports for a day. Switch Default on again to roll back.
5. Delete Default once everything works.

Update, disable or delete a policy

• Update: click the policy's name. The dialog opens with all three tabs; change anything and click Save Changes.
• Disable: use the switch in the Active column. A disabled policy keeps its rules but applies none of them.
• Delete: click Delete on the policy's row and confirm.

Above the table, filter by All, Active or Inactive, by source and by destination group, or search by policy, rule, group, port or route.

A policy for browser users only

Users of Clientless Access reach resources through the Netzilo gateway from a browser. To write a policy that admits only those browser sessions, attach a posture check whose only item is Netzilo Gateway. Gateway sessions pass it; devices with the Netzilo client fail it. Keep endpoint items and operating system minimums out of that check.

Troubleshooting

A new policy has no effect. The Default policy is still enabled and allows everything. Disable it.

Peer A cannot reach peer B. Check, in this order:

• Both peers are in the groups you expect: open each peer under Endpoint > Peers.
• An enabled rule has A's group as source and B's group as destination, or the reverse with both arrows on.
• The protocol and ports match. Ping works but the port does not means the rule allows ICMP and not the port, or the other way round.
• The policy's posture checks pass for A. Search Activity > Events for peer.access.blocked and A's name; the event names the failing check.
• A has the new rules: netzilo status -d on A lists B. If not, run netzilo refresh.
• For a routed destination, the route works and the rule's Routes field does not exclude the target. See Routes.

A peer reaches something it should not. Search Activity > Events for peer.access.granted for the two peers. The event names the policy that allowed it. Look for rules with All, duplicate policies, and rules with both arrows that were meant to be one way.

A one-way rule blocks the wrong side. The arrow points from the side that opens the connection. Point it from the consumer to the server.

A group cannot be deleted. A policy, route, DNS server or other object still uses it. Settings > Groups shows where.

Related Documentation

• Posture Checks - Device requirements for a policy's sources
• Routes - Reach networks behind routing peers
• Peers - Assign groups to peers
• Setup Keys - Auto-assign groups at enrollment
• Groups - Where each group is used
• Events - Granted and blocked connections