Packet Filters

The packet filters view presents the scaffolds that configure settings to modify the rXg per-packet filtering engine.

The packet filtering is most often configured to deny certain end-users and/or devices access to certain kinds of applications. For example, some revenue generating network operators choose to deny access to P2P file sharing applications in order to conserve bandwidth. The rXg application filters scaffold is used to accomplish this.

Selection of end-users and/or devices is accomplished by associating a policy and applications are selected by associating application definitions to an application filter record. Since account group membership is usually determined by end-user self-provisioning via the captive portal web application, it is possible to enforce different application filters based on the usage plan selected by the end-user (and hence, revenue generated). This enables revenue generating network operators to limit access to certain applications (e.g., P2P file sharing and VoIP) to plans that are premium offerings.

Application Filters

An entry in the application filters scaffold creates a firewall rule that prohibits a particular application from reaching and/or being reached by specified WAN targets

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

Rules for a given policy are checked in a top-down order, and the LAST rule to match a packet is the one which will be applied. Care should be given to order the rules appropriately to achieve the desired behavior and avoid being overly restrictive or permissive. More specific rules should be placed below more general rules.

The Action field allows the operator to set the mode to either Block or Pass the traffic as defined in the WAN Targets and Applications fields.

The direction field limits the prohibition of traffic to packets transiting the rXg in a particular direction. The outbound setting configures the firewall rule to drop packets originating from the LAN and destined for the WAN. Conversely, the inbound setting configures the firewall rule to drop packets originating from the WAN and destined for the LAN. The both setting drops all matching packets regardless of the direction of travel.

The WAN targets field limits the effect of the application filter rule defined by this record to traffic that is originating from or destined to the IP addresses or DNS names listed in the selected WAN targets. By default, an application filter denies all traffic matched by the policy regardless of WAN origin / destination. Setting a WAN target causes the breadth of the application filter to be limited to the specified hosts.

By default the WAN Target acts as a blacklist, however by checking the*Invert(!) WAN Targets* box, it will reverse the rule and make it a whitelist so instead of blocking access to what is defined in the WAN target it, it will only allow access to what is defined in the WAN target.

The applications field configures the kinds of applications that will be blocked by the application filter defined by this rule. Selecting multiple application groups applies this rule to all of the selected applications (logical or). By default, all types of packets that match the chosen policy , WAN targets , and applications are blocked.

The policy field relates this record to a set of groups through a policy record.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Filtering rules are applied in a top down order, with the last rule that matches being the one the takes effect, thus rule ordering is important. The Application Filters scaffold also has links to "Move Up" or "Move Down" an entry. More general rules should be at the top of the list and and as the rules get more specific they should be moved down. For example if there are two rules created, one that blocks all traffic and another that passes traffic to a set of WAN targets, the rule blocking all traffic should be moved up to the top, and the rule passing traffic to the set of WAN targets should be below it. This will block all traffic except for sites defined in the WAN target. If the rule order were reversed, where the pass rule is positioned at the top of the list and the rule blocking all traffic is below it, all traffic would be blocked including what is defined in the pass rule because the last rule that matched is the block rule.

Subnet Filters

The subnets filter scaffold configures the rXg packet filtering to enable or disable reachability between LAN subnets. By default, with no subnet filters configured, the rXg permits routing between subnets.

The policies field configures which clients will not be able to access hosts on LAN subnets other than their own. The filtering is unidirectional; clients affiliated with a policy that does not have a subnets filter configured can still access other subnets.

The WAN targets field configures a list of destination hosts that are exempt from the filtering. Clients of the selected policies will still be able to access these hosts, even if they are on a different subnet.

Example filter configurations.

Multi Tenant Example

In this example users will be blocked from communicating across subnets but will have access to a shared resource. First we need to define the resources we want to share by creating a WAN Target by navigating to Identities::Definitions. Create a new WAN Target , the Name field is arbitrary. Enter the IP address or FQDN of resources to be shared. Click Create.

Next navigate to Policies::Packet Filters , edit the existing Subnet Filter or create a new one. The Name field is arbitrary. Select the Shared Printer in the WAN Target field. Lastly use the Policies field to select the policies that should be included for this Subnet Filter. Click Create or Update.

With this configurations tenants will not be allowed to communicate with anything outside of their subnet with the exception of the Shared Printer.

Content Filter Example

In this example an Application Filter will be created that will block streaming services. By default the rXg comes with Applications that includes both Destination Ports and WAN Targets for popular streaming services. Create a new Application Filter , the Name field is arbitrary. Specify if inbound/outbound or both should be blocked using the Direction field. Leave the WAN Target field blank as the WAN Targets are attached to the Applications already in the included applications. In the Applications field, select the Applications to block. Lastly using the Policies field select the policies that this filter should be applied to. Click Create.

Block all traffic except what is whitelisted.

In this example the packet filter will be configured to block all traffic except for what is defined in the selected Wan Targets.

First define the site or sites we wish to allow access to by creating a WAN Target. Navigate to Identities::Definitions. Create or edit and existing WAN Target. For this example Social Media will be allowed but everything else will be blocked.

Next navigate to Policies::Packet Filters and create a new Application. The Name field is arbitrary. Protocol field should be set to tcp udp. For the Destination ports field enter >0, this will include all ports greater than 0. Click Create.

Next create a new Application Filter , the Name field is arbitrary. Set the Direction field to both. Use the WAN Targets field to select the desired WAN targets. To make the WAN targets a whitellist instead of a blacklist check the*Invert (!) WAN Targets* checkbox. In the Applications field select the Application created earlier that contains all ports. Lastly use the Policies field to select the policies to apply the filter to.

This configuration will only allow members of the Bronze policy access to social media sites and not allow them to access other sites.

In this example a rule will be created that blocks ICMP to the 8.8.8.0/24 subnet, and another rule will be created to pass ICMP traffic to 8.8.8.8.

First create the WAN target that contains the IP's to be blocked and another that contains the IP's to allow. Navigate to Identities::Definitions. Create a new WAN Target. Give the WAN target a name, and for the target enter 8.8.8.0/24. Click Create.

Create another WAN Target , this time the target will be the address to allow, in this case 8.8.8.8, click Create.

Next navigate to Policies::Packet Filters and create a new Application Filter. Give the application filter a name, Action should be set to block , Direction set to both. In the WAN Target field select the WAN target that contains the 8.8.8.0/24 subnet. In the Applications field select the ICMP application. Select the policies this rule should apply to, and click Create.

Create another Application Filter , give it a name. The Action field should be set to pass , and the Direction Field set to both. In the WAN Targets field select the WAN target contaning the addresses that are to be allowed. Select the ICMP application in the Applications field. Select the polcies the filter should apply to and click Create.

Now members of the Bronze and Silver policies can ping 8.8.8.8 but cannot ping other addresses in the 8.8.8.0/24 subnet. NOTE: the order of the rules are important, for this to work the PASS rule must be below the block rule in the scaffold. The order can be changed by clicking the Enable Drag & Drop link above the scaffold, or using the Move Up/Move Down links for an individual rule.