Other Advanced Features

The Cisco PIX firewall has many other security features. Some of these features can be used to protect the network against various DoS attacks. Some of them are related to the processing of routing information—both unicast and multicast.

Fragmentation Guard

Fragmented packets are a challenge to firewalls. For example, nothing in the current Internet standards prevents a person from sending IP packets so fragmented that IP addresses of source and destination and TCP port information are located in different fragments or even in overlapping fragments. The firewall cannot decide on what to do with the packet until it sees the entire TCP/IP header. Some firewalls simply pass the fragments without trying to reassemble the original packets, whereas others try to perform this reassembly. Reassembly can be a dangerous process—for example, it is very easy to send fragments that will cause the reassembled packet to be of illegal size, possibly crashing internal buffers of the IP stack implementation.

The PIX always performs reassembly of fragmented packets before they are checked against access lists and can impose some restrictions on the fragmented traffic that passes through it. The FragGuard feature, when turned on, ensures that:

• Each noninitial IP fragment is associated with an already seen initial fragment (teardrop attack prevention).

• The rate of IP fragments is limited to 100 fragments per second to each internal host.

This feature theoretically breaks some rules of processing fragmented packets, but the current state of the Internet is such that heavy fragmentation usually does not occur naturally and almost always is the result of a malicious hacker trying to circumvent firewall rules or flood an Internet host. Therefore, in general, it is much better to have this feature on, unless you are connected via some strange link that does have a lot of fragmentation—but again, in this case there might be something wrong with the link itself.

This feature is disabled by default and can be turned on or off on all interfaces simultaneously only. The command for enabling it is sysopt security fragguard.

The corresponding no command turns the feature off. The status of various settings, including FragGuard, can be checked with the show sysopt command.

Note

The most important side effect of FragGuard is that you could lose the communication with hosts running some versions of Linux if they do fragment IP packets. These versions do not always send the initial fragment first, so the PIX firewall will discard the received sequence of fragments. Although this rarely occurs, you should still watch out for it.

FragGuard settings can be too restrictive at times. It is possible to manually tune the process of virtual reassembly with the fragment set of commands. Their syntax is as follows:

fragment size <database-limit> [<interface>] fragment chain <chain-limit> [<interface>] fragment timeout <seconds> [<interface>] clear fragment

The first command sets the maximum number of blocks that can be used for fragment reassembly. If an interface is not specified, the setting is global; otherwise, this setting is for the specific interface. The default number of blocks is 200 and should never be greater than the total number of available blocks of 1550 bytes' size. In general, a bigger database makes PIX more vulnerable to a DoS attack by flooding it with fragments and exhausting its memory.

The second command sets the maximum allowed number of fragments into which one IP packet is split. The default setting is 24 fragments; the maximum is 8200. Further fragments will be discarded and the packet will not be reassembled. The timeout setting specifies the time frame in which all fragments of one IP packet should be received. The default timeout is 5 seconds and can be up to 30 seconds.

The last command, clear fragment, resets all three settings to their default values. The state of fragments database can be displayed with the show fragment command:

pix(config)# show fragment outside Interface:outside Size:200, Chain:24, Timeout:5 Queue:150, Assemble:300, Fail:0, Overflow:0

This output shows that the database has default settings: the size of 200 blocks, 24 fragments in a chain, 5-second timeout. There are 150 packets waiting to be reassembled, 300 were already successfully reassembled, and there were no failures or database overflows.

AAA Floodguard

Another flood-related problem is that somebody can abuse the PIX AAA authentication mechanism simply by making a large number of login attempts without providing any login information, leaving the connections open. The PIX firewall will then wait until a timeout expires. By making enough attempts, it is possible to exhaust AAA resources so that no further login attempts will be answered—a DoS on login resources. In order to prevent this situation, the PIX firewall has an internal mechanism for reclaiming AAA resources. It is called Floodguard and is enabled by default. When enabled, Floodguard causes the PIX firewall to monitor resource usage and send a syslog message when these resources are exhausted. When in need of additional resources, the PIX firewall will reclaim the ones that are not in active state. This is done in the following order (by priority):

1. Resources that are in the Timewait state are reclaimed.

2. Resources in the Finwait state are reclaimed.

3. Embryonic resources are reclaimed.

4. Idle resources are reclaimed.

Commands (Configuration mode) related to this feature are floodguard enable, floodguard disable, and show floodguard. As these commands are relatively self-explanatory, we will not delve into them here.

SYN Floodguard

Another well-known DoS attack is SYN flooding, which occurs when an attacker sends large numbers of initial SYN packets to the host and neither closes nor confirms these half-open connections. This causes some TCP/IP implementations to use a great deal of resources while waiting for connection confirmation, preventing them from accepting any new connections before the backlog of these half-open connections is cleared. The easiest way to prevent this from happening is to control the rate at which new connections are opened or the number of connections that are half-open (other names for this are SYN Received or embryonic) at any given time. The latter can be performed by specifying a limit on the number of embryonic connections in the static and nat configuration commands. For example:

PIX1(config)# static (dmz, outside) 123.4.5.6 10.1.1.0 netmask 255.255.255.255 100 50 

This creates a static NAT entry for the DMZ server 10.1.1.0 with an external IP address of 123.4.5.6. The number 100 means that only 100 connections to this server from outside can be in an open state at any given time, and the number 50 is the number of half-open or embryonic connections to this server that can exist at any given time. The nat command is similar: Two numbers at the end specify the number of open and embryonic connections that can exist at any given time to each translated host:

nat (inside) 1 10.0.0.0 255.0.0.0 100 50 

When any of these numbers is zero, the number of connections is not limited. The actual behavior of PIX when the number of embryonic connections is reached for a host is different in v5.2 and later (since 5.3).

The TCP Intercept Feature in PIX v5.3 and Later

The implementation of SYN Floodguard in versions before 5.3 was not quite good. When the maximum number of embryonic connections for a host was reached, the PIX firewall simply discarded any further SYN packets directed to the affected host. Thus, while protecting the host against overloading, the PIX firewall prevented any traffic from passing to or from the host in the case of a SYN flood. Similarly, when the maximum number of embryonic connections was not specified, the PIX did not restrict the number of half-open connections, which could lead to a successful SYN flood attack against the host.

Version 5.3 implements a new feature called TCP Intercept. Since v5.3, the PIX firewall behaves differently when the number of embryonic connections for a host is reached. If this happens, until the number of embryonic connections falls below threshold, each new SYN packet to the affected host is intercepted instead of being discarded. Then PIX itself replies to the sender instead of the destination server with SYN/ACK. If the client finally replies with a legitimate ACK, the PIX firewall sends the original SYN to its destination (the server), performs a correct three-way handshake between the PIX and the server, and the connection is resumed between a client and a server.

Figure 10.09 illustrates how the TCP Intercept feature works.

Figure 10.09: TCP Intercept in PIX v5.3 and Later

Reverse-Path Forwarding

The concept of reverse-path forwarding (RPF) is rarely understood well, although it is rather simple. The basic idea is to have an extensive routing table and, for each packet arrived, check its source address against this table. This is why it is called "reverse" lookup. When a route to this source is found (that is, when there is a reverse path to the source), it is ensured that the packet has arrived on the same interface that is listed in the corresponding route entry (so the packet has arrived on the best path back to its origin). If the interface is correct, the packet has arrived from a verifiable source and is legitimate. If a reverse route is not found or the packet arrived on a wrong interface, it is presumed that the packet is spoofed, and it is discarded.

This feature is used for implementing ingress and egress filtering as specified in RFC2267. It is turned off by default and can be enabled on a specific interface using the following configuration command:

ip verify reverse-path interface <interface_name>

Ingress filtering is used for checking that outside hosts really have outside addresses, but because the PIX firewall cannot maintain the table of all possible routes on the Internet, most configurations check that packets arriving to the outside interface from the Internet do not have an "inside" source address. Egress filtering does exactly the opposite: It checks that the packets going to the Internet actually have internal source addresses. This filtering makes tracing any packet back to its origin much easier and prevents most spoofing attacks. Although this can all be accomplished using access lists, the RPF feature provides a much easier and more elegant solution.

Let's consider the following example:

PIX1(config)# ip address inside 192.168.1.254 255.255.0.0 PIX1(config)# route inside 192.168.2.0 255.255.255.0 192.168.1.254 1 PIX1(config)# route inside 192.168.3.0 255.255.255.0 192.168.1.254 1 PIX1(config)# ip address outside 1.2.3.1 255.255.255.0 2 PIX1(config)# route outside 0.0.0.0 0.0.0.0 1.2.3.127 PIX1(config)# ip verify reverse-path interface outside PIX1(config)# ip verify reverse-path interface inside 

Here, two networks—192.168.2.0/24 and 192.168.3.0/24—are connected to the inside interface, and corresponding entries are created in the routing table. The outside interface has a default route to 1.2.3.127. The RPF feature is enabled on both interfaces. Now, when a packet arrives from the network attached to the inside interface, its source address is checked against the routing table. If this address belongs to one of the two networks 192.168.2.0/24 or 192.168.3.0/24, the route lookup succeeds and the packet is allowed to pass through the firewall. If the address is not from either of these networks, no route will be found, and the packet will be discarded.

If a packet arrives from the Internet to the outside interface, its source is also checked because RPF is active on the outside interface. If this address belongs to one of the networks 192.168.2.0/24 or 192.168.3.0.24, route lookup succeeds, but it is noted that this packet has not arrived on the best path to its origin. (The best path goes through the inside interface.) The packet is obviously a spoofed one and it is dropped. In all other cases, the route lookup also succeeds because there is a default route on the outside interface and the packet is permitted to pass through. Thus, ip verify reverse-path interface inside provides egress filtering, whereas ip verify reverse-path interface outside provides ingress filtering.

Note

There are several limitations on using RPF verification. If there is no default route on the outside interface, only the networks mentioned in the routing table are able to send packets to the hosts behind the firewall. In addition, do not turn on RPF verification before routing is fully specified, for the same reason. If your network has asymmetric routing, RPF verification will not work correctly.

If in this configuration we omit RPF verification on the outside interface, only egress filtering on the inside interface will be performed, and spoofed packets from the Internet will be allowed to pass through, whereas any spoofing attempts by inside hosts will be stopped. If RPF verification is enabled only on the outside interface and routes to internal networks are provided, only ingress routing will be performed; outside packets with source IPs belonging to internal networks will be dropped.

RPF-related statistics can be viewed with the following command:

pix(config)# show ip verify statistics interface outside: 5 unicast rpf drops interface inside: 2 unicast rpf drops

Counters here show the number of packets dropped by unicast RPF. The number of RPF drops can also be seen in show interface results:

pix(config)# show interface interface ethernet0 "outside" is up, line protocol is up Hardware is i82559 ethernet, address is 00aa.0000.003b IP address 1.2.3.4, subnet mask 255.255.255.224 MTU 1500 bytes, BW 100000 Kbit half duplex 1183242 packets input, 1222000001 bytes, 0 no buffer Received 210 broadcasts, 23 runts, 0 giants 4 input errors, 0 CRC, 4 frame, 0 overrun, 0 ignored, 0 abort 1311231 packets output, 565432270 bytes, 0 underruns, 0 unicast rpf drops 0 output errors, 12332 collisions, 0 interface resets 0 babbles, 0 late collisions, 12342 deferred 0 lost carrier, 0 no carrier input queue (curr/max blocks): hardware (128/128) software (0/1) output queue (curr/max blocks): hardware (0/2) software (0/1) 

Line 8 of this output contains a message 0 unicast rpf drops; this means there were no drops on this interface.

Not all packets are checked with RPF. What actually happens is:

• ICMP packets are all checked because there is no session state for these types of communication.

• TCP and UDP communications have session information maintained by PIX, so only an initial packet is checked against the routing table. All subsequent packets are checked only for the interface they arrived on. This interface should be the interface on which an initial packet arrived.

The clear ip verify reverse-path, and clear ip verify statistics commands respectively delete ip verify commands from the configuration and clear packet counts,.

Unicast Routing

In this section, we describe some more advanced topics related to unicast routing as performed by the PIX firewall.

Static and Connected Routes

You have already learned how to configure static routes on the PIX firewall using the route command:

route <interface> <ip_address> <netmask> <gateway_address> [<metric>]

For example:

PIX1(config)# route outside 0.0.0.0 0.0.0.0 1.2.3.4 

This command configures a static default route on the outside interface to the gateway 1.2.3.4—a default gateway to be used for network traffic. If you issue a show route command, the output will include the following line:

route outside 0.0.0.0 0.0.0.0 1.2.3.4 1 OTHER static

The keyword OTHER simply means that this route is a manually entered static route. There is one interesting variation to the route command: It is possible to specify an IP address of PIX's own interface instead of a gateway address. This might seem strange from the point of view of the classic static routing, but this is sometimes very useful, especially in a Cisco infrastructure. The PIX itself automatically creates routes of this type when you enter an IP address for an interface.

So, what happens when a route is set to the PIX interface? The simple answer is that the PIX firewall considers the network directly connected and sends an ARP request for the destination address itself instead of requesting for gateway's destination and forwarding the packet to the gateway. The destination host does not really have to be directly connected; if it is connected via a router that has a proxy-arp feature turned on, the router will reply on behalf of the host, the PIX will forward the packet to this router, and the router in turn will forward the packet to the host. Cisco routers and PIX firewalls have proxy ARP turned on by default. For example, if the inside interface has an IP address of 192.168.1.254/24 and two networks, 192.168.2.0/24 and 192.168.3.0/24, are connected to this interface via a router, the following two statements will configure correct routes to these networks (note that the router's IP is not used anywhere; it just has to be in the same network as the inside interface of the PIX):

PIX1(config)# route inside 192.168.2.0 255.255.255.0 192.168.1.254 PIX1(config)# route inside 192.168.3.0 255.255.255.0 192.168.1.254 

The show route command displays the corresponding entries in the routing table as:

route inside 192.168.1.0 255.255.255.0 192.168.1.254 1 CONNECT static route inside 192.168.2.0 255.255.255.0 192.168.1.254 1 OTHER static route inside 192.168.3.0 255.255.255.0 192.168.1.254 1 OTHER static

The first entry here was created automatically by the PIX firewall when an IP address was configured on the inside interface. The other two are the result of our two static route entries.

What exactly happens when the default route (outside interface) on the PIX is set to itself? The sequence of steps PIX performs to correctly forward the packet is as follows:

1. The PIX receives a packet on the inside interface destined for the Internet host with IP a.b.c.d.

2. The default route on the outside interface is set to the interface itself. If a separate default gateway was specified, the PIX would simply ARP for the gateway's address and forward the packet there. If not, the PIX sends an ARP request for IP a.b.c.d.

3. Any router (assuming it has proxy ARP turned on) that has a route to a.b.c.d replies with its MAC address on behalf of the host a.b.c.d.

4. The PIX forwards the packet to this router, which will handle it from there.

5. The PIX also adds an entry to its ARP table for IP address a.b.c.d with the MAC address of the router.

The PIX firewall also has the proxy ARP feature turned on by default, so it can act in the same way as the router in the previous example. It is possible to turn the feature off on a specific interface using:

sysopt noproxyarp <interface>

Note

In case you have not heard the phrase, "one-armed" routing means that the router has only one interface (with more than one IP address on it). All it does is receive a packet from the network and redirect it to another router/host on the same LAN but maybe on another IP network. This is sometimes useful, but PIX cannot do this, because its Adaptive Security Algorithm does not allow any packet to exit on the same interface as it arrived.

Combined with the default proxy ARP feature, this feature can play tricks on your routing. For example, if a router is behind an inside interface and some host sends an ARP request for this router's IP, PIX will reply instead (or together with the router) and the packet is forwarded to the PIX. Here comes the problem: The packet needs to be forwarded to the real router, but PIX cannot do this; the packet cannot exit on the same interface.

So, if you prefer to completely control your static routing and you have created all static routes with correct gateways, it is always better to turn off proxy ARP on all interfaces; it has a nasty habit of getting in the way.

Routing Information Protocol

Beside static routes, the PIX firewall also supports Routing Information Protocol (RIP) v1 and v2. This protocol is the simplest dynamic routing protocol and is described in RFCs 1058, 1388, and 2082. Roughly speaking, a router broadcasts (or it may use multicast in v2) its entire routing table to its neighbors, and they update their tables.

Each PIX interface can be configured either to broadcast (multicast) itself as a default route for the network or to passively listen for routing updates from other routers on the LAN. The simple syntax of the RIP configuration command is as follows:

rip <if_name> [default | passive] version [1 | 2]

The default and passive keywords define the mode RIP runs on the interface if_name. The default parameter specifies that a default route should be advertised, and passive means listening for updates from other routers. The version parameter specifies the version of RIP to use on the interface. If a version is not specified, version 1 is assumed. The major differences between RIPv1 and RIPv2 are that RIPv2 can use multicast to the address 224.0.0.9 instead of broadcasts and that it can use authentication. RIPv1 uses broadcasts only and no authentication of updates. RIPv2 is also a classless routing protocol, which means that it can exchange routing information for networks such as 172.16.1.0/24, whereas RIP v1 uses only networks of A, B, and C classes—for example, Class B network 171.16.0.0/16. Generally, it is better to use RIPv2 if there is no need to interact with older RIPv1 devices.

Note

Before PIX v5.3, the PIX firewall was capable of using only broadcasts for RIPv2. Versions 5.3 and later use multicast to the address 224.0.0.9. By default, when you use RIPv2 on the PIX, it sends updates to 224.0.0.9. If passive mode is configured with RIPv2, the PIX accepts multicast updates with the address of 224.0.0.9, and this multicast address is registered on the corresponding interface. Only Intel 10/100 and Gigabit interfaces support multicasting. When RIP configuration commands are removed from the configuration, this multicast address is unregistered from the interface.

If you have a router that talks multicast RIPv2 to an older PIX (before v5.3), the PIX will not receive any updates. It is possible to switch the router into unicast mode using a command neighbor <pix_address> in its RIP configuration section. The PIX is capable of receiving unicast updates in any version that supports RIP.

Here is an example of RIP v1 configuration:

PIX1(config)# show rip rip outside passive no rip outside default rip inside passive no rip inside default PIX1(config)# rip inside default PIX1(config)# show rip rip outside passive no rip outside default rip inside passive rip inside default

The first show rip command displays the default state of configuration: all interfaces listen passively. Then the inside interface is configured to broadcast itself as a default route. Note that the passive listening mode was not turned off by this mode; you would need to disable it separately with no rip inside passive if you wanted to turn it off.

RIP v2 also supports two types of authentication: clear-text passwords and MD5 hashes. This feature of RIPv2 protocol adds one more field to the transmitted routing update—an authentication field. It can contain either a cleartext password (not recommended) or a keyed MD5 hash of the whole message. Keyed means that there is a key that is used to compute a hash value of the message. PIX configuration is very simple in both cases: An extra parameter needs to be added to the basic configuration command:

rip <if_name> [default | passive] version 2 authentication [text | md5]  <key_string> <key_id>

For example, the following command uses a clear-text password of mysecretkey while broadcasting the default gateway on the inside interface:

rip inside default version 2 authentication text mysecretkey 1

The following command lists only the messages with a correct MD5 hash keyed by a key anothersecretkey:

rip outside passive version 2 authentication md5 anothersecretkey 2

The key_id parameter (a number at the end of the line) is a key identification value and must be the same on all routers with which the PIX communicates.

RIP authentication on routers is more complicated. You need to set up a key chain with some keys (these keys are numbered and are exactly the key_id you need to provide in configuring PIX) and turn the authentication on. A sample partial router configuration corresponding to our case of MD5 authentication is:

interface ethernet 0  ip rip authentication key-chain mykeys  ip rip authentication mode md5 ! router rip  network 172.16.0.0  version 2 ! key chain mykeys  key 2  key-string anothersecretkey

The clear rip configuration mode command removes all RIP configuration statements from the PIX firewall.

Stub Multicast Routing

IP multicasting is becoming increasingly popular, especially in SOHO environments, where hosts are connected via fast links. Multicasting was introduced as a method of packet delivery to multiple hosts. In broadcasting, each host receives all packets sent by a server. In multicasting, a host must join one or more multicast groups, represented by a specific IP address (these addresses are 224.0.0.0–239.255.255.255) and then it will listen only for packets destined for this group. Of course, the nature of broadcasting and multicasting implies that it can be used only for UDP transmission, because TCP always requires two endpoints.

So how exactly does multicasting work? As noted, there is a set of multicast group addresses (Class D IP addresses, 224.0.0.0 through 239.255.255.255). A group of hosts listening to a particular multicast group address is called a host group. A host group is not limited to one network and can include hosts from many networks at the same time. Membership in a group is dynamic; hosts can enter and leave a group at will. The number of hosts in a group is not limited, and a host does not have to be a member of the group to send a message to this group.

When a host sends a message to a specific group address, this address is not subject to the ARP resolution process. It is simply converted into an Ethernet address by special rules, and an Ethernet frame is sent out with the resulting destination MAC address. If all recipients are on the same physical network, everything else is very simple: Listening hosts decide if the packet is sent to them by looking at the MAC address and its correspondence with the group addresses they are listening on. However, multicast groups are not limited to one network by definition, so there is a need for some means of passing these messages through routers and a means of informing routers if there are any hosts from a specific multicast group on a given physical network. This is done using Internet Group Management Protocol (IGMP).

IGMP is similar to ICMP in that it is also considered part of the IP layer. It is IP protocol number 2. Its basic functionality is as follows:

• When a host joins a multicast group, it informs the router by sending it an IGMP message.

• When a host leaves the group, it does not send any reports about this event (see the next two points).

• A multicast router regularly sends IGMP requests out each of its interfaces requesting connected hosts to report to the multicast groups to which they belong.

• A host responds to the request by sending one IGMP report for each group to which it belongs.

Figure 10.10 illustrates this IGMP exchange.

Figure 10.10: IGMP Used to Report Membership in a Multicast Group

Since v6.2, the PIX can process multicast and IGMP messages. It does not have full capabilities of a multicast router, but it can act as a "stub router" or IGMP proxy agent. An IGMP proxy agent is a device that is able to forward IGMP requests and replies between multicast routers and hosts. When the source and destination of multicast transmissions are divided by a PIX firewall, two obvious cases are possible: when the source of a transmission (or a multicast router) is on a lower security-level interface than the destination and when the source (router) is on a higher security-level interface than the destination. Let's look at these two cases separately.

SMR Configuration with Clients on a More Secure Interface

In this case, a multicast router and a server are on the outside interface of the PIX firewall, and clients are on the inside. The PIX needs to be able to pass multicast traffic from the server and IGMP requests from the router to the inside hosts. It also needs to pass IGMP messages from the internal hosts to the outside router.

All SMR configurations start with the following configuration mode command:

multicast interface <interface> [max-groups <number>]

This command enables multicast features on the specified interface. The interface is placed into multicast promiscuous mode, and it enters a submode of multicast configuration for a specific interface. (This is a rare case with the PIX because there are very few submodes in configuration mode.) An optional max-groups parameter defines the number of multicast groups that can appear on the interface at any given time. The default setting is 500; the number can be up to 2000. This mode has subcommands like igmp <command>.

Note

To set the version of IGMP used, use the igmp version {1 | 2} subcommand under the multicast command.

In our case, the PIX needs at least to be able to receive multicast transmissions on its outside interface, so we need to configure:

PIX(config)# multicast interface outside 

Actually, there is not much more to configure on the outside interface. We can optionally configure some counters and protocol options or access control, but this is not specific for a case and is described later. After exiting this multicast configuration mode (but while we're still in configuration mode), we need to configure multicast on the inside interface:

PIX1(config)# multicast interface inside 

The inside interface requires additional configuration. After we enter this mode, we need to configure the interface to which the PIX should forward all IGMP messages from clients. This is the less secure interface where the router is located:

PIX1(config-multicast)# igmp forward interface outside 

Don't forget that this command is entered while we are in the interface multicast configuration mode. Outside is the interface name to forward IGMP messages to from the interface being configured. If you have a multicast router on an interface named dmz1, the command will look like:

PIX1(config-multicast)# igmp forward dmz1 

If any clients on the inside network are not IGMP-capable, but we still want them to receive multicast traffic from some group, we need to configure the inside interface to join this multicast group statically with the command:

igmp join-group <multicast_address>

For example:

PIX1(config-multicast)# igmp join-group 224.1.1.1 

With this interface configured, the PIX outside interface acts as a host interested in receiving transmissions for this group, and then the received data will be forwarded to the inside network. Here is an example of the simplest multicast configuration:

PIX1(config)# multicast interface outside PIX1(config-multicast)# exit PIX1(config)# multicast interface inside PIX1(config-multicast)# igmp forward interface outside 

Here is a more complicated example with non-IGMP capable multicast clients who want to receive transmissions for group 224.10.0.9:

PIX1(config)# multicast interface outside PIX1(config-multicast)# exit PIX1(config)# multicast interface inside PIX1(config-multicast)# igmp forward interface outside PIX1(config-multicast)# igmp join-group 224.10.0.9 

Clients on two interfaces, inside and dmz:

PIX1(config)# multicast interface outside PIX1(config-multicast)# exit PIX1(config)# multicast interface inside PIX1(config-multicast)# igmp forward interface outside PIX1(config-multicast)# exit PIX1(config)# multicast interface dmz PIX1(config-multicast)# igmp forward interface outside 

SMR Configuration with Clients on a Less Secure Interface

This case is simpler. All you need to do is enable multicast processing on both interfaces and create static multicast routes for passing traffic between the clients and the servers (and routers). Multicast processing is enabled with:

PIX1(config)# multicast interface outside PIX1(config-multicast)# exit PIX1(config)# multicast interface inside 

Multicast routes are created using the mroute command (which is not a subcommand of the multicast command):

mroute <src> <srcmask> <in-if-name> <dst> <dstmask> <out-if-name>

The src and srcmask parameters are the IP address and subnet mask of a multicast source host/router (just normal IP addresses, not multicast addresses.). The in-if-name parameter specifies the interface connected to the source. dst and dstmask are the multicast group address and subnet mask to which the server is sending its transmission. Finally, out-if-name is the interface connected to the multicast clients. For example:

PIX1(config)# mroute 192.168.2.25 255.255.255.255 inside 224.0.1.1 255.  255.255.255 outside 

Here is an example configuration in the case of two servers: 192.168.2.25 on the inside interface multicasting to group 224.1.1.1, and 10.2.3.4 on the dmz interface multicasting to the group 230.1.1.1 and no internal clients:

PIX1(config)# multicast interface outside PIX1(config-multicast)# exit PIX1(config)# multicast interface inside PIX1(config-multicast)# exit PIX1(config)# multicast interface dmz1 PIX1(config-multicast)# exit PIX1(config)# mroute 192.168.2.25 255.255.255.255 inside 224.1.1.1 255.  255.255.255 outside PIX1(config)# mroute 10.2.3.4 255.255.255.255 dmz 230.1.1.1 255.255.255.     255 outside 

Access Control and Other Options

It is possible to restrict access to multicast transmissions using the usual PIX means: access lists. In the preceding case with hosts on the inside interface, we could restrict the groups from which the internal hosts can receive transmissions. For example, to allow only multicast transmissions to a group address 224.1.1.1, you should create an access list similar to this:

PXI1(config)# access-list 10 permit igmp any 224.1.1.1 255.255.255.255 

Then apply it to the outside interface:

PIX1(config)# multicast interface outside PIX1(config-multicast)# igmp access-group 10 

Now only IGMP polls for group 224.1.1.1 will be able to pass through PIX, and thus only members of this group will be known to a multicast router. This prevents the router from sending traffic destined for any other group address in this direction.

Other subcommands of the multicast command include igmp query-interval ,seconds>.This command sets the interval at which IGMP messages will be sent out this interface. The default interval is 60 seconds. The maximum timeout for response (for IGMPv2 only) can be set usingthe igmp query-max-response-time <seconds> command.The default setting is 10 seconds.

Configured settings can be cleared using corresponding clear commands. The following command clears the IGMP cache either for a specific group address or the whole cache on the specified interface:

clear igmp group [<group-addr> | interface <interface-name>] 

The following command clears multicast routes for specified transmission source, for a group address, or all routes on the interface:

clear mroute [<src-addr> | <group-addr> | interface <interface-name>] Another set of commands (show igmp, show multicast [interface <interface-name>],  show igmp group [grou<p-addr> | interface <interface-name>], and show mroute [<src- addr> | <group-addr> | interface <interface-name>])allows viewing of multicast  configuration for the interface, multicast group, routes, and so on. 

An example output of the show igmp command is:

pix(config)# show igmp IGMP is enabled on interface inside Current IGMP version is 2 IGMP query interval is 60 seconds IGMP query timeout is 125 seconds IGMP max query response time is 10 seconds Last member query response interval is 1 seconds Inbound IGMP access group is IGMP activity: 0 joins, 0 leaves IGMP querying router is 10.0.1.1 (this system) IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reported

Two debug commands allow monitoring of multicast-related events. The debug igmp command monitors all IGMP messages passing through the PIX. Whereas the debug mfwd

command monitors all events related to multicast forwarding.

PPPoE

Point-to-Point Protocol over Ethernet (PPPoE), documented in RFC2516, is an encapsulation of Point-to-Point Protocol (PPP, RFC1661) for Ethernet networks (which include DSL modems and cable connections). PPPoE is often used in SOHO environments because it allows ISPs to use their existing remote access infrastructure and, as its most important feature, allows authenticated IP address assignment. PPPoE links are established in two main phases:

• Active discovery phase During this first phase, a PPPoE client attempts discovery of the PPPoE server, also called the address concentrator (AC). The PPPoE layer is established and a session ID is assigned.

• PPP session phase A PPP link is established (encapsulated in Ethernet) by the usual means: options and link layer protocols are negotiated, etc. PPP authentication (PAP, CHAP, or MS-CHAP) is performed.

After the session is established, data travels between endpoints encapsulated in PPPoE headers.

The PIX firewall supports PPPoE since software v6.2. Most of the PPPoE configuration is performed using the vpdn command. PPPoE configuration starts with configuring the username and password to be used by the PIX in establishing a link to the server.

Note

The PIX only supports PPPoE client functionality. PPPoE clients can be enabled only on the outside interface at this time (v6.2).

First, a VPDN group needs to be created:

vpdn group <group_name> request dialout pppoe

The group_name parameter can be anything you like. It is used to group all PPPoE settings together. For example:

PIX1(config)# vpdn group my-pppoe-group request dialout pppoe 

Then the authentication type needs to be selected (if required by an ISP):

vpdn group <group_name ppp> authentication pap | chap | mschap

PAP is Password Authentication Protocol, CHAP is Challenge-Handshake Authentication Protocol, and MS-CHAP is Microsoft's version of CHAP. With the same group name, this command selects an authentication protocol for this specific PPPoE group—for example, with CHAP authentication:

PIX1(config)# vpdn group my-pppoe-group ppp authentication chap 

Your ISP assigns the username and password to your system, and they are configured on PIX with the following commands:

vpdn group <group_name> localname <username> vpdn username <username> password <pass>

The second of these commands associates a username with the password, and the first command assigns the username to be used for a specific group, for example:

PIX1(config)# vpdn group my-ppoe-group localname witt PIX1(config)# vpdn username witt password cruelmail 

These commands assign the username witt and password cruelmail to be used for the PPPoE dial-out group my-pppoe-group. After configuring authentication, the next task is to enable the PPPoE client on the PIX. This is done in the configuration of the outside interface with the ip address outside pppoe [setroute] command. After this command is entered, the current PPPoE session is terminated and a new one is established. The setroute parameter allows automatically setting the default route for the outside interface. The MTU on the outside interface is automatically set to 1492, which is the correct setting to provide PPPoE encapsulation. It is also possible to designate a fixed IP address for the outside interface. The PIX still has to provide the ISP with the correct username and password in order to establish the session:

PIX1(config)# ip address outside 1.2.3.4 255.255.255.0 pppoe 

It is possible to use the dhcp auto_config command if you run the DHCP server on PIX in order to pick up DNS and WINS settings from your provider via the PPPoE client:

PIX1(config)# dhcpd auto_config outside 

To monitor and troubleshoot the PPPoE client, use the following commands:

show ip address outside pppoe debug pppoe event | error | packet show vpdn session pppoe [id <sess_id>|packets|state|window]

Examples of output are as follows:

PIX1(config)# show vpdn Tunnel id 0, 1 active sessions time since change 10240 secs Remote Internet Address 10.0.1.1 Local Internet Address 192.168.2.254 1006 packets sent, 1236 received, 98761 bytes sent, 123765 received Remote Internet Address is 10.0.1.1 Session state is SESSION_UP Time since event change 10237 secs, interface outside PPP interface id is 1 1006 packets sent, 1236 received, 98761 bytes sent, 123765 received PIX1(config)# show vpdn tunnel PPPoE Tunnel Information (Total tunnels=1 sessions=1) Tunnel id 0, 1 active sessions time since change 10240 secs Remote Internet Address 10.0.1.1 Local Internet Address 192.168.2.254 1006 packets sent, 1236 received, 98761 bytes sent, 123765 received PIX1(config)# show vpdn session PPPoE Session Information (Total tunnels=1 sessions=1) Remote Internet Address is 10.0.1.1 Session state is SESSION_UP Time since event change 100238 secs, interface outside PPP interface id is 1 1006 packets sent, 1236 received, 98761 bytes sent, 123765 received