Packet filter policies can be organized in different ways. You are free to create your own arrangements. The skeleton itself provides only one proved and tested way. Although the skeleton is not necessarily full and ready for use, it can be extended and finetuned to meet the requirements. Of course, there can be situations when the skeleton policy is ready for use without modifications.

In a skeleton-based policy, the generated and user-defined rules are mixed and can function together. Without using skeletons only user-defined rules are exist. Generated rules are either based on information collected from other components, such as Networking, IPSec VPN or Application-level Gateway, or set during the generation of the skeleton.

The ruleset is generated automatically when the configuration of PNS is modified in a way which affects the packet filter configuration. User-defined rules remain untouched if specified as a keep rule, otherwise the generator removes these rules from the ruleset.

The generator automatically collects the information required to generate the ruleset from the different MC components. After the generator finished, the newly created configuration is presented and can be used the same way as an ordinary user-created configuration.

The new configuration contains both generated and user defined rules.

Since the skeleton consists of generated and user created rules, the relative order of their relations is very important. The generator creates and modifies chains and rules as well. In every chain which is modified by the generator, the generated rules always come first and user-created rules come only further in the framework. Generation drops those user-created rules which are not marked keep rules. Every other chains are left intact.

The order of the generated rules is not specified, but all of them are placed before the user-created ones. The relative order of the user-created rules are kept during the generations, although all the user-created rules are moved after the generated ones. There are two exceptions: the head group and the catch-all rules.

Every chain modified/touched by the generator has a head group. The role of the head group is to provide a way to insert user-created rules before the generated ones. The head group is a generated group and is placed as the first entry of the chain so every rule which is in the head group of the specific chain precedes all of the generated rules in the chain. The rules in the head group remain in place during the skeleton generation.

Some chains (built-in chains and user-defined ones from the IPTables point of view) have a catch-all rule(s). These rules try to provide a default policy for those chains which need it, for example the chains in the filter table.

The purpose of the catch-all rules is a default policy so they must be at the end of each chain following the user-created rules. No user created rule can follow them. Any rule appended after these catch-all ones are moved forwards during the generation.

For the filter table chains the catch-all rules consist of a LOG and a DROP rules to log the packets before they are dropped. The LOG rule also logs the chain to make it possible to trace where the packet was dropped. These two rules, but especially the DROP rule provides the default drop approach from the packet filter point of view for the host.

The catch-all rule in the mangle table only ACCEPTs the packets. ACCEPTing any packet in any table other than the filter does not necessarily mean letting it pass or allowing it to the application. Accepting packets in the mangle table means that neither the packet nor its associated mark values are modified; the packet is only passed to further processing.

After skeleton generation, the modified chain looks like the following: