Misc 31

This is the followup of the previous article, and will use the same topology. As an example, we'll first begin by allowing the Perimeter router to telnet to hosts in the DMZ and User network. To do this, we'll need to make use of access-lists like in the IOS. The syntax is slightly different but you should be able to follow along just fine with the context sensitive help. We'll create two entries in the access-list allowing hosts in the 1.1.1.0 subnet to telnet to 2.2.2.0 and 3.3.3.0:access-list PERMITTELNET extended permit tcp 1.1.1.0 255.255.255.0 2.2.2.0 255.255.255.0 eq telnet
access-list PERMITTELNET extended permit tcp 1.1.1.0 255.255.255.0 3.3.3.0 255.255.255.0 eq telnet

For the list to work, we'll need to apply it. Since the traffic will be coming inbound from Outside, we use the following syntax:
access-group PERMITTELNET in int Outside

Try telnetting from Perimeter to User again. Lo and behold, it works! Here's another example for access-lists. Recall that we have a WebServer in the DMZ. We'll now allow web access from outside to the DMZ with yet another access-list:
access-list PERMITHTTP extended permit tcp any 2.2.2.0 255.255.255.0 eq www

Similarly, we apply the access-list to the outside interface to check on inbound traffic:
access-group PERMITHTTP in int Outside

At this point you can attempt to connect to the 2.2.2.2 server from the computer you have. You may need to create routing entries using the route add command like this:
route add 1.1.1.0 mask 255.255.255.0 192.168.1.1
route add 2.2.2.0 mask 255.255.255.0 192.168.1.1
route add 3.3.3.0 mask 255.255.255.0 192.168.1.1

At this point you should be able to have initiate a HTTP connection to 2.2.2.2 but not to 3.3.3.2. It is all working fine and dandy now!

Now that this is out of the way, we'll begin on NAT. NAT is set up using three commands. The syntax for specifying an INSIDE interface is:
nat (Inside) 1 0 0
nat (DMZ) 1 0 0

The syntax for specifying an OUTSIDE interface for PAT is:
global (Outside) 1 interface
global (DMZ) 1 interface

At this point there are a couple of things that would happen to traffic. Here is a breakdown:
Inside to DMZ - PAT to e1
Inside to Outside - PAT to e0
DMZ to Outside - PAT to e0

If we want the web server to be accessed from outside, what would we usually do on an IOS router? You guessed it, we would perform static NATting. Here's the third form of the NAT command:
static (DMZ,Outside) tcp interface www 2.2.2.2 www

This translates and redirects traffic directed at the Outside interface's www port to the web server's IP. However, the traffic would not be permitted. Why? This is because HTTP traffic directed at 1.1.1.2:80 would be denied even before it gets NATted. The solution? We'll need to add another entry into PERMITHTTP (and perhaps even remove the previous one if you have the time). To do this:
access-list PERMITHTTP extended permit tcp any 1.1.1.2 255.255.255.255 eq www
no access-list PERMITHTTP extended permit tcp any 2.2.2.0 255.255.255.0 eq www

Traffic pointed at 1.1.1.2 at this point would be redirected to 2.2.2.2. This wraps up basic firewall design. We'll now end this session with the setting up of basic management services. Telnet is the easiest to set up. To set up telnet, you simply specify the clients allowed to connect like this:
telnet 3.3.3.0 255.255.255.0 Inside
passwd cisco

To allow SSH, we simply generate a key with the crypto command, then specify the allowed users using the SSH command:
crypto key gen rsa
ssh 3.3.3.0 255.255.255.0 Inside

Now SSH should be set up. If you are logging into SSH without AAA, the username would be "pix" and the password would be whatever is specified in the passwd command. This concludes the PIX introduction.