Firewall Scenarios

To reinforce the topics discussed in this chapter, it's a good idea to look into some sample configurations. The following sections look into three scenarios in which the firewall policy is not enabled, the firewall is using the AYT policy, and the firewall is using the CPP policy.

No Firewall Enforcement

In the scenario depicted in Figure 7.3, the central VPN Concentrator has not enabled any policies from the central location. It is imperative to install a personal firewall or utilize the Stateful Firewall (Always On) option in the Cisco VPN Client to ensure that this station does not become a liability in the overall security infrastructure. This type of administration enables the end-user to use better judgment in provisioning security. In the example, the stateful firewall is enabled and only ESP and DHCP traffic is allowed into the client. In addition, the client also receives traffic that is being transported over the secure tunnel. All other traffic is dropped. Thus, when the attacker from the Internet attempts to compromise the client, the stateful firewall inspects its state table. Because there is no match for the connection session initiated from the attacker, the packets are discarded. No other traffic parameters can be set in this example because the stateful firewall cannot be modified.

Figure 7.3. No Firewall policy scenario.

Firewall AYT Policy Scenario

In a firewall AYT policy, a firewall is required for connectivity and the AYT policy feature is implemented as shown in Figure 7.4. Every 30 seconds, the VPN 3000 Concentrator polls the BlackICE client to ensure that the firewall is still active. If the client becomes inactive, the concentrator terminates the tunnel. All security traffic parameters are still defined by the end user because there is no central policy being sent to the client.

Figure 7.4. AYT firewall policy scenario.

Firewall CPP Policy Scenario

Figure 7.5 entails the final scenario, in which the VPN 3000 Concentrator is pushing a policy to the ZoneAlarm or CIC client. In this scenario, a rule set has been defined and assigned to a created filter. The rules of this filter are as follows:

• All inbound and outbound traffic from 10.2.2.0/24 to the client's network of 10.1.1.0/24 is permitted because it is tunneled.

• Permit all inbound connections that use TCP port number 110 from the POP3 email server.

• Any Out (forward/out) is added to the filter to allow outgoing connections from the client.

• The default rule for this filter is to drop all other traffic when a match is not made.

Figure 7.5. CPP firewall policy scenario.

When this firewall policy is pushed to the client, it creates an access list on the client similar to a router IOS access list. Packets flowing through the client are compared against the rules in the CPP filter. When a match occurs, the rest of the rules are not compared. If a match does not occur, the default action specified on the filter is applied to the end of the list. In this example, the client can send and receive tunneled traffic, as well as send outgoing clear text traffic to the Internet (with split tunneling enabled). The only allowed incoming protocol coming from the Internet is POP3 traffic. All other traffic is dropped.