The filter table is the place where the real filtering takes place so it is very important to understand how and why packets/connections are ACCEPTed or DROPed here.

Every connection that the firewall has to allow must be ACCEPTed here in some way. Basically, three kinds of traffic is handled at the filter table.

The generated ruleset allows every outgoing packet, (reply packets are allowed as well), so that OUTPUT chain ACCEPTs every packet. As PNS is an application level solution no packet forwarding takes place, therefore the FORWARD chain DROPs the packets.

This chain has a head group, like all generated chains, which is responsible for spoof protection. See also section Spoof protection. It has the LOG+DROP catch-all rules at the end as well.

The incoming traffic is basically handled in the INPUT chain and its subchains since the filter table is only meant for filtering (DROPping REJECTing and ACCEPTing) the packets and the connections. As every ruleset generated chain, the INPUT also begins with the head group, which works just as the same as it works in every other places.

After the head group, the evaluation continues with spoof protection, followed by the broadcast chain and noise filtering. Noise filtering is responsible for DROPping every network traffic/packet that is considered junk like broadcast messages or anything else that you want to drop without LOGing it. This filtering takes place in the noise chain which is generated by the ruleset generator. The noise chain begins with a head group and followed by DROP rules dropping (but not logging) packets going to the broadcast address of the network interfaces. As a catch-all rule the chain ends with a RETURN rule which jumps back to the INPUT chain and the ruleset evaluation continues from there.

After that, various ICMP packets are ACCEPTed which are RELATED to already established connections. Not every type of ICMP packets are allowed, only those that are needed for the correct and secure operation of the firewall. These are the following:

ICMP packet types are sent as responses for an already established connection by the remote peer indicating some network problem. RELATED means here that only those messages ACCEPTed which are responses for a known connection, messages related to an unknown connection are not ACCEPTed. For further information on RELATED and ICMP types, see Appendix C, Further readings.

After the ICMP rules, the next rule ACCEPTs every packet which belongs to an already ESTABLISHED connection. This way the reply packets for the outgoing connections are ACCEPTed. To track the state and the relation of a packet to the known connections the conntrack table is used. This table assigns a state information to every packet which is checked here.

The defaults group is next, which is responsible for keeping some necessary default rules. There is no need to modify these default rules although it is possible to add other rules. The first rule ACCEPTs every packet that has been marked for transparent proxying. Transparent proxying packets/connections in the mangle table is just redirecting them to the dispatchers (so they can handle transparent traffic), but every packet must be ACCEPTed on the filter table as well, so transparently proxying them on the mangle table is insufficient in this situation. When a connection is marked for transparent proxying, every packet belonging to that connection receives the same tproxy-mark. This way every previously TPROXYed packet can be ACCEPTed with only one rule. Another use of this mark is to flag those packets/connections which are implicitly requested by PNS and ACCEPT them as well with this rule. These connections are usually the secondary connections of traffic proxied by PNS, for example the data channel of an FTP session. When PNS listens for such a connection, it implicitly requests transparent proxying and flagging so there is no need to manually add rules for them — MS automatically generates the required rule into the PREROUTING chain of the mangle table: -A PREROUTING --match socket --transparent --jump MARK --set-mark 0x80000000/0x80000000. Not that it is also needed to allow/ACCEPT these connections on the filter table and this tproxy matching rule realizes that as well.

Altogether, in the defaults group every packet is ACCEPTed which has been already handled (for example, transparently handled packets) or is related to or part of already known connections. Every other packet must be filtered.

The next group is called local_services which is responsible for handling the packet filter configuration of the local or native services. These services can be set as the first step of the ruleset generation. For every service and for every selected zone an ACCEPT rule is generated matching the protocol, the port and the source zone addresses.

Following the local_services group, the routing group can be found. Like in the tproxy table, the rules are divided to subchains based on the incoming interface of the packets. The routing group is the placeholder for such rules that separate the traffic. For each and every interface a LO<interface name> chain exists and the rules in the routing group jump the evaluation to these chains according to the incoming interface and the IP addresses (primary and alias addresses) of the interface pairs. Every further production rule is located in the LO* subchains. Every LO* chain holds the rules that apply to the traffic coming in on the appropriate interface and target the host itself.

The LO* chains begin with the usual head group. After the head group, the rules generated by the ruleset can be found, but the order of the rules is not specified. The information for the rules come from two components: the Application-level Gateway and the VPN.

For every VPN connection, two rules are generated: one for ACCEPTing UDP packets from the remote end of the connection on source and destination port 500 and another rule ACCEPTing ESP (protocol: 50) packets from the remote end of the connection. These rules only allow the encrypted communication everything inside the tunnel, the real payload which comes on the ipsec* interfaces must be filtered separately like any other traffic.

The other rules placed in the LO* chains are generated based on the information from the PNS components. For every non-Transparent dispatcher in PNS an ACCEPT rule is created in one of the LO* chains according to the Address setting of the dispatcher. The configured Address specifies into which sub LO* chain should the rule be placed in.

Each rule ACCEPTs packets to destination ports configured in the Proxy port attribute where the dispatcher listens for connections.

At the end of the INPUT chain, every packet is LOGged and DROPed. Although normally no packet can get to this point of evaluation, because they are thrown to the LO* subchains and at the end of the subchains everything is LOGed and DROPed again. The LOG rule also logs the place (“filter/INPUT”) and the verdict (“DROP”) in the logs.