Example: using Access rules to filter traffic on an inline IPS engine

Figure: Company B's network

Hosts in the two networks must be able to communicate between each other using certain specific ports. Also, one of the administrators has a workstation connected to Network A. The administrator’s workstation must have unrestricted access to Network B. The administrators decide that the inline IPS engine provides an acceptable level of security between two internal networks.

The administrators:

1. Create elements for network A, network B, and administration host.
2. Add new Access rules for their inline IPS engine:

   Table 1. Access rules for filtering traffic

   Source	Destination	Service	Action	Options
   Administrator Network B	Administrator Network B	ANY	Allow	Logging: Undefined Deep inspection: On
   Network A Network B	Network A Network B	Service elements for allowed services	Allow	Logging: Undefined Deep inspection: On
   ANY	ANY	ANY	Allow	Logging: Stored Deep inspection: (irrelevant, because dropped traffic is never inspected further)

   • Each of the first two rules allows traffic between the Source and the Destination in both directions. The order of the elements within the Source, Destination, and Service cells makes no difference to the outcome of the matching process.
   • The order of the rules is important. The rules above proceed correctly from most specific to the least specific. The two first rules must be in this order, because the administrators want all connections from the Administrator host (which is in Network A) to always match the first rule and never the second one, since the rules have different logging options.
   • The last of the added rules stops all traffic that is not allowed in the rules above to prevent unauthorized traffic from passing.
     Note: If the inline interfaces are on a fail-open network card, traffic passes freely whenever the IPS engine is offline regardless of what the Access rules state.