cc/td/doc/product/iaabu/pix/pix_v41
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

PIX Firewall Series Version 4.1(6)
Release Notes

PIX Firewall Series Version 4.1(6)
Release Notes

May 1998

Cisco's PIX Firewall provides firewall and network translation services.

The following topics are covered in these release notes:

Cisco provides PIX Firewall technical tips at: 

http://www.cisco.com/warp/public/110/index.shtml

Additional information about PIX Firewall is available at:

http://www.cisco.com/pix

Important Notes

The following are critically important information notes.

    1. PIX Firewall does not support a configuration with three Token Ring interfaces.

    2. To install and configure the PIX Firewall Manager, refer to the PIX Firewall Manager
    Version 4.1(6) Release Notes     included in the PIX Firewall accessory kit.

    3. RADIUS is only supported for authentication and not for authorization.

    4. Before installing version 4.1(6) from 4.0(x), save your configuration on floppy disk and write down your license activation key. You must have a copy of your activation key to restore a previous version from floppy disk.

    5. PIX Firewall only supports configuration upgrades from version 4.0(x). With versions previous to 4.0(x), save your configuration to an ASCII text file using your terminal configuration program.

    6. The HTML Configuration Manager is being obsoleted in the next major release and has not been updated for use with the version 4.1 third interface feature. If your PIX Firewall has two network interfaces, it will work correctly.

    7. Define all interfaces on your PIX Firewall. If three interface cards are installed, you must have interface and ip address statements in your configuration for each interface, even if a network cable is not connected to the interface.

    8. Hosts mapped with static can no longer be pinged from the outside. Only global addresses specified with the conduit or global commands can be pinged.

    9. You must specify a conduit statement for inbound pings. The conduit command has been enhanced to let you specify ICMP message types using the port field. Refer to the conduit note in "Command Changes" for more information.

Command Differences

The following changes to the PIX Firewall command set occurred in versions 4.1(0) through 4.1(6):

New Commands

The commands described in this section were added to PIX Firewall starting with version 4.1(0). Except for the virtual http and virtual telnet commands, all new commands are described in the PIX Firewall Series Configuration Guide.

The new commands are:

The virtual http command redirects the web browser's initial connection to a fictitious IP address in the PIX Firewall, authenticates the user, then redirects the browser back to the URL that the user originally requested. This mechanism comprises the PIX Firewall's virtual server feature. The virtual http command accesses the virtual server for use with HTTP.
This command is especially useful for PIX Firewall interoperability with Microsoft IIS.
When you enter the virtual http command in your configuration, PIX Firewall requires that you create a fictitious IP address for the virtual server. The IP address must not exist on any network and it is recommended that you use an RFC 1918 address.
The format for this command is:
virtual http fictitious_ip [warn]
The fictitious_ip parameter is an IP address that you make up that cannot be the same as any host on the network you are accessing. Cisco recommends that you use an RFC 1918 address or you can use Cisco's documentation example address of 204.31.17.1. The warn option lets users know that the command was redirected. This option is only applicable for text-based browsers on which the redirect cannot happen automatically.
If the virtual server needs to be visible on an external interface, create a static and conduit pair for the fictitious_ip address, and make sure that this address is routed to the PIX Firewall by the Internet router.
Use show virtual http to list commands in the configuration. Use no virtual http to disable its use.
virtual telnet fictitious_ip
The fictitious_ip parameter is an IP address that you make up that cannot be the same as any host on any network served by the PIX Firewall. Cisco recommends that you use an RFC 1918 address or you can use Cisco's documentation example address of 204.31.17.1.
After adding this command to the configuration and writing the configuration to flash memory, users wanting to start PPTP sessions through PIX Firewall then use Telnet to access the fictitious_ip as shown in the following example:
On the PIX Firewall:
virtual telnet 204.31.17.1
static 204.31.17.1 10.1.1.1
conduit 204.31.17.1 23 tcp 0 0
write memory
The local host mapped by the static needs to exist.
If the virtual server needs to be visible on an external interface, create a static and conduit pair for the fictitious_ip address, and make sure that this address is routed to the PIX Firewall by the Internet router.
If aaa authentication inbound is used, the static and conduit statements are not required.

Command Changes

Table 1 lists the command changes that occurred since version 4.1(0).

Table 1: Command Changes
Command Change

all commands

For all commands that accept a protocol parameter, any protocol can be specified by protocol number. You can also supply a mnemonic value for TCP, UDP, or GRE. Support for all protocols is an EFT feature in version 4.1(5).

aaa

1 .New except option.

2 .New console option as an extended field test (EFT) feature that lets you require authentication for access to the PIX Firewall console either on the serial console or via Telnet. If the authentication server cannot be accessed, you can log into the PIX Firewall from the serial console by entering the pix user name and the enable password. The syntax is:


aaa authentication [any|telnet] console tacacs+|radius

Where:

  • any---Access to the serial console or Telnet to the PIX's console must be authenticated with the authentication server.

  • telnet---Only Telnet access to the PIX Firewall console requires authentication from the authentication server.

3 .You can now specify an interface name with aaa authentication. In previous versions, if you specified aaa authentication any outbound 0 0 server, PIX Firewall only authenticated outbound connections and not those to the perimeter interface. In version 4.1(6), PIX Firewall authenticates any outbound connection to the outside as well as to hosts on the perimeter interface. To preserve the behavior of previous versions, use the first two commands that follow to enable authentication and the second command to disable authentication from the inside to the perimeter interface:


aaa authentication any outbound 0 0 server
aaa authentication except outbound perim_net perim_mask server

The version 4.1(6) syntax is:

aaa authentication service|except inbound|outbound|if_name local_ip mask foreign_ip mask tacacs+|radius

Description:

  • if_name---Packets arriving at this interface are authenticated. Use in combination with the local_ip address and the foreign_ip address to determine where access is sought and from whom. The local_ip address is always on the highest security level interface and foreign_ip is always on the lowest.

For example, if you have a server on the perimeter that you want everyone who uses it to be authenticated, you need the following two aaa statements:

aaa authentication any perimeter 204.31.17.1 255.255.255.0 0 0 tacacs+
aaa authentication any perimeter 0 0 204.31.17.1 255.255.255.0 tacacs+

The first aaa statement requires users from the outside network to be authenticated. By putting the perimeter server's IP address in local_ip, which is always the highest security level, then users accessing it must be coming from a lower security level interface, the outside.

The second aaa statement requires users from the inside to be authenticated. By putting the perimeter server's IP address in foreign_ip, which is always the IP address of the lowest security level, then users accessing it must be coming from a higher security interface, the inside.

  • local_ip---The IP address of the highest security level interface from which or to which access is sought.

  • foreign_ip---The IP address of the lowest security level interface from which or to which access is sought.

alias

An interface name can optionally be specified as [(if_name)].

apply

An interface name can optionally be specified as [(if_name)].

arp

You can now specify the name of the third interface.

conduit

1 .New permit and deny options. The syntax is now:


conduit [(int_if,ext_if)] global_ip [deny|permit] port[-port] protocol foreign_ip [netmask]

2 .An interface name can optionally be specified as [(if_name,if_name)].

3 .New sqlnet port identifier.

4 .New gre protocol identifier.

5 .If icmp is specified as the protocol, use the port parameter to specify the ICMP message type.


Inbound pings require a conduit for 8 icmp. You can also use 1 instead of icmp; for example:

conduit 204.31.17.1 8 1 0 0
show conduit
conduit (inside,outside) 204.31.17.1 8 icmp 0.0.0.0 0.0.0.0

Do not use 0 to represent the global IP address for this command.

The most common ICMP message types are 0 for echo reply, 3 for destination unreachable, 4 for source quench, and 8 for echo request.

configure

New net option lets you load a TFTP configuration across the network.

established

New permitto and permitfrom options. You can also use 0 to specify all ports.

global

An interface name can optionally be specified as [(if_name)].

interface

1 .The inside and outside options are no longer supported, but these parameters will continue to work to provide backward compatibility for existing configurations. The inside and outside parameters will be removed from interface in a future release.

2 .The show interface command now displays failover status information.

ip address

You can now specify the name of the third interface.

link

You can now specify an interface name. The syntax is now:


link [(if_name)] foreign_ext_ip [key_id [key|md5]]

linkpath

An extended field test (EFT) feature that lets you specify linkpath 0.0.0.0 0.0.0.0 foreign_external_ip command to route all outbound traffic on a foreign PIX Firewall to a central PIX Firewall. However, this use has two caveats: there can be only one central PIX Firewall and the other PIX Firewall units must be satellites to it. This implies that the satellites only relay connections to the central and do not communicate among themselves. The second caveat is that the linkpath 0 0 command overrides the default route on the outside interface of the satellite PIX Firewall causing all outbound traffic to flow over Private Link to the central PIX Firewall unit. One use of this feature is when access to the Internet is controlled through one PIX Firewall and the other PIX Firewall units feed their Internet traffic to this one site. This could occur when a central processing facility wants to manage all the Internet IP addresses, let the internal networks use any IP numbering scheme, and have local PIX Firewall units protecting individual departments or sites.

mailhost

An interface name can optionally be specified as [(if_name,if_name)].

mtu

You can now specify the name of the third interface.

nat

1 .An interface name can optionally be specified as [(if_name)].

2 .New norandomseq option, which lets you not randomize the TCP/IP packet sequence numbers. This lets the PIX Firewall interact with applications that also randomize the sequence numbers. Note that use of the norandomseq option opens a security hole in the PIX Firewall.

ping

You can now specify the name of the third interface.

rip

You can now specify the name of the third interface.

route

You can now specify the name of the third interface.

static

1 .An interface name can optionally be specified as [(if_name,if_name)].

2 .New classA, classB, and classC options.

3 .New norandomseq option, which lets you not randomize the TCP/IP packet sequence numbers. This lets the PIX Firewall interact with applications that also randomize the sequence numbers. Note that use of the norandomseq option opens a security hole in the PIX Firewall.

snmp-server

New community option lets you specify an encryption key of up to 32-characters shared between the PIX Firewall and the SNMP server.

timeout

New inactivity and absolute qualifiers were added to the uauth option. These qualifiers cause users to have to reauthenticate after either a period of inactivity or an absolute duration.

The inactivity timer starts after a connection becomes idle. If a user establishes a new connection before the duration of the inactivity timer, the user is not required to reauthenticate. If a user establishes a new connection after the inactivity timer expires, the user must reauthenticate. The default durations are zero for the inactivity timer and 5 minutes for the absolute timer; that is, the default behavior is to cause the user to reauthenticate every 5 minutes.

The absolute timer runs continuously, but waits to reprompt the user if the user is idle, such as when the user reads a lengthy web page. When the user starts a new connection, such as clicking a jump and the absolute timer has elapsed, then the user is prompted to reauthenticate. The absolute timer must be shorter than the xlate timer; otherwise, a user could be reprompted after their session already ended.

Inactivity timers give users the best web access because they are not prompted to regularly reauthenticate. Absolute timers provide security and manage the PIX Firewall connections better. By being prompted to reauthenticate regularly, users manage their use of the resources more efficiently. Also by being reprompted, you minimize the risk that someone will attempt to use another user's access after they leave their workstation, such as in a college computer lab. You may want to set an absolute timer during peak hours and an inactivity timer thereafter.

Both an inactivity timer and an absolute timer can operate at the same time, but you should set the absolute timer duration longer than the inactivity timer. If the absolute timer is less than the inactivity timer, the inactivity timer never occurs. For example, if you set the absolute timer to 10 minutes and the inactivity timer to an hour, the absolute timer reprompts the user every 10 minutes; therefore, the inactivity timer will never be started.

If you set the inactivity timer to a duration, but the absolute timer to zero, then users are only reauthenticated after the inactivity timer elapses. If you set both timers to zero, then users have to reauthenticate on every new connection.

An example of the new qualifiers follow:


show timeout
timeout xlate 24:00:00 conn 12:00:00 udp 0:02:00
timeout rpc 0:10:00 h323 0:05:00 uauth 0:05:00
timeout uauth 0:5:00 absolute uauth 0:4:00 inactivity
show timeout
timeout xlate 24:00:00 conn 12:00:00 udp 0:02:00
timeout rpc 0:10:00 h323 0:05:00 uauth 0:05:00 absolute uauth 0:04:00 inactivity

write

New net option lets you save a TFTP configuration across the network.

Removed Commands

The following commands were removed:

Usage Notes

The following sections contain information required to use PIX Firewall. Usage notes are provided in these areas:
Initial Configuration Enhancing the Configuration Advanced Configurations

AAA

Significant functionality changes occurred in PIX Firewall version 4.1(6) with the addition of the interface name. View the aaa note in "Command Changes" for more information.

Access Lists

outbound 10 deny 0 0 23
outbound 10 except 10.1.1.1 255.255.255.255 23
outbound 10 except 10.1.1.2 255.255.255.255 23
outbound 10 except 10.1.1.3 255.255.255.255 23
apply 10 outgoing_src

outbound 11 deny 10.1.1.1 255.255.255.255 0 tcp
outbound 11 deny 10.1.1.2 255.255.255.255 0 tcp
outbound 11 except 204.31.17.1 255.255.255.255 0 tcp
apply 11 outgoing_src

Aliases

The alias command requires that the DNS server be on the outside network. There must be an A (address) record in the DNS zone file for the internal "dnat" address in the alias command.

Attacks

Authentication

Automatic Recovery

Note During automatic recovery, all connections are lost, and all Telnet console sessions or PIX Firewall Manager sessions are suspended and need to be restarted after the unit is back on line.

Conduits

conduit (inside, outside) global_ip 1723 tcp foreign_ip mask

conduit (inside, outside) global_ip 0 gre foreign_ip mask



GRE requires only the second conduit statement.





 Configuration



 Default Routes


 When you define default routes for the PIX Firewall with three interfaces, only specify a default route for the outside interface; for example:


route outside 0 0 192.150.50.1 1



 DHCP


 If you are using DHCP to configure IP addresses for the hosts on the inside network, the DHCP server must provide the IP address, netmask, and gateway (default route) IP address. The default route must point to the PIX Firewall, either directly or via a router.


 Downgrading Versions


 Before downgrading from version 4 to version 3:



Step 1	 Use the show config command to view the encrypted form of the privileged mode password. 



Step 2	 Enter the text representation of the encrypted password in version 3 to access privileged mode.



Step 3	 Remove the aaa commands from your configuration.



Step 4	 Reload version 3 software.



Step 5	 		Add the appropriate auth commands back in.


 Failover



Primary pins 7, 8, and 13 are not used.




 Globals



1.17.31.204.in-addr.arpa. IN PTR pix.newoaks.com




 GRE and PPTP


 To configure the PIX Firewall for PPTP, create two conduit statements as follows:


conduit (inside,interface) global_ip 1723 tcp foreign_ip mask

conduit (inside,interface) global_ip 0 gre foreign_ip mask



 For GRE itself, only the second conduit statement is required to define access to this service.


 GRE uses TCP port 1723, and PIX Firewall requires an additional statement to specify that the GRE protocol is in use. Before using the conduit statements, create static statements to map an internal network address to a global address.


 ICMP


 Use the conduit command with the icmp protocol parameter to allow ICMP access to the PIX Firewall. Refer to "Command Differences" for more information about how you can specify the ICMP message type in the port field.


 IDENT


 PIX Firewall does not support the use of the established command with a PAT IP address for the IDENT service.


 Mail Guard



 Microsoft Exchange


 The following notes affect the use of the Microsoft Exchange mail agent for use with PIX Firewall:



Before starting, you need to:




 Configuring the Microsoft Exchange Servers


 The information that follows describes how to configure a PIX Firewall and two Windows NT systems to pass mail across the PIX Firewall. 



Note To use the procedure that follows, you must be completely familiar with Microsoft Exchange and the administrative functionality of your Windows NT server.



 To help understand this procedure, the following example names and addresses are used: 




 System


 Name


 IP Address


 Domain




 Outside Windows NT server


 outserver


 204.31.17.2


 pixout




 Inside Windows NT server


 inserver


 192.168.42.2


 pixin




 PIX Firewall outside interface


 None


 204.31.17.1


 None




 PIX Firewall inside interface


 None


 192.168.42.1


 None














 The PIX Firewall static statement uses 204.31.17.5 as its global address. An administrative domain is created with the Microsoft Exchange Administrator application named CISCO in this example. This domain includes both servers.


 The sections that follow show how to configure the Microsoft Exchange servers and the PIX Firewall. Complete each section before moving to the next. 


 The sections are:



 Configure the PIX Firewall



Step 1	 Create static and conduit commands to permit the outside server access to the inside server via the global address in the PIX Firewall. For example:



 The static command permits the inside server, 192.168.42.2 to be accessible from the outside at global address 204.31.17.5. The conduit commands give the outside server, 204.31.17.2, access to the inside server's global address 204.31.17.5. Port 139 gives access to NetBIOS over TCP. Access to UDP ports 137 and 138 are also required.


 The last conduit command for TCP port 135 permits the outside server to come in via MSRPC, which uses TCP. RPC stands for Remote Procedure Call.



Step 2	 In addition, add an established command to permit RPC back connections from the outside host on all high ports (1024 through 65535) to deliver mail:




Step 3	 Enter the syslog console command so that you can watch for messages after you configure the two servers.


 Configure the Outside Server



Step 1	 On the outside Microsoft Exchange server, access the Network entry in the Start>Settings>Control Panel. In the Ethernet adapter Properties section, set the primary WINS (Windows Internet Name System) address to the IP address of the outside system, in this case, 204.31.17.2. Set the secondary WINS address to the global address from the static command, 204.31.17.5.



Step 2	 Also in the Network entry, choose Services, and Computer Browser. Ensure that the outside server is the master browser for the server's outside domain which, in this case, is pixout.



Step 3	 Start the Start>Programs>WINS Manager application. Choose Mappings>Static Mappings. Add a static mapping for the inside server's domain, pixin, with the global address from the static command, 204.31.17.5. Also add a unique mapping for the inside server's name, inserver, and set it as well to the global address from the static command. Then save the new information and exit the WINS Manager.



Step 4	 Next, establish a trusted, trusting relationship between the outside server's domain, pixout and the inside server's domain, pixin. Access Start>Programs>Administrative Tools>User Manager for Domains. Then choose Policies>Trust Relationship and click Trusting Domain. Add a trusting domain for the inside server's domain and assign a password to it. 


 Then establish a trusted domain for pixin by clicking Trusted Domain. 



Step 5	 Exit the application and reboot the Windows NT system.


 Configure the Inside Server



Step 1	 On the inside server, access the Network entry in the Control Panel, and set the primary WINS address to the address of that system, 192.168.42.2 and set the secondary WINS address to the inside address of the PIX firewall, 192.168.41.1.


 In the Network entry, choose Services, and Computer Browser. Ensure that the inside server is the master browser for the domain, which in this case, is pixin.


 In the Network entry, choose Protocols>TCP/IP Protocol>WINS Configuration. Set the primary and secondary WINS address to that of the inside server, in this case, 192.168.42.2. On the Default Gateway tab, set the address to the inside address of the PIX Firewall, in this case, 192.168.42.1.



Step 2	 Access Start>Programs>WINS Manager, and specify a static mapping for the outside server's domain, pixout, and a unique mapping for the outside server, outserver. Set both to the address of the outside server, 204.31.17.2.


 On the Server menu, choose Replication Partners and add a Pull Partner for the outside server, in this case, 204.31.17.2. This permits pulling the outside server's database to the inside server's local database. This incorporates the two server's databases so that user information is shared across the firewall. Use the default options in the remainder of this dialog box. 


 You can view the information you entered with Mappings>Show Database.



Step 3	 Establish a trusted, trusting relationship between the inside server's domain, pixin and the outside server's domain, pixout. Access Start>Programs>Administrative Tools>User Manager for Domains. Then choose Policies>Trust Relationship and click Trusting Domain. Add a trusting domain for the outside server's domain and assign a password to it.


 Then establish a trusted domain for pixout by clicking Trusted Domain. 



Step 4	 Exit the application and reboot the Windows NT system.


 Configure Both Systems After Rebooting



Step 1	 After the systems are usable, on the inside server, access Start>Find>Computer and look up the outside server, in this case, by entering \\outserver. Then go to the outside server and find inserver.



Step 2	 On each server, configure Microsoft Exchange from Start>Programs>Microsoft Exchange Administrator to connect to the other server. Declare a network name, in this case, CISCO on both servers. On each server, declare the site name to be the respective server's domain name. In this case, on the inside server, the site name is pixin. On the outside server, it is pixout.


 Access File>Connect to Server to connect to the other server. 



Step 3	 From the Administrator application, configure the site connector. Double-click your site name in the Configure/Connections field and the Connections list appears. Ensure you have a site connector installed. If you followed the defaults when you installed Microsoft Exchange, this should be present. If not, add the site connector for the server's respective domains, just as you did in Step 2. For the cost, use the default. For the Messaging Bridge Head, use the name of that server. For the Target Server, use the name of the other server. You can ignore the Address Space field.



Step 4	 Once both sites are connected, the Administrator application should show the other site available for access. Ensure that at least one user name is specified on each server that you can use as a test login.



Step 5	 Then test mail from a mail client with the user name. The global address list in the address book should list the other server and users on either side. Send the email message.



Step 6	 On the PIX Firewall, you should now be able to see SYSLOG messages indicating an MSRPC connection. If you are sending mail from inside out, you should see an MSRPC connection going from the inside server to the outside server on port 135. Then you should see another high port connection being built between the outside server and the inside server. Your email should flow through almost immediately.


 name Command


 Always use the names command immediately after using the name command. This must be done before you store the configuration in flash memory with the write memory command.


 PAT (Port Address Translation)



nat (inside) 1 0 0
global (outside) 1 204.31.17.1
outbound 1 permit 0 0 1024-65535 tcp
apply (outside) 1 outgoing_src



In this example, the nat command lets inside hosts start outbound connections. The global command creates a PAT global using the 204.31.17.1 IP address. The outbound command permits all inside users to access the high ports. This will let passive FTP connections work correctly. The apply command states that the outbound command applies to inside users starting outside interface connections.




 Pings	


 Starting with this version, PIX Firewall no longer permits pings to local IP addresses declared by the static command. Now only a global IP address configured with the conduit command can be pinged if you have created a conduit to that address. This special conduit designates the icmp protocol and lets you use the port field to specify what type of ICMP message you will let access the global IP address. For example, the following conduit lets any outside host ping any global IP address:


conduit 0 8 icmp 0 0



 The most common message types are 0 for echo reply, 3 for destination unreachable, 4 for source quench, and 8 for echo request.


 


 Private Link


 PIX Firewall selects the next Private Link encryption key by the "round-robin" method. The age command determines the length of time a key is current.


 SQL*Net


 To let SQL*Net clients connect through PIX Firewall, edit the following file on the client PC:


\oracle_dir\network\admin\sqlnet.ora



 Make sure the AUTOMATIC_IPC entry, if it exists, is set to ON as follows:


	AUTOMATIC_IPC = ON



 Statics



 SYSLOG



 Token Ring	



 Troubleshooting




Step 1	 Check that the interface addresses, global and NAT addresses, and route addresses are all unique. All interfaces must be defined, have valid addresses, and appropriate masks.



Step 2	 Check what translation method is in use, either global statements and the nat 1 statement, the nat 0 statement without a global statement, or a nat statement and a PAT global statement. If translation methods are used in combination, none should overlap, or use a single nat x 0 0 statement to overlap the others. Do not use nat 0 and net static statements in conjunction with each other.



Step 3	 If an outbound list exists, ensure that the apply statement is correct.



Step 4	 Ensure that the route statements point to routers on appropriate interfaces.



Step 5	 Check that the test system is part of a valid nat statement or has a static mapping.



Step 6	 Check that each static and conduit statement pair has the correct addresses and that the port or protocol has the correct number of conduit statements. Refer to the "Conduits" usage note for more information. If a third interface is used, ensure that a static and conduit statement pair is provided between the perimeter and outside networks, or from the outside to the inside network.



Step 7	 Ensure that the global pool contains enough addresses for the number of clients on the interface to which it applies. If PAT is in use, ensure that it is configured with the same nat statement identifier as the main pool of global addresses.



Step 8	 Ensure that timeout statement options are reasonable for the site requirements. In most cases, set each option to no more than 30 minutes instead of the default 12 or 24 hours.


 Future Command Obsolescence

 
 Because the http command will be removed in the near future, the information is provided in these release notes and not in the PIX Firewall Series Configuration Guide.



Note The HTML Configuration Manager has not been updated for the third interface changes and may provide unexpected information displays.



 Configuring with the HTML Configuration Manager


 The PIX Firewall provides a graphical user interface to help simplify configuration tasks. 


 Once you have specified the network interface speed and IP addresses, you need to enter two additional commands and you can then use a network browser, such as Netscape Navigator, to complete the configuration. You can have up to 16 simultaneous HTTP console sessions.


 Use the http command (described in the next section) to give access to a workstation and ensure that the firewall has an IP address other than the default 0.0.0.0 value.


 To access the PIX Firewall from a network browser:



Step 1	 At your workstation, start a network browser. 



Step 2	 Open a URL and specify the IP address of the PIX Firewall's inside IP address.



Step 3	 The network browser then prompts you for a user name and password. Always use admin for the user name and enter the password you specified with the passwd command. The default password is cisco.


 The main configuration screen then appears. You can then configure information as needed.


 http command


 Provide or remove access to the PIX Firewall console HTML interface. (Privileged mode.)

[no] http ip_address [netmask]

clear http ip_address [netmask]

show http


 Syntax Description


 



 ip_address


 Inside host IP address that can access this interface.




 netmask


 Network mask of ip_address. If you do not specify netmask, it defaults to 255.255.255.255 regardless of the class of ip_address. 













 Usage Guidelines


 The http command lets an IP address access the PIX Firewall console HTML management interface. Use no http or clear http to disable management interface access. Use show http to list the information you entered. Up to 16 HTTP console sessions can be simultaneously active.


 When you start the web browser, specify the IP address of the firewall in the Go to field or the Open URL field. You must have previously given the firewall an IP address and default route. In addition, if the computer on which you run the browser is directly connected to the PIX Firewall, the computer must be on the same subnet as the firewall.


 If the browser displays an error message stating "Document contains no data," the http command has not been used to give that computer access to the firewall.



Note You must use the http command before you can use the PIX Firewall HTML network browser configuration capability.

The HTTP user name is admin and the default password is cisco. The user name cannot be changed.



 Example


http 192.168.42.42
show http
      192.168.42.42 255.255.255.255*



 Features

 
 Version 4.1 contains the following features:



 Documentation Errata

 
 Table 2 lists the documentation errors in the PIX Firewall Series Configuration Guide since 
version 4.1(0). 




Table 2: Documentation Errors


Item
Description



 Chapter 2, "Providing Outbound Access,"
Step 2


 Do not specify a range of IP addresses that you want to deny or permit access with the outbound command. The following outbound command with an IP range does not work:



outbound 1 permit 10.1.2.1-10.1.2.10 255.255.255.255 80


 While the command seems to work, PIX Firewall transparently changes the IP address to zeros, which is visible when you use the show outbound command.




 Chapter 2, "Providing Outbound Access,"
Step 4


 Do not use nat 0 0 0 with the net static command. If you want to disable address translation with the nat 0 command, specify each static address separately instead of within its network form. For example, to disable address translation and to make an inside address visible on the outside, use these commands:



nat 0 204.31.17.1

static 204.31.17.1 204.31.17.1

conduit 204.31.17.1 0 tcp 0 0


 Table 3-1


 The recommended RFC 1918 IP address groups should be:


  • Class A: 10.0.0.0 to 10.255.255.255
    

  • Class B: 172.16.0.0 to 172.31.255.255
    

  • Class C: 192.168.0.0 to 192.168.255.255
    





 conduit 
command page




1	.The statement that if you exceed 4,096 conduits, you need to upgrade to the 2 MB flash memory should actually read that if the configuration exceeds 100 KB, you should upgrade. Use the UNIX wc command or a Windows word processing program, such as Microsoft Word, to view the number of characters in a configuration.





2	.The pptp protocol identifier should be gre.





 interface command page


 In the next to the last bullet under Usage Guidelines, the first sub bullet recommends that if a no buffer condition arises, you should reboot the PIX Firewall. In an overloaded network situation, these errors can occur and do not signify a problem. Rebooting the PIX Firewall does not improve the situation.


 The last bullet in this section describing overrun errors should instead be in the interface problems bullet list.




 mailhost command page




1	.The reference to the clear mailhost command in the command syntax is incorrect. This command does not exist. Use the no mailhost command instead.





2	.The global IP address can be selected from the pool of global addresses you created with the global command.





 outbound command page




1	.You can ignore the following statement: "Do not specify more than one outbound statement for the same outbound list because each additional command stays in the configuration."





2	.The discussion of the except option is incorrect. The except option is the same as specifying the opposite of the previous blanket permit or deny statement. For example, both of these command sets have the same effect:




outbound 1 permit 0 0

outbound 1 except 10.1.1.1 255.255.255.255 23



outbound 1 permit 0 0 

outbound 1 deny 10.1.1.1 255.255.255.255 23


 route
command page


 Refer to the "Default Routes" usage note for information about specifying default routes for three interfaces.




 snmp-server
command page


 The example for the SNMP community string incorrectly shows a string entered in lowercase with the snmp-server command being transformed into uppercase and lowercase with the show snmp-server command. While the SNMP community string is case sensitive, uppercase must be explicitly entered.




 static
command page




1	.The clear static command does not exist. Use the no static command instead.





2	.The global IP address can be selected from the pool of global addresses you created with the global command.





 timeout 
command page


 The command description incorrectly states that TCP connection slots are freed within 30 seconds after a normal connection close sequence. Connection slots actually free after 75 seconds when a cleanup thread executes.














 Bug Fixes

 
 The following bugs were fixed in the current version: CSCdk01787, CSCdk01706, CSCdj92586, CSCdj92583, CSCdj92178, CSCdj91717, CSCdj90872, CSCdj89773, CSCdj88295, CSCdj86376, CSCdj85520, CSCdj82524, CSCdj81537, CSCdj65904, CSCdj62140, CSCdj54551, CSCdj57141, CSCdj30671, and CSCdj30300.


 Table 3 lists bugs that have been fixed since version 4.0(0). 




Table 3: Bug Fixes


Bug Number
Description
Fixed in Release



 CSCdk01787


 PIX Firewall no longer reboots when the conduit command is entered without a host IP address.


 4.1(6)




 CSCdk01706


 Outbound pings now work correctly.


 4.1(6)




 CSCdj92586


 The aaa authorization command now only works when a previous 
aaa authentication command has been entered.


 4.1(6)




 CSCdj92583


 Reset connections no longer have an unnecessary time-wait state.


 4.1(6)




 CSCdj91717


 PIX Firewall now handles SQL*Net port negotiation correctly. When an inbound SQL*Net connection is made from an outside client to an inside Oracle Windows NT server, the connection is made on TCP port 1521. The server then negotiates with the client to use another TCP port to make the connection. PIX Firewall now handles the negotiation and the new port assignment.


 4.1(6)




 CSCdj90872


 The snmp-server community command now works correctly and lets you change the community string.


 4.1(6)




 CSCdj89773


 Multiple conduit statements for the same port are no longer treated as duplicate commands.


 4.1(6)




 CSCdj88295 and CSCdj92178


 Failover is now disabled in the default configuration. When failover is enabled, the PIX Firewall ARPs for its own inside address.


 4.1(6)




 CSCdj86376


 Commands are now checked for the minimum number of required parameters. The previous behavior caused PIX Firewall to reboot if a command was entered with too few parameters, such as:



static (inside,outside) 10.1.5.6
 4.1(6)




 CSCdj85520


 The Begin configuration SYSLOG message now has the correct format so that it starts with the <165> 111007 label. The full message is:



<165> 111007 Begin configuration: reading from terminal


 This message appears when the PIX Firewall starts up. You can view the message with the show syslog command.


 4.1(6)




 CSCdj82524


 The use of aaa authentication command with PAT (port address translation) now works correctly. The former behavior caused the "Error: connection closed by foreign host" message to display when first time users were authenticated; however, the show uauth command would indicate that the user authenticated successfully. No subsequent reauthentication was necessary thereafter.


 4.1(6)




 CSCdj82436


 PIX Firewall no longer hangs when user authentication traffic is heavy. The previous condition caused the PIX Firewall to run out of "uauths" and "uauth proxies."


 4.1(5)




 CSCdj82103


 User authentication now works correctly with the proxy server in Microsoft Internet Explorer version 3.02.


 4.1(5)




 CSCdj81537


 Pings over Private Link now work correctly when the MTU is greater than 1432 bytes. In versions 4.1(4) and 4.1(5) , if the MTU was greater than 1432 (Ethernet is normally 1500), pings from hosts or routers on either side of the Private Link failed.


 4.1(6)




 CSCdj80668


 The established command now works correctly. The previous behavior was reported on this command: estab tcp xxx permitto udp xxx


 4.1(5)




 CSCdj79777


 User authentication now works correctly when inside users access a PAT global address. The previous behavior caused the initial connection to be reset by the destination host when starting user authentication. Network browsers would display "network error" and Telnet connections would reset the client with the message "error... connection closed by foreign host."


 4.1(5)




 CSCdj78502


 PIX Firewall now correctly validates entries in the translation slot table and IP packets are now forwarded correctly for each entry. The previous behavior caused the following SYSLOG message to appear:



create:(nnn, nnn, nnn) t_salloc failed
 In addition, it was observed that translations became invalid, and certain IP addresses were not able to go through the firewall anymore.


 4.1(5)




 CSCdj75818


 Support for Microsoft Exchange has been clarified. Refer to the "Microsoft Exchange" usage note for more information.


 4.1(5)




 CSCdj74187


 After a PIX Firewall in failover mode fails, it now automatically reboots. The unit still requires intervention to become the primary unit again.


 4.1(5)




 CSCdj72476


 On PIX Firewall units equipped with Token Ring interfaces, if a network or card failure occurs and traffic has not passed through the unit for 15 seconds, the PIX Firewall automatically reboots.


 4.1(5)




 CSCdj71935


 The established command now allows IDENT queries. The previous failure resulted in SYSLOG denial messages and that data was denied by PIX Firewall.


 4.1(5)




 CSCdj71749


 The established command now works correctly. Failure was previously reported with the command estab tcp 25 permitto 113.


 4.1(5)




 CSCdj71645


 Microsoft IIS support has been provided with the new virtual http command.


 4.1(5)




 CSCdj69951 


 The conduit command now accepts a value of 0 in the ports parameter to indicate all ports.


 4.1(5)




 CSCdj69950


 PIX Firewall now evaluates outbound command statements by the numerical value of the number parameter instead of the order in which the commands appear in the configuration.


 4.1(5)




 CSCdj69878


 PIX Firewall no longer stalls after displaying the "alloc_uauth: out of uauth's" message. This could occur during heavy authentication usage, when the uauth option to timeout was set to a value higher than 15 minutes, and when using one of these products: Steel Belted Radius with NDS, Shiva Access Manager, and Cisco Secure Solaris TACACS+.


 4.1(5)




 CSCdj68104


 PIX Firewall Token Ring configurations now work correctly. Previously, a Token Ring PIX Firewall would lock up inexplicably. In this release, the Token Ring driver has the following fixes: a UDP memory leak, ring buffer miscounts, added ring status error detection, added adapter not functioning detection, provided more Token Ring interface statistics, and provided extended buffer optimization.


 4.1(5)




 CSCdj67896


 The sysObjectID and sysUptime SNMP traps now return a fully formed packet length identifier.


 4.1(5)




 CSCdj66058


 Improvements in the PIX Firewall's Intel NIC driver fixed list processing and system control block problems reported against version 4.0(7).


 4.1(4)




 CSCdj65904


 The mailhost command now handles the ORCPT parameter of the RCPT To: command of SMTP.


 4.1(6)




 CSCdj65208


 The conduit command now works correctly with protocols other than TCP and UDP. The previous behavior would not let you enter two statements with the same IP address and ports for non-TCP/UDP protocols; for example:



conduit 10.1.1.1 0 47 0 0

conduit 10.1.1.1 0 29 0 0
 4.1(5)




 CSCdj64928


 PIX Firewall now sends an ICMP destination unreachable message when it receives a packet larger than the size set in the mtu command and when the DF (Don't Fragment) bit is set in the flags field of the IP header. The DF bit is set by a network administrator. PIX Firewall does not let you change bits in the IP header.


 4.1(5)




 CSCdj64459


 After a PIX Firewall in failover mode fails, it now automatically reboots. The unit still requires intervention to become the primary unit again.


 4.1(5) 




 CSCdj64454


 SQL*Net access now works correctly.


 4.1(5)




 CSCdj63817


 PIX Firewall now expires authentications correctly. The authentication duration is set with the uauth option to the timeout command. After an authentication expires, the user is reprompted for their authentication credentials when they start a new connection. The behavior in previous releases caused expired authentications to appear with the show uauth command.


 4.1(4)




 CSCdj63283


 PIX Firewall now displays failover status information in SYSLOG and with the show interface command. Refer to the "Failover" usage note for more information.


 4.1(5)




 CSCdj63280


 Net statics now work correctly so that parameters are no longer truncated. New syntax for the static command is shown in the PIX Firewall Series Configuration Guide. 


 4.1(4)




 CSCdj63276 


 PIX Firewall now works correctly with two Token Ring and one Ethernet interface. Note: Three Token Ring boards are not supported.


 4.1(4)




 CSCdj62140


 Global addresses created with PAT can now be detected by traceroute on outbound connections.


 4.1(6)




 CSCdj61138


 PIX Firewall now correctly routes packets generated on the perimeter network to their correct destination. In the past, these packets were routed to the inside network and either denied or dropped.


 4.1(4)




 CSCdj58092


 PIX Firewall now correctly authenticates users so that reauthentication is no longer required for every subordinate connection, such as when visiting additional web sites.


 4.1(4)




 CSCdj57141


 This bug requested that the documentation state that PIX Firewall does not support IDENT service with the established command. Bug CSCdj71935 fixed the established command so that it would work correctly with IDENT and made bug CSCdj57141 obsolete. 


 4.1(6)




 CSCdj56353


 PIX Firewall now correctly releases translation slots with the clean_xlate function.


 4.1(4)




 CSCdj54975


 Use of Token Ring for the third interface now works correctly with all PIX Firewall motherboards.


 4.1(4)




 CSCdj54659


 The conduit command now accepts a value of 0 in the ports parameter to indicate all ports.


 4.1(5)




 CSCdj54551


 Private Link no longer creates fragmented packets not containing data.


 4.1(6)




 CSCdj54467


 The outbound command now works correctly.


 4.1(5)




 CSCdj52620


 The show xlate command now works correctly.


 4.1(4)




 CSCdj51732


 PIX Firewall no longer requires all Intel 10/100 interfaces for use with the third interface feature.


 4.1(4)




 CSCdj51100


 The conduit command now permits literals for port and protocol parameters.


 4.1(4)




 CSCdj50247


 PIX Firewall now lets Telnet users enter command lines greater than 
160 characters.


 4.1(4)




 CSCdj50133


 SYSLOG messages are now sent correctly to the SYSLOG server.


 4.1(4)




 CSCdj48329


 Prior to version 4.1(4), outbound FTP did not work after aaa authentication was started for HTTP or Telnet. For example, after entering the following command, outbound FTP would be inoperable: 



aaa authentication http outbound 0 0 tacacs+
 For previous versions, FTP can be made to work by enabling outbound user authentication for FTP connections: 



aaa authentication ftp outbound 0 0 tacacs+
 4.1(4)




 CSCdj46403


 Inbound Telnet TN5250 sessions no longer display garbled characters on the first attempt at user authentication.


 4.1(4)




 CSCdj44848 and CSCdj30254


 Private Link over Token Ring no longer forces a reboot.


 4.1(4)




 CSCdj45964


 Support for PPTP tunneling now works correctly.


 4.1(4)




 CSCdj44209


 Use of a host address containing a zero in the last octet(s) used with the static command no longer causes PIX Firewall to crash and display the message "Assert failure." For example, failure occurred when a static command contained an address like 10.1.1.0 as a host address. 


 4.1(4)




 CSCdj43329


 PIX10000 failover now correctly handles the switch from standby mode to active. Examine the first usage note in "Failover" for more information.


 4.1(5)




 CSCdj42187


 PIX Firewall now works correctly when a Windows 95 client copies a NetBIOS SMB file across Private Link. 


 4.1(4)




 CSCdj42149


 PIX Firewall now sends SYSLOG messages correctly.


 4.1(4)




 CSCdj42111


 PIX Firewall now handles multiple inbound user authorization requests. 


 4.1(4)




 CSCdj41919


 SNMP traps are now sent correctly.


 4.1(4)




 CSCdj41735


 PIX Firewall now logs valid Telnet logins via SYSLOG.


 4.1(2)




 CSCdj41550


 Telnet to PIX Firewall console no longer stalls the Telnet session. 


 4.1(4)




 CSCdj41161


 PIX Firewall formerly hung after user authentication proxy failures when the requested server did not exist.


 4.1(2)




 CSCdj40162


 SQL*Net access now works correctly.


 4.1(5)




 CSCdj38612 and CSCdj37411


 PIX Firewall formerly hung on a Telnet console disconnect when the syslog console command was used.


 4.1(2)




 CSCdj36920


 Net statics now take precedence over use of the nat 1 0 0 and global command pair. This means that nat 1 0 0 only grants outbound access to hosts not specified in the net static command.


 4.1(2)




 CSCdj33461


 PIX Firewall previously dropped ICMP exceed messages generated by the routers on the outside. This caused ping requests to fail.


 4.1(2)




 CSCdj33164


 PIX Firewall no longer reboots after running 100 minutes.


 4.1(2)




 CSCdj32982


 Net statics with a variable subnet mask caused ambiguous results.


 4.1(2)




 CSCdj32394


 PIX Firewall would hang intermittently triggering the watchdog timer. This same error caused the PIX Firewall to reboot each time the xlate table was cleared. A crash dump showed the "clean-xlate" thread to be in an active state in the show process output.


 4.0(7)




 CSCdj31673


 Outbound FTP through an alias address created by port address translation did not work.


 4.1(2)




 CSCdj31212


 Use of the nat 0 command caused PIX Firewall to run out of translation slots (called "xlates").


 4.1(2) and 4.0(7)




 CSCdj31210


 When using failover, the secondary PIX Firewall would reboot every 100 minutes.  The show block command would show a leakage in 80-byte blocks.


 4.0(7)




 CSCdj30955


 User authorization for Telnet sessions now works correctly. 


 4.1(4)




 CSCdj30671


 


 If the Don't Fragment bit is set in the IP header and the PIX Firewall receives a packet greater than its MTU setting, PIX Firewall now returns an ICMP MTU Exceeded error. The previous behavior was to silently drop the packet.


 4.1(6)




 CSCdj30300


 PAT does not support connections using UNIX rshell.


 4.1(6)




 CSCdj30226


 Use of the conduit command for PPTP protocol (a subset of the GRE protocol) requires that you create two conduit statements. Refer to the "Conduits" usage note for more information.


 4.1(2)




 CSCdj29700


 User authentication now works correctly. The previous state caused PIX Firewall to run out of authentication slots.


 4.1(5)




 CSCdj27408


 The show uauth command did not display all available information.


 4.0(6)




 CSCdj27407


 The aaa authentication except command did not work.


 4.0(6)




 CSCdj27405


 HTTP did not reprompt when a password was not provided.


 4.0(6)




 CSCdj27404


 The first attempt to deny inbound TACACS+ Telnet authorization did not work.


 4.0(6)




 CSCdj27403


 RADIUS authentication only worked during one session; subsequent sessions failed.


 4.0(6)




 CSCdj26968


 PAT now works when IP fragmenting is in effect.


 4.0(6)




 CSCdj26812


 NFS over PAT now works correctly.


 4.0(6)




 CSCdj26291


 DNS would not resolve PAT addresses and returned an error stating that the DNS response was denied.


 4.0(6)




 CSCdj24669


 When the primary authentication server failed and when the PIX Firewall switched to the next authentication server, the firewall failed and rebooted.


 4.0(6)




 CSCdj23886


 Use of failover no longer causes PIX Firewall to crash.


 4.0(6)




 CSCdj23209


 The alias command now works with different network classes.


 4.0(5)




 CSCdj22282


 The PIX Firewall now allows auto sensing as long as the interface board is capable of handling this feature.


 4.0(5)




 CSCdj22235


 Private Link now resets reliably on the PIX10000.


 4.0(5)




 CSCdj22151


 The buffer overrun and crash problem is fixed.


 4.0(5)




 CSCdj21914


 User-authenticated FTP now works to cco.cisco.com or to any other sites that return multiline responses for the FTP user command.


 4.0(5)




 CSCdj21400


 The aaa authorization command now handles access denials consistently.


 4.0(5)




 CSCdj20000


 Use of FTP during an FTP session now uploads the timeout value.


 4.0(5)




 CSCdj19716


 CuSeeMe UDP chat data stream now works correctly.


 4.1(5)




 CSCdj19369


 Data connections from repeated chained FTP sessions are no longer denied.


 4.0(5)




 CSCdj19306


 The PIX Firewall Token-Ring interfaces now work correctly with an IBM 2210 router.


 4.0(5)




 CSCdj19302


 The firewall now works correctly with the AMD flash memory chip.


 4.0(5)




 CSCdj19227


 Outbound pings via PAT to Cisco routers did not work.


 4.0(6)




 CSCdj19040


 Port numbers higher than 34463 are now permitted in the outbound command.


 4.0(5)




 CSCdj18776


 After one use of PIX Firewall's ping on a PAT (port address translation) IP address, all translated packets were returned with CRC errors.


 4.0(6)




 CSCdj18320


 The aaa authentication command allows an r-shell (rsh) stderr connection.


 4.0(5)




 CSCdj18256


 The PIX Firewall reuses ports properly.


 4.0(5)




 CSCdj18176


 PIX Firewall now responds to ARP requests from Windows 95 and Windows NT without requiring the ARP timeout duration to be less than 10 seconds.


 4.0(5)




 CSCdj17286


 A nat global that was reused as a PAT global mysteriously appeared in a PAT nat combination.


 4.0(6)




 CSCdj16468


 PIX Firewall formerly did not check for excessive command line arguments.


 4.1(2)




 CSCdj15384


 Intel 10/100 interface cards now boot up and respond to ARP requests faster than the previous performance of 75 seconds.


 4.1(2)




 CSCdj12006


 The alias command now automatically makes DNS requests. The PIX Firewall now intercepts DNS queries for aliased IP addresses, resolves the query and sends out the packet with the correct source address.


 4.0(5)














 Cisco Connection Online

 
 Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.


 Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.


 CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.


 You can access CCO in the following ways:



 For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.



Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800  553-2447, 408  526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800  553-6387, 408  526-7208, or cs-rep@cisco.com.



 CD-ROM Documentation

 
 Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com,  http://www-china.cisco.com,  or http://www-europe.cisco.com.
  

 If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
  








hometocprevnextglossaryfeedbacksearchhelp




Copyright 1989-1998 
 © 
Cisco Systems Inc.