Overview of Network Policies
How to apply network policies to authentication systems, captive portals, and Sputnik-powered devices to create walled gardens, block unwanted sites, apply content filtering, and enable port forwarding.
Four basic network policies.
SputnikNet provides four basic network policies:
- Allow/Accept: enable traffic to defined network destinations, often used for walled gardens
- Deny/Reject: disable traffic to defined network destinations, used to block unwanted sites
- Destination NAT: re-routes specified network traffic to a different network destination, used for content filtering
- Port Forward: (sometimes referred to as tunneling) forwards a network port from one network node to another, often used to allow an external user to reach a port on a private IP address (inside a LAN) from the outside, for example to access a web-based control panel on a device on a private network
Creating walled gardens with allow/accept rules.
Walled garden policies (based on allow rules) are an example of policies that applied to captive portals, which are then applied to Sputnik-powered devices. Walled garden policies take effect before a user authenticates.
Blocking private nets with deny/reject rules.
Block private network policies (based on deny rules) are an example of policies that are applied to authentication systems, which are then applied to captive portals, and then to Sputnik-powered devices. Block private network policies take effect after a user authenticates.
Content filtering with destination NAT rules.
Content filtering policies (based on destination NAT rules) are an example of policies that are applied to authentication systems, which are then applied to captive portals, and then to Sputnik-powered devices. Content filtering policies take effect after a user authenticates.
Accessing a private network device from outside via port forwarding rules.
To access a webcam's built-in control panel from outside of the private network it is on, for example, apply port forwarding policies to an authentication system; then apply the authentication system directly to the local Sputnik-powered device that the webcam connects through as an override.
Network policy chain.
Here's another way to look at how network policies ultimately apply to authenticated users:
- One or more policies are applied to user groups.
- Groups are part of authentication systems, which by default have an "all" group. The user authentication system alone can have multiple groups.
- Authentication systems are applied to captive portals.
- Captive portals are applied to Sputnik-powered devices.
- A user connects to a Sputnik-powered device through a captive portal using an authentication system that assigns them to one or more groups with defined network policies. (Yes, it reminds us of the "House that Jack Built".)
The authentication system and captive portal "links" can be skipped, as noted above. But generally, this chain of relationships applies in SputnikNet.
Policy order.
In general it is a good idea to limit the number of network policies; things can quickly become unmanageably complex. The above example is for illustrative purposes only.
Also, except in cases like walled gardens and port forwarding, we recommend that you apply policies at the highest level of abstraction - i.e. at the authentication system level. Here is the order in which network policies are applied to a user.
- Device override policies (inherited from a Sputnik-powered device/router) are applied before captive portal and before authentication
- Captive portal walled garden rules apply before authentication
- Authentication rules apply after a user logs in
Generally, policies are applied in the order they are added to the device, captive portal, or authentication system. To establish this sequence, click on the checkbox next to the first policy, click "Update", then repeat for additional policies in order. The built-in "Block Private Nets" policy is always applied last.
Authentication system policies are applied in this order:
- First, the "all" group policies
- Then network policies in order applied to the group, but
- "Block Private Nets" is always applied last.
In the special case of the user authentication system, policies are applied to users who are members of multiple groups in this order:
- First, the "all" group policies in order applied to the group,
- Then additional groups and their network policies in order applied, but
- "Block Private Nets" is always applied last.