Definitions

The definitions view presents the scaffolds associated with configuring mechanisms to identify applications and WAN targets.

The rXg identifies applications by traffic characteristics and WAN targets by IP address or domain name. Identified applications and WAN targets are used in many facts of the policy enforcement engine.

For example, when used with bandwidth queues, application identification is useful for reducing the priority of bulk transfer of data over FTP and NNTP and increasing the priority of interactive applications such as web surfing. WAN targets may be used with bandwidth queues to restrict the utilization of social networking websites and/or guarantee the bandwidth to video on demand servers.

WAN targets are in many other facets of the policy enforcement engine. For example, WAN targets are used as whitelists to enabled unfettered access to certain websites when forced browser redirection to a captive portal is enabled. In addition, WAN targets are used to select destinations for link affinity when an rXg is deployed in a link control scenario.

Applications

An entry in the applications scaffold defines a set of ports that are considered by the rXg to be a singular logical group for policy enforcement.

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.

The protocol field configures this application definition to match to a particular class of transport. In most cases, a given application will only transport over only one TCP, UDP or ICMP, not

The destination ports and source ports fields specify the ports that are used to identify the application defined by this record. Multiple ports and ranges of ports are specified by using these operators:

!=x All ports not equal to the specified value. For example, !=80 matches all ports other than 80. <x and <=x All ports less then and less than or equal to the specified value. For example, <1024 matches all ports less than 1024 (i.e., 1 to 1023 inclusive) and <=1024 matches all ports less or equal to 1024 (i.e., 1 to 1024 inclusive). >x and >=x All ports greater than and greater than or equal to the specified value. For example, >40000 matches all ports greater than 40000 (i.e., 40001 to 65535 inclusive) and <=40000 matches all ports greater than or equal to 40000 (i.e., 40000 to 65535 inclusive). x-y and x:y All ports within the range specified by the numbers on either side of the operator including boundaries. For example, 5900-5909 and 5900:5909 are two ways to specify ports 5900 to 5909 inclusive. x><y All ports within the range specified by the numbers on either side of the operator excluding boundaries. For example 1025><1030 specifies ports 1026 to 1029 inclusive. x<>y All ports except those specified by the numbers on either side of the operator. x,y Multiple port specifications may be included in a single field by separating them with commas. For example, `8080-8090, 9080-9090,

=9300`

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.

WAN Targets

WAN targets define WAN IP addresses and DNS entries that are to be considered as a single logical group for the purposes of policy enforcement.

The targets field configures the list of WAN IPs and/or DNS entries that are members of this WAN target. Any combination of IP addresses (IPv4 or IPv6), CIDR notation, DNS names, and wildcard domain patterns is valid. Enter one target per line, or separate multiple targets with commas.

The source URL field configures an optional remote URL from which the targets list can be automatically downloaded and synchronized. When configured, the rXg will periodically fetch the contents of the URL and update the targets list accordingly. This enables operators to maintain centrally-managed target lists that are automatically distributed across their fleet.

The sync frequency field determines how often the rXg will re-download and synchronize the targets list from the configured source URL. Available options include hourly, twice-daily, daily, weekly, bi-weekly, and monthly.

Using DNS names reduces the performance of the system due to the need to perform DNS lookup. Use IP addresses when possible.

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.

Default WAN Target Lists

The rXg ships with a comprehensive library of pre-configured WAN target definitions covering popular services, platforms, and network infrastructure endpoints. These default lists are designed to give operators immediate, out-of-the-box policy enforcement capabilities without requiring manual research or configuration of destination addresses for well-known services.

Default WAN target lists can be created or restored at any time using the Create Defaults action in the WAN Targets scaffold. Operators are free to customize any default list to suit their specific deployment requirements entries can be added, removed, or the list can be deleted entirely without affecting system operation.

DNS over HTTPS Providers

The DNS over HTTPS Providers default WAN target is a curated list of known DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) service endpoints. This list includes the domain names and IP addresses of public encrypted DNS resolvers operated by providers worldwide.

Purpose and Intent

The inclusion of this list is not an indication that these services are malicious or harmful. DNS over HTTPS is a legitimate privacy-enhancing technology used by millions of users globally. The rXg includes this comprehensive list to empower network operators with visibility and policy control over encrypted DNS traffic within their managed networks.

The list is intentionally broad in geographic and provider coverage to support operators deploying across diverse regions and subscriber populations. Whether an operator manages networks in North America, Europe, Asia-Pacific, or any other region, the default list provides identification of regional and global DoH/DoT providers that subscribers' devices may be configured to use.

Why Operators Need This

In managed network environments such as service provider, hospitality, enterprise, and multi-dwelling unit deployments operators rely on DNS infrastructure for critical network functions including:

Captive portal enforcement Subscriber devices using external encrypted DNS can bypass captive portal detection mechanisms
Content filtering and compliance Regulatory or policy-driven content restrictions require DNS-level visibility
Security monitoring DNS query logs provide essential threat intelligence; encrypted DNS to external resolvers creates blind spots
Network diagnostics DNS-based troubleshooting and traffic analysis depend on queries traversing the local resolver

The DNS over HTTPS Providers WAN target allows operators to build policies that address these requirements while maintaining a positive subscriber experience. Common use cases include:

Associating the list with content filters to block or shape encrypted DNS traffic to external resolvers
Using the list with bandwidth queues to manage DoH traffic
Attaching to uplink control policies to route DoH traffic through specific paths
Excluding from captive portal bypass whitelists to ensure portal enforcement is not circumvented by encrypted DNS

Customization

Operators should review and tailor this list to their specific deployment needs. Some considerations:

Remove entries for providers not relevant to your subscriber base or geographic region
Add new providers as the DoH ecosystem evolves
Use the source URL and sync frequency fields to subscribe to a centrally-maintained and regularly-updated list
Some entries in the default list may trigger alerts in third-party security monitoring systems (e.g., next-generation firewalls or SIEM platforms) that categorize any DNS resolution outside their known-good list as suspicious. This is expected behavior the WAN target entries are domain names being identified for policy enforcement, not indicators of compromise

DPI Signatures

An entry in the DPI Signatures scaffold specifies a set of deep packet inspection rules that are used to identify and classify of end-user traffic.

The rules field contains the deep packet inspection specifications that are used to identify the end-user traffic. Rules are specified using the Snort rule format. The rXg is designed to be compatible with most Snort rulesets that are commonly available for download. For example, the Sourcefire Vulnerability Research Team publishes a list of Snort rules that identify common attacks.

The rXg requires that rules follow a few additional specifications in addition to the Snort grammar:

The alert action must be specified. The log and pass actions will not have any affect when used with the rXg. In other words, any rule that does not begin with the alert idiom will be ignored when used with the rXg.

The sid idiom (Snort rule ID) is required for each and every rule. Furthermore no two rules may have the same sid. Ensure that rules abide by the Snort sid conventions to prevent sid conflict. Values of sid less than one million are reserved for "official" rules. Bleeding Snort publishes rules starting at sid two million. Entirely new custom rules should start at sid nine million.

The msg idiom is used by the rXg for logging. For example, when DPI signatures are used with triggers, the string specified by the msg idiom is used to populate the reason field.

Here is a simple example rule that checks to see if a node transmits 10 emails (via port 25) in the past 60 seconds:

alert tcp $HOME_NET any -> any 25 (msg:"possible spammer";
content:"rcpt to\:"; nocase; flow:to_server, established;
threshold:type both, track by_src, count 10, seconds 60; sid:9000000;
rev:1;)

Here is a another example rule that checks to see if a node opens more than 10 SSH connections (via port 25) in the past 60 seconds:

alert tcp any any -> any 22 (msg:SSH incoming; flow:stateless;
flags:S+; threshold:type both, track by_src, count 10, seconds 60;
sid:9000001; rev:1;)

Nodes that exhibit such behavior are likely to be zombies that are transmitting spam. The above rule is intended to be used in a DPI signature linked to a policy that is associated with throttling via bandwidth queues or quarantine via captive portal to prevent upstream spamming.

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.

Remote DPI Signatures

An entry in the Remote DPI Signatures scaffold configures the rXg for automatic download of deep packet inspection signatures that are used to identify and classify of end-user traffic from a third-party website.

The categories field allows the operator to choose from one or more groups of predefined signatures present on the third-party server. This field is only useful when the URL of this remote DPI signature refers to a gzipped tarball archive. The signatures present in the archive are presumed to be organized by file name. Each file should contain signatures that are relevant to the name of the file.

The SID whitelist field enables the operator to exclude specific rules from being used. This feature is typically used to exclude overly aggressive rules and thus reduce the possibility of false positives. Consider the following rule from the Snort emerging threats list:

emerging-p2p.rules:alert udp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:"ET P2P Edonkey Publicize File"; dsize:>15; content:"|e3 0c|"; depth:2; reference:url,www.giac.org/certified_professionals/practicals/gcih/0446.php; reference:url,doc.emergingthreats.net/bin/view/Main/2003310; classtype:policy-violation; sid:2003310; rev:3;)

The example rule shown above is known to occasionally trip false positives with Skype file sharing. Listing 2003310 into the SID whitelist field causes the rule to be ignored. Multiple SIDs may be listed in the SID whitelist to tell the DPI engine to ignore more than one rule in the remote set.

When a remote DPI signature record is first created, the categories field will be empty. Once the signatures have been downloaded and extracted for the first time, the names of the files will then appear in this field. After creating a remote DPI signature it is necessary to edit the record and select the desired categories in order for proper operation. Initial download time (and hence, population of the categories field depends upon the size of the archive file as well as the speed of the network connection between the server addressed by the URL.

The URL field contains the URL of the file that the rXg will download. The target file is expected to be in one of two formats: .tar.gz archive or a .txt plain text file. If the file is a gzipped tarball archive (.tar.gz), it is expected to extract multiple files named by category, each of which contains DPI signatures. If the file is plain-text, it is expected that the file is simply a file of the the DPI signatures. The rXg supports DPI signatures formatted for Snort 2.9. Well known remote DPI signature repositories include the official Snort rules and the Snort emerging threats list.

The frequency field specifies the download interval. Some sites have terms of use that specify appropriate download intervals. Please check the remote site terms and conditions carefully before using.

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.

Content Filter Lists

Entries in the content filter lists scaffold are used to define sets of domain names and URLs that are to be blocked or passed by the rXg content filter. Each content filter list record should store a list of domains, wildcards, or URLs that are similar in nature for organizational purposes. Multiple content filter lists may be used simultaneously in a single content filter enforcement.

The category field is used to store a short phrase that is meant to help the end-user understand the reason why the URL is being blocked. The text in this field is presented on the access denied page on the captive portal. For example, if the list includes domains and URLs that refer to online casinos, the phrase "gambling" would be appropriate for the category.

The list field contains the set of entries that comprise this content filter list. When this content filter list is associated with a content filter enforcement, HTTP requests that match entries in this list will be denied. Valid entries include domain names (e.g., somedomain.com) as well as URL fragments (e.g., somedomain.com/somepath/).

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.

Remote Content Filter Lists

Entries in the remote content filter lists scaffold are used to configure the parameters needed to periodically download third party maintained lists. The de facto standard list format is a compressed archive (.tar.gz) file that extracts into a series of subdirectories named by blocking category. Each entry in this scaffold configures the periodic download of a compressed archive (.tar.gz) file. Multiple archive files may be used in a single content filter policy enforcement.

The categories field allows the operator to choose from one or more groups of URLs and/or domains to include in this remote content filter list definition. This field is only useful when the URL of this remote content filter list refers to a gzipped tarball archive. The names of subdirectories present in the archive are presumed to be the names of blocking categories and show up in this field.

When a remote content filter list is created, this field will be empty. Once the list is downloaded and extracted for the first time, the subdirectories will then appear in this field. After creating a remote content filter list it is necessary to edit the record and select the desired categories in order for proper operation. Initial download time (and hence, population of the categories field depends upon the size of the archive file as well as the speed of the network connection between the server addressed by the URL.

When Custom is selected in the Provider field it allows the operator to specify a custom URL to a list maintained by the operator or another source.

The URL field contains the URL of the file that the rXg will download. The target file is expected to be in one of two formats: .tar.gz archive or a .txt plain text file. If the file is a gzipped tarball archive (.tar.gz), it is expected to extract multiple subdirectories named by category, each of which contains a "urls" file containing a list of specific URLs to list, and/or a "domains" file containing a list of domains (i.e., entire sites) to list. If the file is plain-text, it is expected that the file is a list of domains and URLs to list. The rXg supports lists formatted for ufdbGuard,DansGuardian and SquidGuard. Well known providers include URLfilterDB, Shalla Listand Squidblacklist.org.

The frequency defines the periodicity with which the rXg will download the list archive file from the URL specified. The request to download a new remote content filter list occurs immediately after the create button is clicked. The periodicity of subsequent downloads are determined by the value of specified in this field. The downloading of subsequent updates will always occur between 4 and 5 AM local time.

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.