The Protocol tab is used to specify which protocols are permitted between which combinations of zones.
To the left of the tab is the Defined Network Zones: list holding every zone currently defined. The Zone Properties area shows which protocols or services the currently selected zone is permitted to serve and to whom. We will refer to the currently selected zone as the serving zone.
The expandable list of protocols is organised into ten categories:
Data Serve - Protocols used by databases and other data sources like time servers.
File Transfer - Protocols used to tranfers files like HTTP for the Web and FTP.
Game - Protocols used by games for online multiplayer gaming.
Interactive Session - Protocols used for working on or performing actions on a remote system. SSH Secure Shell, telnet and also RPC protocols are here.
Mail - Protocols associated with delivering and moving email. SMTP and POP3 are here.
Media - Protocols used for delivering multimedia across the internet in real time.
Miscellaneous - Other protocols that really didn't fit under the other categories.
Network - Protocols related to the direct operation of the network inself.
User Defined - Protocols defined by the user on the "Advanced" tab show up here.
To the right of each protocol entry in the list may be one or more columns of checkboxes. Each zone that the serving zone is connected to has a column on checkboxes. The name of the zone is at the top of the column. The zones/columns which appear here is determined by the Connection list on the Zone tab for the currently selected zone.
The checkboxes have the following means:
Clear - The protocol is not permitted. Clients in this zone may not start a connection to the serving zone using this protocol. For example, if "Web Servers" is the currently selected serving zone, and the HTTP (Web) protocol box is clear for the "Bad Guys" zone, then machines in the "Bad Guys" zone will not be allowed to access a web server running on a machine in the "Web Servers" zone. Any attempt will be completely ignored. Any incoming packets will be dropped.
Checked/Ticked - The protocol is permitted. Clients in this zone may start a connection to the serving zone using this protocol. For example, if "Web Servers" is the currently selected serving zone, and the HTTP (Web) protocol box is ticked for the "Bad Guys" zone, then machines in the "Bad Guys" zone will be allowed to access a web server running on a machine in the "Web Servers" zone.
Crossed - The protocol is not permitted and packets will be rejected instead of just dropped. When a packet is rejected an ICMP packet is sent back to the source to inform it that the packets was rejected by the firewall. For example, if "Web Servers" is the currently selected serving zone, and the HTTP (Web) protocol box is crossed for the "Bad Guys" zone, then machines in the "Bad Guys" zone will not be allowed to access a web server running on a machine in the "Web Servers" zone. But unlike when the checkbox is unticked and blank, any connection attempts will be rejected instead of ignored.
This information is summerised at the bottom of the tab in a concise key or legend show each of the different checkbox states.
Rejecting a protocol is considered a more "friendly" way of blocking it's use, because the sender is immediately informed about what has happened. When a packet is quietly blocked by the firewall, the sender will not know and will have to wait and "time out" before realising that communication has failed.
Generally there is little reason to reject protocols instead of just having them dropped. If someone is trying to use a protocol that you didn't allow, then for safety's sake we should assume that they are hostile and therefore shouldn't be helped. In this situation, dropping packets is better because it uses less network capacity and has the effect of making most port scanners run very slowly.
The only situation that you are likely to run into where rejecting a protocol is desirable, is with the "ident" protocol. When connecting to many mail or IRC servers when connected to, use the "ident" protocol to try to find out owner of the incoming connection, and don't respond to the incoming connection until they have tried "ident". This problem shows up, for example, as delays when connecting to mail servers. The connection will be made with the mail server, but there will be a noticeable delay before any mail is retrieved. This is because the server tries to make an "ident" connection back, but has wait and time out before realising that it won't work. The solution is to just make sure that "ident" is being rejected for connections coming from the zone containing the mail server.
Information about a protocol is displayed on the botton left side of the tab. You can get information about any of the protocols in the list just by clicking on it's title.
The following information is available about each protocol:
Name - The name of the protocol. It's fully name and also any acronym it may be known by.
Description - A short description of what the protocol is used for.
Security Risk - An estimate of the security risk that use of the protocol has. The risk ranges from low, medium, high or unknown.
Network Usage - This is a description of how the protocol uses the network. It describes which connections, IP protocols and port ranges etc the protocol uses to operate. This field is only shown if the Show Advanced Protocol Help checkbox is check on the Advanced tab.