PIX Routing Configuration

Routing represents a multifaceted problem for the PIX Firewall. First, the PIX Firewall is an inline security filter, not a router, and therefore uses static routes to direct traffic out of the interfaces. This nonrouter strategy is reinforced because the PIX interfaces don’t support VLAN trunk links and require a “real” router to perform VLAN termination before forwarding traffic on to the firewall.

Second, Cisco security strategy considers sending routing protocols across any firewall to be a serious vulnerability because corrupted or compromised routes received on the unprotected interface would then be transmitted to the protected side of the firewall.

Finally, the PIX Firewall doesn’t forward broadcast or multicast packets used by most routing protocols. Not forwarding multicasts also has implications for technologies like IP-TV.

This section looks briefly at the route command, and then at possible solutions around the no routing and no multicast restrictions for those exceptional cases. Figure 19-16 shows the router and firewall implementation to use for the examples in this section. The Layer 3 switch connecting the organization’s VLANs to the PIX Firewall could also be a router and Layer 2 switch.

Figure 19-16: Perimeter router, PIX Firewall, and Layer 3 switch implementation

The Route Command

Except for organizations using BGP between their networks and their ISPs, most organizations don’t share a routing protocol with their ISPs. Instead, they use a static default route to the ISP and the ISP uses one or more static routes back. This reduces router overhead on the organization’s routers and limits information about the internal network shared with the outside world, particularly when combined with NAT. The commands for the example in Figure 19-16 might look like the following:

Rtr1(config)#ip route 0.0.0.0 0.0.0.0 10.0.2.1
ISP(config)#ip route 10.1.1.0 255.255.255.0 10.0.2.2

The PIX configuration mode route command performs a similar function for the PIX Firewall. To define a default route, set ip_address and netmask both to 0.0.0.0, or the shortened form of 0. Use the no form of the command or the clear route command to remove the route. The syntax is

Pix(config)# route int_name ip_address netmask gateway_ip [metric]
Pix(config)# no route [int_name ip_address [netmask gateway_ip]]
Pix(config)# clear route [int_name ip_address [netmask gateway_ip]]

gateway_ip	Specify the IP address of the gateway router (the next hop address for this route).
metric	Specify the number of hops to gateway_ip. The default is 1.

For the sample network in Figure 19-16, use the following command to define a default route for outbound traffic:

Pix(config)# route outside 0 0 10.1.1.2 1

In the next example, the PIX Firewall directs all traffic for the protected LANs 192.168.0.0 to 192.168.127.0 to the Layer 3 switch.

Pix(config)# route inside 192.168.0.0 255.255.128.0 192.168.0.2 1

The next example looks at forwarding traffic destined to any shared servers into the DMZ. If the route command uses the IP address of a PIX interface as the gateway IP address, the PIX then recognizes the address as local and uses an Address Resolution Protocol (ARP) request for the destination IP address in the packet instead of the gateway IP address.

Pix(config)# route dmz 192.168.128.0 255.255.255.0 192.168.128.1 1

The show route Command

Use the show route command to confirm static and default route configuration. The CONNECT identifier indicates a local network attached directly to a PIX interface. If the target network is labeled with the CONNECT identifier, the PIX will ARP for the destination address.

Pix# show route
 ?? ??? outside 0.0.0.0 0.0.0.0 10.1.1.2 1 OTHER static
 ? ??? ?inside 192.168.0.0 255.255.128.0 192.168.0.2 1 OTHER static
 ? ? ? ?dmz 192.168.128.0 255.255.128.0 192.168.128.1 1 CONNECT static
Pix#

Routing Options

The PIX Firewall doesn’t allow broadcast and multicast traffic to pass between interfaces. Looking at Figure 19-16, it wouldn’t be possible to exchange routing between the perimeter router Rtr1 and the Layer 3 switch using an Interior Gateway Protocol (IGP), such as Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), or Routing Information Protocol (RIP), all of which use broadcast or multicast packets to exchange routing information.

Possible Workarounds

One possible solution, if it were necessary to send routing updates through the PIX firewall, would be to add neighbor statements to the router configuration on the Layer 3 switch and perimeter router. The neighbor statement causes the routing update to be sent to the neighbor router using a unicast, rather than broadcast or multicast. The following output demonstrates what a RIP configuration on the Layer 3 switch might look like. EIGRP and OSPF would support a similar solution.

router rip
 ?version 2
 ?network 192.168.0.0
 ?network 192.168.1.0
 ?network 192.168.2.0
 ?(other networks omitted)
 ?neighbor 10.1.1.2

The neighbor 10.1.1.2 statement directs routing updates to be sent directly to the perimeter router using a unicast.

Downsides

So, if this is so easy, what’s the problem? This example intentionally took the easy part of the solution. Little security risk occurs in configuring an outside address on this switch and the firewall naturally allows the packets to flow from the inside to the outside. Things get more complicated coming the other way. What address for the L3 switch would need to be used when the neighbor statement is added to the perimeter router? You don’t want to put a “hidden” inside address outside the firewall. Using a translated (static) address and the associated ACL or conduit would involve punching a hole completely through the firewall.

All things considered, this option must be approached carefully, particularly because the Static Route option is within the firewall.

RIP Routing

The PIX Firewall interfaces are configurable for route and RIP information. This means the interfaces can exchange RIP updates with other directly adjacent RIP routers. Unfortunately, those updates still can’t be forwarded through the firewall and none of the other routing protocols is supported.

The configuration mode rip command enables IP routing table updates from RIP broadcasts received directly on the interface. The PIX Firewall still can’t pass RIP updates between interfaces. If RIP version 2 is configured, the RIP updates will be encrypted using MD5 encryption. Use the no rip command to disable the PIX Firewall IP routing table updates. The syntax is

Pix(config)# rip int_name {default | passive} [version [1 | 2]] [authentication [text | md5 key (key_id)]]
Pix(config)# no rip int_name {default | passive} [version [1 | 2]] [authentication [text | md5 key (key_id)]]

int_name	The internal or external network interface name
default	Broadcast a default route on the interface
passive	Enable passive RIP on the interface, allowing the PIX to listen for RIP-routing broadcasts and to add that information to its routing table
version	RIP version. (1) Backward compatibility with the older RIP version. (2) RIP update encryption and VLSM and CIDR support
authentication	Enable RIP version 2 authentication
text	Send RIP version 2 updates as clear text (not recommended)
md5	Send RIP version 2 updates using MD5 encryption
key	Key to encrypt RIP version 2 updates (up to 16 characters). Must be the same on any device that provides RIP version 2 updates
key_id	Key identification value (a number from 1 to 255). Must be the same key_id on any device that provides RIP version 2 updates

The Passive option enables the PIX Firewall to learn about the network by listening for RIP network updates. This is often called routing by rumor. Any networks “discovered” by listening to the interface RIP traffic are added to the PIX Firewall routing tables.

Verifying and Monitoring RIP

The clear rip command removes all the rip commands from the PIX Firewall configuration. The show rip command displays the RIP configuration while the debug rip command turns on real-time monitoring of the RIP exchanges.

Pix# debug rip [int_name]
Pix# show rip [int_name]
Pix# clear rip

The next example demonstrates version 1 and version 2 RIP commands, and the result of the show rip command. The first line turns on RIP v1, the second turns on RIP v2 without authentication, and the third enables RIP v2 with authentication using cisco as the key and 7 as the key_id.

Pix(config)# rip outside passive
Pix(config)# rip dmz passive version 2
Pix(config)# rip inside passive version 2 authentication md5 cisco 7
Pix(config)# show rip
rip outside passive version 1
rip inside passive version 2 authentication md5 cisco 7
rip dmz passive version 2

BGP Routing

Border Gateway Protocol (BGP–RFC 1163) is the routing protocol of the Internet. BGP implementation is complex and well beyond the scope of this text and exams. If an organization needs to pass BGP through a PIX Firewall to achieve redundancy in a multihomed BGP environment, this is made much easier because BGP uses unicast TCP packets on port 179 to communicate with its peers, instead of either broadcast or multicast traffic, which can’t pass through the PIX.

Multicast Traffic

IP TV and other streaming media content applications use IP multicast to deliver the content to the end user while preserving bandwidth. Many routing protocols are also using multicast technologies to reduce bandwidth and disruption to unaffected devices. The problem is the PIX Firewall won’t pass multicast traffic.

The workaround for this is to encapsulate the multicast packets in a GRE tunnel to pass them through the PIX device.

This isn’t an exam requirement and configuring IP multicasting is too complex to go into here. Simply be aware a relatively simple solution exists. Several examples are on the Cisco site: search for PIX Firewall Multicast or PIX Firewall GRE.