Defining Traffic Flows and Shaping Rules

While routing rules can be viewed on non-managed gateway objects, such as clouds and routers, such rules are not distributed to those gateway objects by Cisco Secure Policy Manager. Instead, Cisco Secure Policy Manager assumes that you have defined such routing rules on those gateway objects.

Note All static routing rules that have been defined using administrative interfaces other than Cisco Secure Policy Manager are replaced by those routing rules that are defined using Cisco Secure Policy Manager. Therefore, you should be sure to copy your current configuration to a safe location so that you can specify any non-derived static routing rules within Cisco Secure Policy Manager.

Note For the purpose of this discussion, a network object is a host or consumer of network services. It is an endpoint that acts as an initiator or recipient of a network communication.

Before any network packet can traverse the network from NetObject A to NetObject B, routes must exist for NetObject B on every gateway object along the path from NetObject A to NetObject B. Like a bucket brigade, each object moves the network packet one step farther down the path. On the basis of the final destination of the packet, each object uses routing rules to determine the next object along the path. The next object's address is called the "hop address." For a network session to occur between NetObject A and NetObject B, the inverse routes must exist on every gateway object along the path from NetObject B to NetObject A. The two paths do not necessarily have to be symmetric.

Figure 7-1:
Rules Required to Route Between Two Objects

In a scenario where NetObject A and NetObject B reside on networks directly attached to separate interfaces on a common Policy Enforcement Point (Gw1), six routing rules must exist for bi-directional communications:

• R1: NetObject A must have a route to Net Y on which NetObject B resides. (non-implicit)

• R2: NetObject A must have a route to Gw1. (implicit)

• R3: Gw1 must have a route to Net Y on which NetObject B resides. (implicit)

• R4: Gw1 must have a route to Net X on which NetObject A resides. (implicit)

• R5: NetObject B must have a route to Net X on which NetObject A resides. (non-implicit)

• R6: NetObject B must have a route to Gw1. (implicit)

These rules are marked as "Derived" in the Routes panel. When you define routing rules, you only need to define rules for special cases where the derived rules are inadequate or where you need to override a derived rule---such rules are "MANUAL," which represent non-derived rules. The remainder of this topic provides details useful for managing non-derived rules.

Note If you define a MANUAL routing rule that overrides a derived routing rule, the derived routing rule will no longer appear in the Routes panel and no command set will be generated to enable that derived route. However, you can delete the MANUAL routing rule to have the derived routing rule generated and distributed as part of the command set.

Just because a computer exists on your internal networks does not mean that Policy Enforcement Points have a routing rule defined for it. If a computer cannot communicate with a Policy Enforcement Point, most likely no routing rule is defined to reach that computer (or the computer does not have a routing rule to reach the gateway or Policy Enforcement Point). Even when the computer resides on your trusted networks, a Policy Enforcement Point drops all network packets destined for that computer if a route is not defined directly to that computer or the network on which that computer resides.

Tips You can use Cloud nodes and cloud networks to ensure that all your networks are identified so that Cisco Secure Policy Manager can generate derived routing rules for all routes required to reach those networks contained within the cloud and the objects residing on those networks.

Defining routing rules is similar to charting a course of travel. When you look at a map, you can plan an optimal route to a specific destination. When a Policy Enforcement Point determines what route to use, it selects the most specific rule (based on the highest netmask). Because Cisco Secure Policy Manager does not support dynamic routes, you can only define one routing rule for each network or cloud network defined within the Network Topology tree.

To understand how netmasks are used, consider a Policy Enforcement Point that is attached to the 10.0.0.0 network.

Example: We will consider two routing rules:

1. address: 10.1.2.0 netmask: 255.255.255.0 gateway: 10.0.0.4

2. address: 10.1.0.0 netmask: 255.255.0.0 gateway: 10.0.0.5

Rule 1 applies for network packets that are destined for the more exclusive 10.1.2.* subnetwork, whereas Rule 2 applies to those network packets destined to the 10.1.*.* subnetwork, but not to the 10.1.2.* subnetwork. For example, Rule 2 would apply to network packets destined for 10.1.3.13, and Rule 1 would apply to network packets destined for 10.1.2.13.

In this example, the largest netmask value determines which rule to use, selected from the list of available rules that are applicable to the destination address of a network packet.

Because the netmask value in Rule 1 is 255.255.255.0, we know to use the first three octets in the address when determining whether to apply this routing rule. In Rule 2, we know that only the first two octets are necessary for determining whether to apply it. Because Rule 1 has three significant octets, it has the highest netmask value. When the Policy Enforcement Point receives a network packet destined for a host on the 10.1.2 network, Rule 1 is always applied instead of Rule 2. Rule 1 applies because it is a valid rule for routing the network packet (as is Rule 2) and Rule 1 has a larger netmask value than Rule 2.

Step 2 To view the Routes panel, point to Properties, and click Routes on the shortcut menu.

Result: The Routes panel appears in the View pane.

Result: A new rule appears as the last item in the Active Routing Rules list with the word "Unknown" selected in the Network box.

Step 4 To select the network, network shortcut, or cloud network to which you want this Policy Enforcement Point to be able to route

• right-click the question mark in the Network box under Active Routing Rules, and click that object in the options list that appears

---or---

• click (specify) to define a custom network (one that is not defined in the Network Topology tree).

The options list displays all network, network shortcut, cloud networks, and IP ranges that are defined in the Network Topology tree. This options list also includes the (specify) option.

Step 5 If you selected an existing object, skip to Step 9. Otherwise continue with Step 6.

Because routes to all directly connected networks are automatically derived, this value identifies an address of a network, network shortcut, or cloud network that is not directly connected to the Policy Enforcement Point---it does not belong to an object to which the Policy Enforcement Point's network interfaces are directly connected. This value is also a network that is not defined under the Network Topology tree.

Step 8 To specify the gateway that is used to reach the object specified in the Network Address box, type the IP address of that gateway in the Gateway box under Active Routing Rules.

This value identifies a gateway that either

• forwards, to another gateway, any network packets destined to the network or host specified in the Network box

---or---

• delivers the network packets to the final destination because the network is directly attached to the gateway.

Step 9 Repeat Steps 3 through 7 for each new rule that you want to create.

Step 10 To accept your changes and close the selected panel, click OK.

Step 11 To save any changes that you have made, click Save on the File menu.

Step 2 To view the Routes panel, point to Properties, and click Routes on the shortcut menu.

Result: The Routes panel appears in the View pane.

Result: The boxes under Selected Route display the current settings for the selected rule.

Note You cannot change a rule that is marked "Implicit" or "Derived." However, you can override such a rule by defining a MANUAL rule to the same target network object.

Step 4 To modify the IP address of the network, network shortcut, or cloud network for this rule, right-click that object in the Network box under Active Routing Rules, and then either

• click the new object in the options list that appears

The options list displays all networks that are defined in the Network Topology tree.

---or---

• click (specify), and type the new address of the network in the Network Address box under Selected Route

Because routes to all directly connected networks are automatically derived, this value identifies an address of a network, network shortcut, or cloud network that is not directly connected to this gateway object---it does not belong to an object to which this gateway object's network interfaces are directly connected. This value is also a network that is not defined under the Network Topology tree.

Step 5 If you selected an existing network, skip to Step 8. Otherwise continue with Step 6.

This value identifies a gateway that either

• forwards, to another gateway, any network packets destined to the network or host specified in the Network Address box

---or---

• delivers the network packets to the final destination because the network is directly attached to the gateway.

Step 8 Repeat Steps 3 through 7 for each rule that you want to change.

Step 9 To accept your changes and close the selected panel, click OK.

Step 10 To save any changes that you have made, click Save on the File menu.

Step 2 To view the Routes panel, point to Properties, and click Routes on the shortcut menu.

Result: The Routes panel appears in the View pane.

Step 3 To disable the generation of derived routing rules, select the Inhibit generation of non-MANUAL rules.

Result: Any derived routing rules, marked Implicit or Derived, are removed from the Routes panel. The only routing rules, based on this gateway object, that Cisco Secure Policy Manager will publish to any Policy Enforcement Points on your network are those MANUAL routing rules that you define in this panel.

Step 4 To accept your changes and close the selected panel, click OK.

Step 5 To save any changes that you have made, click Save on the File menu.

Step 2 To view the Routes panel, point to Properties, and click Routes on the shortcut menu.

Result: The Routes panel appears in the View pane.

Step 3 To review the list of active rules, scroll through the Active Routing Rules list.

Step 4 To review the IP address assigned to the interface to which a network is attached for any given rule, click that rule in the Active Routing Rules list.

Result: The Interface Address field under Selected Route displays the value associated with the selected routing rule, as do the Network Address and Network Mask boxes.

Step 5 To close the selected panel, click OK.

Static translation and address hiding rules are enforced by a Policy Enforcement Point when network packets are transferred between two perimeters (inter-perimeter communications) attached to that Policy Enforcement Point. These rules are enforced on a per-Policy Enforcement Point basis, and you can only define these two rule types on a Policy Enforcement Point.

A path restriction rule enables you to restrict network flows across your network. Like static translation and address hiding rules, path restriction rules are enforced by Policy Enforcement Points. However, you can define path restriction rules on all gateway object types, including Policy Enforcement Points, routers, and clouds, and each Policy Enforcement Point along the restricted path enforces these rules by not permitting network services enabled by the security policies that you have defined to traverse that Policy Enforcement Point.

The following sections describe how each rule type works, when to use that rule type, and how to create, modify, and view those types of rules from the Mapping panel.

Caution If you define a static translation rule for a Policy Distribution Point, you can cause a temporary command set publishing problem. The problem results because the connection to the Policy Enforcement Point is broken after the new command set is published to the Policy Enforcement Point because it effectively changes the address of the Cisco Secure Policy Manager host by which the current command set is being published.

In this case, you have two possible solutions to resolve this temporary problem:

• Define a temporary policy that permits the administrative network service from the old Policy Distribution Point address to the administrative network interface in the Policy Enforcement Points that use that Policy Distribution Point. You only need to define the policy to permit the old IP address because the policy that permits the new IP address is automatically generated and applied in the Cisco System Folder. After you have published the command sets, remove the temporary policy and regenerate/publish the command sets.

• Another approach is to use the Prologue option in the Command panel for the affected Policy Enforcement Points to specify that you want to accept administrative connections manually from the old IP address used by the affected Policy Enforcement Points. After you have published the command sets, you can remove the line and republish.

Note Because static translation rules take precedence over address hiding rules, you can use this rule type to force a specific translation while allowing other communications to be translated using the more generic address hiding rules.

Example: We can define a static translation rule that maps from the external IP address 192.168.7.130 (alias address) to the internal file server 192.168.1.3 (real address).

Note To allow communication to these internal hosts, you must still define and apply security policies that permit session requests originating on the external networks to reach the internal servers.

When the Policy Enforcement Point receives a session request where the source address matches the IP address of the internal file server, it changes the source address to the external IP address before placing the packet onto the network of which the external address is a member. Likewise, when the Policy Enforcement Point receives a network packet destined for the alias address, it changes the destination address to the address of the internal file server and places the new packet onto the network to which the internal file server belongs. Thus, the internal file server processes the packet as though it were originally destined for the file server. In both cases, all packets that are part of a valid session are remapped according to the translation rule (assuming that the active security policy permits the communication). If the active security policy does not permit a specific communication, the session request is rejected and the translation never occurs.

Warning If you expose your internal DNS servers using a static translation rule, you do not benefit from the address hiding feature provided by address hiding rules. External users can simply request information about your trusted networks from the DNS servers that you expose.

Result: The Mapping panel appears in the View pane.

Step 2 To specify that you want to define a static translation rule, click Static Translation (bidirectional remapping) in the Select rule type box.

Result: The list of active static translation rules appears in the Static Translation list.

Result: A new rule named S# is created in the Static Translation list.

Step 4 To specify which network object to translate with this rule, click that network or host in the Translate object box under Static Translation (bidirectional remapping).

The Translate object box displays a list of the network objects that reside under the Policy Enforcement Point node for which you are defining this rule. If you do not see the network object that you want to hide, you must define it within the Network Topology tree.

Caution If you define a static translation rule for a Policy Distribution Point, you can cause a temporary command set publishing problem. The problem results because the connection to the Policy Enforcement Point is broken after the new command set is published to the Policy Enforcement Point because it effectively changes the address of the Cisco Secure Policy Manager host by which the current command set is being published.

In this case, you have two possible solutions to resolve this temporary problem:

• Define a temporary policy that permits the administrative network service from the old Policy Distribution Point address to the administrative network interface on the Policy Enforcement Points that use that Policy Distribution Point. You only need to define the policy to permit the old IP address because the policy that permits the new IP address is automatically generated and applied in the Cisco System Folder. After you have published the command sets, remove the temporary policy and regenerate/publish the command sets.

• Another approach is to use the Prologue option in the Command panel for the affected Policy Enforcement Points to specify that you want to accept administrative connections manually from the old IP address used by the affected Policy Enforcement Points. After you have published the command sets, you can remove the line and republish.

Tips You can lock the Mapping panel by clicking the Lock this view box at the bottom of the panel, and then use a drag-and-drop operation to move a host from the Network Topology tree onto the Translate object box.

Step 5 To specify the interface, or set of interfaces, from which the network or host will be translated, click the interface(s) in the via interface(s) box.

The via interface(s) box displays a list of the interfaces directly attached to the Policy Enforcement Point. However, this list does not contain the interface to which the network or host that you want to translate is attached. You cannot translate a host or network from the interface to which it is attached.

When you translate a network object from an interface, you are declaring that any network object attached to that interface cannot use the real address to access the translated network object. Instead, such network objects must deliver all network traffic to the address specified in the using address box (presumably, the address assigned to the interface to which the network objects are attached). The Policy Enforcement Point acts as a proxy agent between the translated network object and the interface objects by mapping between the two addresses. This mapping occurs for communications that originate either from the translated network object or from an object residing on the interface specified in this field.

Tips To select more than one value from this list, press and hold the Shift key or the Ctrl key while selecting an item in the list. The Shift+Click option enables you to select a sequential set of values. The Ctrl+Click option enables you to select values in any order.

Step 6 To specify the IP address, or starting address of an IP range, that the internal network object's address(es) will be remapped to, type that IP address in the using address box.

This value is the specific alias IP address to which you want to translate the real addresses of the translated object. If the value in the through    with box is also specified, this address identifies the starting address of the IP range that will be used to translate the network object. However, you can define a range of exactly one address. If the Policy Enforcement Point is exposing the network object to users on the Internet, this IP address must be a valid IP address that is registered with the American Registry for Internet Numbers (ARIN).

Step 7 To specify the ending address of the IP range that the internal network object address(es) will be remapped to, type that IP address in the through    with box.

This value identifies the ending alias IP address in an IP address range that will be used for this translation rule. If the Policy Enforcement Point is exposing the network object to users on the Internet, this IP address must be a valid IP address that is registered with ARIN.

Step 8 To specify the network mask value of the IP range that the internal network object address(es) will be remapped to, type that value in the mask box.

This value identifies the mask of the network on which IP address(es) used as aliases are members. It represents the number of bits in the netmask.

Step 9 (PIX Firewall only: Optional) To specify the maximum number of simultaneous connections for this rule, type that value in the MaxC box.

This value is a whole number that represents the maximum number of simultaneous connections that can use this translation rule. The Policy Enforcement Point enforces this value against new session requests. Use 0 (zero) to specify the default value assigned to the Policy Enforcement Point.

This value is a whole number (smaller than the MaxC value) that represents the maximum number of simultaneous embryonic links that can use this translation rule. The Policy Enforcement Point enforces this value against new session requests by restricting the number of session requests that have not completed the handshake. This feature enables you to guard against TCP_SYN attacks. Use 0 (zero) to specify the default value assigned to the Policy Enforcement Point.

Step 11 For each new rule that you want to create, repeat Steps 3 through 10.

Step 12 To accept your changes and close the selected panel, click OK.

Step 13 To save any changes that you have made, click Save on the File menu.

Step 2 To view the Mapping panel, point to Properties, and then click Mapping on the shortcut menu.

Result: The Mapping panel appears in the View pane.

Result: The list of active static translation rules appears in the Static Translation list.

Step 4 To select the rule that you want to change, click that rule under Static Translation (bi-directional mapping).

Step 5 To change which host on your internal network is used for this rule, click the new host in the Translate object box.

The list of hosts that are available in the Translate object box are those hosts that reside under the selected Policy Enforcement Point. If you do not see the host for which you want to define the new rule in this list, you must define that host in the Network Topology tree.

Caution If you define a static translation rule for a Policy Distribution Point, you can cause a temporary command set publishing problem. The problem results because the connection to the Policy Enforcement Point is broken once the new command set is published to the Policy Enforcement Point because it effectively changes the address of the Cisco Secure Policy Manager host by which the current command set is being published.

In this case, you have two possible solutions to resolve this temporary problem:

• Define a temporary policy that permits the administrative network service from the old Policy Distribution Point address to the administrative network interface on the Policy Enforcement Points that use that Policy Distribution Point. You only need to define the policy to permit the old IP address because the policy that permits the new IP address is automatically generated and applied in the Cisco System Folder. After you have published the command sets, remove the temporary policy and regenerate/publish the command sets.

• Another approach is to use the Prologue option in the Command panel for the affected Policy Enforcement Points to specify that you want to accept administrative connections manually from the old IP address used by the affected Policy Enforcement Points. After you have published the command sets, you can remove the line and republish.

Tips You can lock the Mapping panel by clicking the Lock this view box at the bottom of the panel, and then use a drag-and-drop operation to move a host from the Network Topology tree onto the Translate object box.

Step 6 To specify the interface, or set of interfaces, from which the network or host will be hidden, click the interface(s) in the via interface(s) box.

The via interface(s) box displays a list of the interfaces directly attached to the Policy Enforcement Point. However, this list does not contain the interface to which the network or host that you want to hide is attached. You cannot hide a host or network from the interface to which it is attached.

When you hide a network object from an interface, you are declaring that any network object attached to that interface cannot use the real address to access the hidden network object. Instead, such network objects must deliver all network traffic to the address specified in the using address box (presumably, the address assigned to the interface to which the network objects are attached). The Policy Enforcement Point acts as a proxy agent between the hidden network object and the interface objects by mapping between the two addresses. This mapping occurs for communications that originate either from the hidden network object or from an object residing on the interface specified in this field.

Tips To select more than one value from this list, press and hold the Shift key or the Ctrl key while selecting an item in the list. The Shift+Click option enables you to select a sequential set of values. The Ctrl+Click option enables you to select values in any order.

Step 7 To change the IP address on the selected host that is remapped, click the new IP address in the using address box.

The addresses that are available in the using address box are the IP addresses that have been previously assigned to that network host within the Network Topology tree.

The list of addresses available in the through    with box are the IP addresses assigned to the network adapter cards on the Policy Enforcement Point for which you are defining this new rule.

Step 9 For each new rule that you want to change, repeat Steps 3 through 8.

Step 10 To accept your changes and close the selected panel, click OK.

Step 11 To save any changes that you have made, click Save on the File menu.

Step 2 To view the Mapping panel, point to Properties, and then click Mapping on the shortcut menu.

Step 3 To specify the rule type that you want to view, click Static Translation (bidirectional remapping) in the Select rule type box.

Step 4 To review the list of active rules, scroll through the list under Static Translation.

Step 5 To close the selected panel, click OK.

In addition to conserving IP addresses, address hiding provides additional security features for your network by hiding its internal structure and allowing logical mappings to users who compose the different groups and departments within your company. These logical mappings enable you to track your external network usage statistics much more easily.

Warning If you expose your internal DNS servers using a static translation rule, you do not benefit from the address hiding feature provided by address hiding rules. External users can simply request information about your trusted networks from the DNS servers that you expose.

While some users may not need to use address hiding, you should keep this feature in mind as your network continues to grow. The following topics describe what problems address hiding can solve and how it works to solve these problems.

• Enhances network security by hiding your network's internal structure from external users and enables you to logically group your users according to security domains.

• Permits an almost unlimited number of users for one class D network address because valid external addresses are required only when a user is connected to the Internet.

• When you attach your existing IP networks to the Internet, you do not need to replace the IP address of each computer on your internal subnets with a valid, registered IP address from the Internet Network Information Center (the American Registry for Internet Numbers [ARIN]).

As these benefits indicate, network address translation overcomes several limitations associated with the current IP addressing scheme. We discuss these limitations below.

Conceals Internal IP Addresses from Internet Users. As the network administrator, you may wish to conceal internal network addresses from the Internet, which prevents them from being disclosed to possibly malicious users. An address hiding translator dynamically assigns a valid external IP address to an internal IP address by mapping the internal address to an external address. Because this mapping between the external and internal IP addresses is temporary (it lasts only for the duration of a session), your internal IP addresses are concealed from the Internet. Only the external addresses appear in the packets that are distributed across the Internet.

Requires Fewer Registered IP Addresses. To connect to the Internet, a company must purchase IP addresses from ARIN, which is the organization responsible for registering and assigning IP addresses to those who wish to connect to the Internet. Currently, IP addresses are allocated based on the size of the company that is requesting IP addresses. To prevent depletion of IP addresses on the Internet, small and medium organizations receive fewer IP addresses, regardless of plans for future expansion. An address hiding translator bypasses this limitation and ensures that you can continue to grow your network without acquiring additional addresses. Because an address hiding translator distributes the control and allocation of valid external IP addresses, it provides full connectivity and access to the Internet regardless of the size of your network or the number of users that you support.

Use of Invalid Internal Addresses. Because many companies use invalid IP addresses within their intranets, computers using those addresses cannot legally access the Internet. From the perspective of the routers, these addresses appear to belong to a network that is different from the Internet. If you have used such addresses, you may find that it is impractical to change them to valid internal addresses. The address hiding translator maintains the integrity of your internal addressing schemes by mapping registered IP addresses to all internal addresses, including invalid addresses.

Note Invalid IP addresses are also referred to as reserved addresses, which are IP addresses restricted to special purposes, such as internal domain or Internet service provider network usage.

Network address translation solves these problems by temporarily reassigning a registered IP address to an internal computer that requests services across the Internet (or another external network). When residing on a Policy Enforcement Point, the address hiding translator acts as a buffer between the global Internet and the local IP networks called subnets. The internal subnets only require IP addresses that are unique to that subnet level. When a computer on one of these subnets sends traffic out over the Internet (thus traversing the Policy Enforcement Point), the address hiding translator strips the internal IP address (unique for that subnet) from the network packets and replaces that address with a unique external address that is registered and assigned to that subnet or site.

Result: The Mapping panel appears in the View pane.

Step 2 To specify that you want to define an address hiding rule, click Address Hiding (source remapping) in the Select rule type box.

Result: The list of active address hiding rules appears in the Address Hiding list.

Result: A new rule named H# is created in the Address Hiding list.

Step 4 To specify which network object to hide with this rule, click that network or host in the Hide object box under Address Hiding (source remapping).

The Hide object box displays a list of the network objects that reside under the Policy Enforcement Point node for which you are defining this rule. If you do not see the network object that you want to hide, you must define it within the Network Topology tree.

Tips You can lock the Mapping panel by clicking the Lock this view box at the bottom of the panel, and then use a drag-and-drop operation to move a network host from the Network Topology tree onto the Hide object box.

Step 5 To specify the interface, or set of interfaces, from which the network or host will be hidden, click the interface(s) in the from interface(s) box.

The from interface(s) box displays a list of the interfaces directly attached to the Policy Enforcement Point. However, this list does not contain the interface to which the network or host that you want to hide is attached. You cannot hide a network or host from the interface to which it is attached.

When you hide a network or host from an interface, you are declaring that any network object attached to that interface cannot use the real address to access the hidden network object. Instead, such network objects must deliver all network traffic to one of the addresses specified in the using address and through    with boxes (presumably, the address assigned to the interface to which the network objects are attached). The Policy Enforcement Point acts as a proxy agent between the hidden objects and the interface objects by mapping between the two addresses. However, this mapping only occurs for communications that originate from the hidden object.

Tips To select more than one value from this list, press and hold the Shift key or the Ctrl key while selecting an item in the list. The Shift+Click option enables you to select a sequential set of values. The Ctrl+Click option enables you to select values in any order.

Step 6 To specify the IP address, or starting address of an IP range, that the internal network object address(es) will be remapped to, type that IP address in the using address box.

This value is the specific alias IP address to which you want to translate the real addresses of the translated object. If the value in the through    with box is also specified, this address identifies the starting address of the IP range that will be used to translate the network object. However, you can define exactly one address. If the Policy Enforcement Point is exposing the network object to users on the Internet, this IP address must be a valid IP address that is registered with ARIN.

Step 7 To specify the ending address of the IP range that the internal network object address(es) will be remapped to, type that IP address in the through    with box.

This value identifies the ending alias IP address in an IP address range that will be used for this translation rule. If the Policy Enforcement Point is exposing the network object to users on the Internet, this IP address must be a valid IP address that is registered with ARIN.

Step 8 To specify the network mask value of the IP range that the internal network object address(es) will be remapped to, type that value in the mask box.

This value identifies the mask of the network on which IP address(es) used as aliases are members. It represents the number of bits in the netmask.

Step 9 (PIX Firewall only: Optional) To specify the maximum number of simultaneous connections for this rule, type that value in the MaxC box.

This value is a whole number that represents the maximum number of simultaneous connections that can use this translation rule. The Policy Enforcement Point enforces this value against new session requests. Use 0 (zero) to specify the default value assigned to the Policy Enforcement Point.

This value is a whole number (smaller than the MaxC value) that represents the maximum number of simultaneous embryonic links that can use this translation rule. The Policy Enforcement Point enforces this value against new session requests by restricting the number of session requests that have not completed the handshake. This feature enables you to guard against TCP_SYN attacks. Use 0 (zero) to specify the default value assigned to the Policy Enforcement Point.

Step 11 For each new rule that you want to create, repeat Steps 3 through 10.

Step 12 To accept your changes and close the selected panel, click OK.

Step 13 To save any changes that you have made, click Save on the File menu.

Result: The Mapping panel appears in the View pane.

Step 2 To specify that you want to change an address hiding rule, click Address Hiding (source remapping) in the Select rule type box.

Result: The list of active address hiding rules appears in the Address Hiding list.

Step 3 To specify which rule you want to change, click that rule in the list of rules under Address Hiding.

Step 4 To change the network or host that you want to hide, click the new network or host in the Hide object box under Address Hiding (source remapping).

The Hide object box displays a list of the networks and hosts that reside under the Policy Enforcement Point node for which you are defining this rule. If you do not see the network or host that you want to hide, you must define it within the Network Topology tree.

Tips You can lock the Mapping panel by clicking the Lock this view box at the bottom of the panel, and then use a drag-and-drop operation to move a network host from the Network Topology tree onto the Hide object box.

Step 5 To specify that you want to hide the network from a different interface or set of interfaces, click the new interface(s) in the from interface(s) box.

The from interface(s) box displays a list of the interfaces attached to the Policy Enforcement Point. However, this list does not contain the interface to which the network or host that you want to hide is attached. You cannot hide a network or host from the interface to which it is attached.

When you hide a network or host from an interface, you are declaring that any network object attached to that interface cannot use the real address to access the hidden network object. Instead, such network objects must deliver all network traffic to one of the addresses specified in the using address box (presumably, the address assigned to the interface to which the network objects are attached). The Policy Enforcement Point acts as a proxy agent between the hidden network object and the interface objects by mapping between the two addresses. However, this mapping only occurs for communications that originate from the hidden network or host.

Tips To select more than one value from this list, press and hold the Shift key or the Ctrl key while selecting an item in the list. The Shift+Click option enables you to select a sequential set of values. The Ctrl+Click option enables you to select values in any order.

Step 6 To change the IP address, or set of addresses, that the internal network/host address is remapped to, click the new IP address(es), in the using address box, that are assigned to the Policy Enforcement Point's network adapter card from which the external requests will originate.

These addresses identify the IP addresses, which are assigned to network adapter cards on the Policy Enforcement Point, that external servers will see when they receive a network packet that originated from the internal network or host that you are hiding. One of these addresses will appear as the source address of these network packets. The algorithm by which these addresses are applied is as follows:

1. Test the first address in list to see if the original transport layer port of the session request is available. If it is, that address/port pair is used.

2. Test the next address/original transport layer port until a match is found or the list of addresses is exhausted.

3. Test the first address in list to find the first available port. If no port is available for that address, test the next address in the list to find an available port. This step is repeated until an available port is found for one of the addresses in the list.

Step 7 For each new rule that you want to change, repeat Steps 3 through 6.

Step 8 To accept your changes and close the selected panel, click OK.

Step 9 To save any changes that you have made, click Save on the File menu.

Result: The Mapping panel appears in the View pane.

Step 2 To specify the rule type that you want to view, click Address Hiding (source remapping) in the Select rule type box.

Step 3 To review the list of active rules, scroll through the list under Address Hiding.

Step 4 To close the selected panel, click OK.

To summarize, the organization in the example above wants to end up with the following traffic flows:

• Traffic can flow from Site A to Site B using the Backbone Network only

• Traffic from Site A, Site B, or the Internet cannot flow across the Management Network

• Traffic from the Management Network can traverse Site A or Site B to reach the Internet, as long as it does not traverse the Backbone Network

• Route Generation Savings. Flow restrictions also enable the Policy Server Point to generate fewer routes, which reduces the Policy Server Point's execution time. In terms of how long it takes you to generate the derived command sets, route generation is the second most expensive operation performed by Cisco Secure Policy Manager.

• Intra-gateway flow restrictions

• Inter-gateway flow restrictions

• Regional flow restrictions

The following sections describe these three types of flow restrictions, explain what effects flow restrictions have across your network, and identify when you should define the different types of flow restriction.

Each path restriction rule used to define an intra-gateway flow restriction reads as follows:

• Disable the path to the specified interface on the selected gateway object from an interface on the same gateway object.

You can define an intra-gateway flow restriction for any of six possible flows:

• Gw1a:Gw1b

• Gw1a:Gw1c

• Gw1a:Gw1d

• Gw1b:Gw1c

• Gw1b:Gw1d

• Gw1c:Gw1d

When you define an intra-gateway flow restriction, you must first select the particular intra-gateway flow that you want to restrict, and then define a path restriction rule for both directions of that flow. To define the two required path restriction rules, use the following algorithm:

FOR the first interface in the pair 
define a path restriction rule from the second interface; 
FOR the second interface in the pair 
define a path restriction rule from the first interface;
 

As an example, we can define two path restriction rules on gateway object Gw1 that will prevent network traffic between interface Gw1a and interface Gw1b, which identifies the intra-gateway flow Gw1a:Gw1b. The two following rules restrict this specific flow:

• Disable paths to "Gw1a" from interface(s) "Gw1b."

• Disable paths to "Gw1b" from interface(s) "Gw1a."

By preventing the paths in both directions of the flow, we effectively prevent traffic between these two interfaces.

Each path restriction rule used to define an inter-gateway flow restriction reads as follows:

• Disable the path to the specified interface on the remote gateway object from an interface on the selected gateway object.

Assuming that Gw1c is connected to Gw2a, then nine inter-gateway flows are possible:

Gw1a:Gw2a (invalid)	Gw1c:Gw2a (invalid) 
Gw1a:Gw2b	Gw1c:Gw2b (invalid)
Gw1a:Gw2c	Gw1c:Gw2c (invalid) 
Gw1a:Gw2d	Gw1c:Gw2d (invalid)
Gw1b:Gw2a (invalid)	Gw1d:Gw2a (invalid) 
Gw1b:Gw2b	Gw1d:Gw2b 
Gw1b:Gw2c	Gw1d:Gw2c 
Gw1b:Gw2d	Gw1d:Gw2d
 

When you define an inter-gateway flow restriction, you must first select the particular inter-gateway flow that you want to restrict, and then define a path restriction rule to stop the flow in each direction (each symmetric path). In other words, you must define a path restriction rule to prevent the flow from the first gateway object and then define a path restriction rule to stop the same flow from the second gateway object.

A pair of paths is considered to be a flow only when each of those paths traverses the same gateway object. You can define a path restriction rule only in cases where the path traverses (enters at one interface and exists via a different interface) the gateway object on which the rule is being defined. The reason for this traversal requirement is that intrinsically a Policy Enforcement Point cannot affect a packet unless it traverses that Policy Enforcement Point; also, because the default security stance is "deny all" unless that service is explicitly permitted, it is ultimately the Policy Enforcement Points that are responsible for enabling the traffic flows and the network services permitted along those flows. To control specific traffic flows, Cisco Secure Policy Manager enables you to define path restriction rules on a per-interface basis.

This traversal requirement is illustrated in the preceding example, in which Gw1c is connected to Gw2a. This particular connection (marked invalid in the list of possible flows above) does not represent a flow because it does not traverse either Gw1 or Gw2. The other connections that are marked invalid traverse either Gw1 or Gw2, but not both, making them asymmetric flows. In the examples throughout this section, we assume that each interface is connected to a unique network segment unless it is directly connected to another interface in the examples.

Determining Symmetric Inter-gateway Flows

Each path restriction rule used to define a regional flow restriction reads as follows:

• Disable the path(s) to the specified interface (with respect to the region) on the remote gateway object from each external interface on the selected gateway object.

Assuming that Gw1b, Gw2b, and Gw3c collectively are the interfaces that bound Region Z, then five regional flows are possible:

Gw1a:Gw2a	Gw2a:Gw3a 
Gw1a:Gw2b (invalid)	Gw2a:Gw3b 
Gw1a:Gw3a 	Gw2a:Gw3c (invalid) 
Gw1a:Gw3b 	Gw1a:Gw3c (invalid)
Gw1b:Gw2a (invalid)	Gw2b:Gw3a (invalid) 
Gw1b:Gw2b (invalid)	Gw2b:Gw3b (invalid) 
Gw1b:Gw3a (invalid)	Gw2b:Gw3c (invalid) 
Gw1b:Gw3b (invalid) 	Gw1b:Gw3c (invalid)
 

When you define a regional flow restriction, you are building on the inter-gateway flow restriction algorithm by defining an inter-gateway flow restriction for each flow that traverses the defined region. To define path restriction rules, use the following algorithm:

FOR each gateway bordering the region (Active Gateway) 
	DO FOR each external interface on all other bordering gateways on the region 
		DO define a path restriction rule from the external interface(s) on Active Gateway; 
	END; \ FOR each external interface 
END; \ FOR each gateway

From this high-level perspective, you can treat a particular region as a single gateway object because the goal of defining path restriction rules is to prevent traffic from traversing the multiple paths across that region. Paths can begin or end in a region, but they are not allowed to traverse it. The way that you manage a gateway object is analogous in that you are essentially preventing traffic flows from one interface to another on the same gateway.

Recall that the organization described at the beginning of this section wants to end up with the following traffic flows:

• Traffic can flow from Site A to Site B using the Backbone Network only

• Traffic from Site A, Site B, or the Internet cannot flow across the Management Network

• Traffic from the Management Network can traverse Site A or Site B to reach the Internet, as long as it does not traverse the Backbone Network

Assuming that we want to have these traffic flows, we must prevent the following specific symmetric traffic flows:

• Gw1b:Gw2b. This regional flow restriction prevents any traffic from traversing the Internet (all flows between Site A and Site B via the Internet).

• Gw5a:Gw6a. This regional flow restriction prevents any traffic between Site A and Site B from traversing the Management Network (and, therefore, flows from the Internet across the Management Network between Site A and Site B).

• Gw3b:Gw3c. This intra-gateway flow restriction prevents Management Network traffic from traversing the Backbone Network to reach Site B by first traveling toward Site A and then traversing the Backbone Network (and, therefore, prevents the Management Network from using one path to the Internet over the Backbone Network).

• Gw4b:Gw4c. This intra-gateway flow restriction prevents Management Network traffic from traversing the Backbone Network to reach Site A by first traveling toward Site B and then traversing the Backbone Network (and, therefore, prevents the Management Network from using the remaining path to the Internet over the Backbone Network).

We can further refine the permitted flows to ensure that all traffic flowing between the Management Network and the Internet travels across Site B (not Site A). To prevent the flow across Site A, we define the inter-gateway flow restriction Gw1a:Gw5b.

Result: The Mapping panel appears in the View pane.

Step 2 To specify that you want to define a path restriction rule, click Path Restrictions in the Select rule type box.

Result: The list of active path restriction rules appears in the Path Restrictions list.

Step 3 To begin defining a new path restriction rule, click Insert Rule.

Result: A new rule named R# is created in the Path Restrictions list.

Step 4 To specify the network object to/from which you want to restrict network traffic, click that network object in the Disable paths to box under Path Restrictions.

The Disable paths to box displays a list of network objects that reside under the Network Topology tree. If you do not see the network object to/from which you want to restrict a specific network path, you must define it within the Network Topology tree. However, you can select neither Host nor IP Range nodes. To refer to an interface on another Policy Enforcement Point, you must select the interface by navigating the tree shown in the Disable paths to box in the Mapping panel. The interfaces are not first-level objects in the Network Topology tree in the Navigator pane.

Step 5 To specify the interface, or set of interfaces, that will enforce the path restriction rule, click that interface(s) in the from interface(s) box.

The from interface(s) box displays a list of the interfaces attached to the Policy Enforcement Points that can enforce the path restriction rule. If you are defining a rule on a specific Policy Enforcement Point, only the interfaces on that Policy Enforcement Point are presented as options for enforcing the rule. However, this list does not contain the interface to which the network object to which you are disabling the paths is attached. You cannot hide a network object from the interface to which it is attached.

When you disable paths to a network object from an interface, you are declaring that any packets received from or sent to that network object will not be permitted to traverse the selected interface(s). In other words, these interfaces cannot be used to reach the network object.

Tips To select more than one value from this list, press and hold the Shift key or the Ctrl key while selecting an item in the list. The Shift+Click option enables you to select a sequential set of values. The Ctrl+Click option enables you to select values in any order.

Step 6 For each new rule that you want to create, repeat Steps 3 through 5.

To verify that the path restriction rule you are defining is a valid path restriction rule, ensure that the flow that you want to restrict actually traverses the gateway object on which you are defining this rule.

Step 7 To accept your changes and close the selected panel, click OK.

Step 8 To save any changes that you have made, click Save on the File menu.

Result: The Mapping panel appears in the View pane.

Step 2 To specify that you want to change a path restriction rule, click Path Restrictions in the Select rule type box.

Result: The list of active path restriction rules appears in the Path Restrictions list.

Step 3 To select the path restriction rule that you want to modify, click that rule in the Path Restrictions list.

Step 4 To modify the network object to/from which you want to restrict network traffic, click the new network object in the Disable paths to box under Path Restrictions.

The Disable paths to box displays a list of the network objects that reside under the Network Topology tree. If you do not see the network object to/from which you want to restrict a specific network path, you must define it within the Network Topology tree. However, you can select neither Host nor IP Range nodes.

Step 5 To modify the interface, or set of interfaces, that currently enforces this path restriction rule, click the new interface(s) in the from interface(s) box.

The from interface(s) box displays a list of the interfaces attached to the Policy Enforcement Points that can enforce the path restriction rule. If you are defining a rule on a specific Policy Enforcement Point, only the interfaces on that Policy Enforcement Point are presented as options for enforcing the rule. However, this list does not contain the interface to which the network object to which you are disabling the paths is attached. You cannot hide a network object from the interface to which it is attached.

When you disable paths to a network object from an interface, you are declaring that any packets received from or sent to that network object will not be permitted to traverse the selected interface(s). In other words, these interfaces cannot be used to reach the network object.

Tips To select more than one value from this list, press and hold the Shift key or the Ctrl key while selecting an item in the list. The Shift+Click option enables you to select a sequential set of values. The Ctrl+Click option enables you to select values in any order.

Step 6 For each new rule that you want to change, repeat Steps 3 through 5.

To verify that the path restriction rule you are defining is a valid path restriction rule, ensure that the flow that you want to restrict actually traverses the gateway object on which you are defining this rule.

Step 7 To accept your changes and close the selected panel, click OK.

Step 8 To save any changes that you have made, click Save on the File menu.

Result: The Mapping panel appears in the View pane.

Step 2 To specify the rule type that you want to view, click Path Restrictions in the Select rule type box.

Step 3 To review the list of active rules, scroll through the list under Path Restrictions.

Step 4 To close the selected panel, click OK.