| 10.1 |  | Access Control Lists and the PIX Security Appliance |
| 10.1.5 |  | Case study - differences in the behavior of conduits and ACLs |

| Probably the best way to learn how to avoid the most common problems associated with using access lists in the PIX Security Appliance is to look at a case study. This section includes a typical scenario. In the example in Figure , an ACL is bound to the Partnernet interface. The purpose of this ACL is to allow access from the Partnernet clients to the mail server on the internal network, and the user is able to access the mail server. However, the user is unable to access the Internet or the internal FTP server. At first glance, both of the access problems the user is having may seem odd. Normally, with correctly configured NAT and global statements in place, connections from a higher-level interface to a lower-level interface should pass through with no problems. It would also seem that the user should be able to access the internal FTP server because the appropriate static and conduit have been configured. The following page shows the configuration that caused these problems.

The example in Figure shows a portion of the configuration in the PIX Security Appliance on the previous figure. In this example, a new network security specialist was given the task of setting up a partner network and configuring its security. The following instructions were given.

- Allow users on the Partnernet to access the FTP server on the inside.
- Allow users on the Partnernet to access the mail server on the inside.
- Permit all HTTP traffic originating from the Partnernet except that which is destined for the inside network.
- Deny all other traffic originating from the Partnernet.

The Configuration
To accomplish this, the following steps were completed by the security specialist:

- First, NAT and global statements were created to allow outbound access from the Partnernet. This configuration was tested to prove that it was correct.
- Next a static mapping for the internal FTP server 10.0.0.3 address was created. This enabled it to appear to hosts on the Partnernet as 172.18.0.10, an address on that network. Once this was done, a conduit was created to work in conjunction with the static address of the FTP to allow FTP traffic to pass from the inside network to the higher security Partnernet network. Testing confirmed that the configuration had been done correctly and access was permitted from the internal FTP server to the Partnernet.
- Finally, another static statement was created, which mapped the internal mail server 10.0.0.4 address to 172.18.0.12. Because Cisco was moving toward the use of ACLs rather than conduits, it was decided to try using an ACL to permit the traffic instead of a conduit. An ACL permitting Partnernet users to access the statically mapped address of the mail server was created. Again, this part of the configuration was tested successfully.

The Problem
Since all of the testing of the configuration had indicated no problems, the specialist assumed that the configuration was correct. Unfortunately, users on the Partnernet began reporting that although they could send and receive e-mail, access to the Internet or the internal FTP server was unavailable.

The specialist could not figure out what was wrong. Normally, with correctly configured NAT and global statements in place, connections from a higher-level interface to a lower-level interface should pass through with no problems. The user should also have been able to access the internal FTP server, because the appropriate static and conduit had been configured.

The Issue
After troubleshooting the problem for some time, the specialist discovered what the problem was. Due to the implicit deny at the end of any ACL, even an ACL containing no deny options can block traffic. When the specialist applied the ACL to the Partnernet interface, all traffic was denied except for the Simple Mail Transfer Protocol (SMTP) or e-mail traffic, which had been explicitly permitted by the ACL. This included denying the higher security inside network from accessing the lower security Partnernet network.

Additionally, the FTP and Web traffic were denied even though the conduit statements had expressly permitted it. This was because ACLs override conduit commands. Therefore, when the specialist had initially tested the conduit commands, the ACLs had not yet been applied and the commands still worked as intended. Once the ACL was applied, this traffic could no longer reach its destination.

The resolution
Now that the specialist has identified the problem, corrections can be made. Options were considered, and it was determined that the best way to fix the configuration was to take out the conduit statements for the FTP and Web traffic and replace them with an access list. The ACL would specifically define FTP and Web traffic, along with SMTP traffic, as traffic that should be allowed to traverse the interface. Users were then able to access the following due to the conversion to and correct usage of ACLs:

- The FTP server on the internal network
- The mail server on the internal network
- HTTP servers on the Internet and on any PIX Security Appliance interface except the inside

Figure shows the relevant portion of the PIX Security Appliance configuration after the security specialist converted the conduits statements to ACLs. The configuration now contains four ACL statements, one to permit each of the following:

- Allow users on the Partnernet to access to the FTP server on the inside.
- Allow users on the Partnernet to access the mail server on the inside.
- Prevent users on the Partnernet from accessing hosts on the inside network via HTTP.
- Permit all other HTTP traffic originating from the Partnernet.

The implicit deny at the end of the ACL blocks all other traffic originating from the Partnernet.