Configuring your Netopia Router to create IP filter sets beyond the Basic Firewall.
The Netopia router includes a pre-configured Basic Firewall that is adequate for most general needs. The Netopia router's Basic Firewall is generally sufficient to secure the network while permitting the users of the network appropriate access to remain productive. However, some users will have specific needs that will require some degree of custom firewall configuration. To this end, the Netopia includes a filter set editor that can be used to create custom firewall sets that are appropriate to the specific needs of individual users.
This technote presents information that will be helpful to users who want to customize the Netopia router's filtering of Internet Protocol (IP) beyond the Basic Firewall. It is designed to supplement the material on IP filtering that is presented in your router's User Reference Guide, available on the CD-ROM that shipped with your Router.
This technote does not cover Internetwork Packet Exchange (IPX) filters. That topic is covered in your router's User Reference Guide.
In addition to this technote, there's a Quick Guide that gives information on configuring the Basic Firewall to include filter rules to allow telnet, mail and web access to servers on your network. Click here to go directly to NQG_039. This Quick Guide is a supplement to this comprehensive technote.
Note: For firmware revision 4.8.2 or later, if you are using Network Address Translation with a Public WAN IP, in order to allow telnet to the Netopia's WAN interface, you must create a filter set rule that has a Destination IP Address of the Netopia's Public WAN IP address. Set the Destination Subnet Mask to 255.255.255.255.
| Firewall | A component or set of components that restrict access between a protected network and the Internet or between two networks. |
| Host | A workstation on the Network. |
| Packet | A unit of communication on the Network. |
| Packet Filter | Packet filters allow or deny packets based on source or destination IP addresses, TCP or UDP ports, or the TCP ACK bit. |
| Port | A number that defines a particular type of service. |
| Filter Rule | A filter set is comprised of individual filter rules. |
| Filter Set | A group of individual filter rules. |
Netopia's Basic Firewall can be activated for a particular Connection Profile by selecting Quick Menus -> Change Connection Profiles -> IP Profile Parameters -> Filter Set.
Note: On an R9100 router with no added Connection Profiles, the Basic Firewall can be activated by selecting Wan Configuration -> Wan Setup -> EN setup ->Filter Set.
This Basic Firewall will, by default, allow all traffic that originates on the user's Local Area Network (LAN) to route out, but it will block most traffic directed into the LAN, unless the request for said traffic originated within the LAN. It will also allow traffic above ports 1023 to enter, as these ports are usually necessary for the return of data and not usually a security threat because of the dynamic way in which ports above 1023 are used. The five input filters and one output filter that make up the Basic Firewall are presented in the User Reference Guide.
The Netopia filter sets are static filters. Netopia has the ability to filter by source and destination network address, by source or destination host IP address, by traffic type (e.g., TCP, UDP, ICMP, etc.) and service port number (e.g., ftp on port 21, telnet on port 23, etc.) The filter rules can combine some, all or none of these parameters. The filters will compare incoming traffic against the parameters specified, and ALLOW or DENY the traffic based on what the rule specifies.
Input rules filter traffic coming from the WAN into the LAN, and output filters filter traffic going from the LAN to the WAN. Each Netopia can have up to 8 filter SETS, but only one filter set can be assigned to a given connection profile.
As of firmware version 4.3.4, there are a total of 256 filter rules that can be used among all filter sets. There is no restriction on the number of rules in a given filter set, as long as the number of rules do not exceed 256. For example, you can have two filter sets with 128 rules each, or one with 256 rules. The total number of rules applies to both input and output filters. That means that a filter set with 6 input rules and 6 output rules uses 12 rules total.
Firmware versions previous to 4.3.4 were restricted to a total of 16 input rules and 16 output rules.
Additional information about how firewall filter sets work, including a description of basic IP packet components, and a description of basic protocol types, is presented below.
The IP layer of the TCP/IP protocol suite receives packets delivered by lower-level layers, e.g., a physical device, and passes these packets up to the higher-layer level TCP or UDP layers. Conversely, IP transmits packets that have been received from the TCP or UDP layers to the lower-level layer. The TCP or UDP layer transmits packets to and from various applications, e.g., FTP, Telnet, DNS, and NFS.
All IP packets contain the same basic "header" information. The packet filter uses this header information to make filtering decisions. It is important to note that a packet filter does not look into the IP data stream (the User Data from above) to make filtering decisions. This means that the Netopia router only filters packets by information that determines where the packet came from, is destined for, it's type, or the service/ports it uses. It does not scan the data payload of a packet to filter by CONTENT, e.g., to screen out data that is objectionable if it is coming from an otherwise trusted source. This means the filter set will be no protection against viruses, etc., that travel in the data payload of the packet. An example of IP packet header information is presented in the following table:
| Field | Example |
| Source IP Address | 163.176.132.18 |
| Destination IP Address | 163.176.4.27 |
| Source Port | 2541 |
| Destination Port | 80 |
| Protocol | TCP |
| ACK Bit | Yes |
| DATA | User Data |
The TCP or UDP layer receives IP packets and, in turn, sends them to an application program, such as Telnet, FTP, rlogin, X Windows, SMTP, and DNS. TCP and UDP each have their own characteristics for transmission.
TCP - Transmission Control Protocol. TCP provides reliable packet delivery and has a re-transmission mechanism (so packets are not lost). RFC 793 is the spec for TCP.
UDP - User Datagram Protocol. Unlike TCP, UDP does not guarantee reliable, sequenced packet delivery. If data does not reach its destination, UDP does not re-transmit the data. RFC 768 is the spec for UDP.
Each port service is identified with a 16-bit number. Server processes like Telnet, SMTP, X Windows have an assigned port number along with the destination IP address and this port number is used when initiating a connection to a particular host and service. See the References section of this technote for a list of most of the common TCP and UDP service ports, as well as more IP packet types. There are more ports defined in the 'Assigned Addresses' RFC.
All firewalls have a Default Rule. The default rule determines the behavior of an empty filter set. The default rule in the Netopia router is ALLOW. There is really no reason for having an empty filter set, but an understanding of the default rule is necessary to understanding the behavior of the filter set overall.
More important, however, is the understanding of how the filters will react in real situations. If a Netopia filter set contains only ALLOW rules, all other traffic will be DENIED by default. If a filter set contains only DENY rules, all other traffic is ALLOWED by default. If the filter set contains mixed rules (both ALLOW and DENY), all traffic not covered by a specific rule will be DENIED. Input and output sets are considered separately; e.g., a Connection Profile can contain an output filter set that contains all DENY rules, and an input set that contains all ALLOW rules. The implied rule for the output set will be ALLOW all unspecified traffic, while the default rule for all input traffic will be to DENY all unspecified traffic.
The default rules make filter set design easier by requiring less rules to be written per set. Generally, all one needs to do is add the rules to allow or deny the specific traffic that one is concerned with, and let the default rules handle the rest.
Filter rule ordering is extremely important. Traffic is processed by the filter rules in order, from top to bottom. Therefore, if rule #2 of a filter set blocks a type of traffic that is allowed by rule #3, the traffic will be DENIED before it is ALLOWED, and the traffic will not pass. Furthermore, if a rule specifies that a packet is ALLOWED, and a subsequent rule specifies the packet is DENIED, the rule will be ALLOWED when it is processed by the first rule, and the second rule will never be applied. The important point to remember is that the FIRST rule that a packet matches will determine the fate of the packet, whether it is allowed (passed) or denied (discarded).
As of firmware version 4.3.4, filter rules can be moved using the Move Input Filter, or Move Output Filter screen items on the Display/Change IP Filter Set screen.
Firmware previous to 4.3.4 did not have a Move option. If you have firmware older than 4.3.4, it is very inportant to design your filter sets before you begin entering them into the editor, or you may need to completely re-write your firewall.
One technique that can make expanding your firewall at a later date easier is to leave a blank, inactive filer rule between each active filter rule of the filter set. This leaves room to add additional rules as necessary, without having to rewrite all the rules.
The filter rule editors are found by telneting or consoling to the router and going to Quick Menus -> IP Filter Sets.
Source and Destination Addresses:
The SOURCE address is the network or host address that the packet originated FROM, and so the DESTINATION address is the network or host address that the packet is addressed TO. An input filter will consider traffic originating from the WAN as the source address, whereas an output filter will consider traffic originating on the LAN as the source address.
In the source or destination IP address fields, the IP address that is entered MUST be the NETWORK address of the subnet. A HOST address can be entered, but the applied subnet mask must be 32 bits (255.255.255.255). To apply a rule to ALL networks, use the IP address and mask of 0.0.0.0/0.0.0.0 for the source and/or destination network address.
The Netopia has the ability to compare source and destination TCP or UDP ports. These options are as follows...
Protocol Type:
There are numerous different types of IP packets. The most common are TCP, UDP and ICMP. TCP and UDP packets will be addressed to ports. ICMP (ie, ping and traceroute) and other packet types typically do not use ports. The default value in the protocol type field is any, but you may also type in TCP, UDP, ICMP or the packet type identifier number as listed in the reference section of this technote (see IP protocol types by number at the end of this note, or refer to RFC 1700 directly).
Source/Destination Port Compare:
TCP and UDP packets deliver their data to an application or service listening to a specific port. The port that an application listens to is the destination port of the packet sent to that service. The port that the packet originates on is the source port. For example, web browsers submit their requests for data to a web server application listening to TCP port 80 (by default) so the DESTINATION port of a web browser request is TCP port 80. Filtering by destination ports is most common, since source ports are usually assigned dynamically. An exception would be NetBIOS packets used by Windows networks. For details, see technote NIR_025: Preventing Windows Dial on Demand Issues (NetBIOS). There are a number of logical operators that can be performed on source and destination ports. They are defined below.
| Item... | What it means... |
| No compare | Does not compare TCP or UDP port number |
| Not Equal To | Matches any port other than what is defined |
| Less Than | Anything less than the port defined |
| Less Than Or Equal | Any port less than or equal to the port defined |
| Equal | Matches only the port defined |
| Greater Than or Equal | Matches the port or any port greater |
| Greater Than | Matches anything greater than the port defined. |
Established Connections:
A TCP packet header contains one bit called the ACK Bit (or TCP Ack bit). This ACK Bit only appears with TCP, not UDP. The ACK bit is part of the TCP mechanism that guarantees the delivery of data. The ACK bit is set whenever one side of a connection has received data from the other side. Only the first TCP packet will not have the ACK bit set. Once the TCP connection is in place, the remainder of the TCP packets will have the ACK bit set.
The ACK bit is helpful for firewall design and reduces the number of potential filter rules. A filter rule could be created just allowing incoming TCP packets with the ACK bit set, as these packets had to be originated from the local network.
One of the most common errors when configuring filter sets in the Netopia is forgetting to activate the filter by assigning it to a connection profile. To activate a filter set, telnet or console to the Netopia and from the Main Menu go to Quick Menus -> Change Connection Profile. Select the profile that you wish to activate the filter in and go to the IP Profile Parameters. Select the Filter Sets entry, and you will see a pop-up menu of your configured filter sets. Select the desired filter set. You can only have one filter set active in any one profile at a time, but a single filter set can be used in multiple profiles. You can remove a filter set from a profile by selecting Remove Filter Set.
Note: On an R9100 router with no added Connection Profiles, filter sets can be enabled/disabled by selecting Wan Configuration -> Wan Setup -> EN setup -> Filter Set/Remove Filter Set.
Generally speaking, if the router is using Network Address Translation (NAT) to connect to the Internet or other remote site, it is unnecessary to see a filter set since the LAN cannot be reached from the remote network. However, in some unusual circumstances where it is desirable to filter traffic being proxied through NAT, it is crucial to remember that the NAT process occurs before the filtering process in the Netopia, hence the destination and source addresses used in the filter rules should be the ETHERNET address of the router, not the WAN address as one would normally assume.
The following is an example of how to configure a filter set to allow Point-to-Point Tunneling Protocol (PPTP). The filter set is based on the following network diagram.
This INPUT filter would be set in router A:
| Source IP Address | Source Mask | Destination IP Address | Destination Mask | Protocol | Source Port | Destination Port | On? | Forward |
| 192.168.2.2 | 255.255.255.255 | 192.168.1.2 | 255.255.255.255 | TCP | No Compare | =1723 | Yes | Yes |
| 192.168.2.2 | 255.255.255.255 | 192.168.1.2 | 255.255.255.255 | 47 | -- | -- | Yes | Yes |
This INPUT filter would be set in router B:
| Source IP Address | Source Mask | Destination IP Address | Destination Mask | Protocol | Source Port | Destination Port | On? | Forward |
| 192.168.1.2 | 255.255.255.255 | 192.168.2.2 | 255.255.255.255 | TCP | No Compare | =1723 | Yes | Yes |
| 192.168.1.2 | 255.255.255.255 | 192.168.2.2 | 255.255.255.255 | 47 | -- | -- | Yes | Yes |
The PPTP protocol itself runs on TCP port 1723, but the data is actually passed in packets of type GRE. GRE is another type of IP packet similar to TCP and UDP. GRE packet types are identified by a value of 47 in the IP packet protocol header field. The filter rule in example A allows TCP port 1723 from specific host address 192.168.2.2 to specific host address 192.168.1.2 - these being the IP addresses of the PPTP server machines. Additionally, packets of type GRE are allowed from network 192.168.2.0 to 192.168.1.0 Example B simply reverses this criteria. Note that the IP addresses used in this example are not valid internet addresses and are used for illustrative purposes only. These values will not be appropriate for general use.
- For information on how to configure a filter set to block unwanted demand calls from Windows machines, see technote:
NIR_025: Preventing Windows Dial on Demand Issues (NetBIOS). - For Timbuktu firewall issues, see technote:
TPM_031: Firewall Issues.
This section provides a convenient reference source for common IP types as well as standard TCP and UDP services by port number. These tables are culled from the appropriate RFCs and are potentially subject to change.
The common TCP and UDP ports are:
| tcpmux | 701/tcp | gopher | 70/tcp | netbios-dgm | 138/tcp | new-rwho | 550/udp | |||
| echo | 7/tcp | rje | 77/tcp | netbios-dgm | 138/udp | remotefs | 556/tcp | |||
| echo | 7/udp | finger | 79/tcp | netbios-ssn | 139/tcp | rmonitor | 560/udp | |||
| discard | 9/tcp | http | 80/tcp | imap | 143/tcp | monitor | 561/udp | |||
| discard | 9udp | www | 80/tcp | news | 144/tcp | pcserver | 600/tcp | |||
| systat | 11/tcp | link | 87/tcp | snmp | 161/udp | mount | 635/udp | |||
| daytime | 13/tcp | kerberos | 88/udp | snmp-trap | 162/udp | pcnfs | 640/udp | |||
| daytime | 13/udp | kerberos | 88/udp | exec | 512/tcp | bwnfs | 650/udp | |||
| netstat | 15/tcp | supdup | 95/tcp | biff | 512/udp | kerberos-adm | 749/tcp | |||
| gotd | 17/tcp | hostnames | 101/tcp | login | 513/tcp | kerberos | 749/tcp | |||
| chargen | 19/tcp | iso-tsap | 102/tcp | who | 513/udp | kerberos-sec | 750/udp | |||
| chargen | 19/udp | x400 | 103/tcp | shell | 514/tcp | kerberos-sec | 750/tcp | |||
| ftp-data | 20/tcp | x400-snd | 104/tcp | syslog | 514/udp | kerberos_master | 751/udp | |||
| ftp | 21/tcp | csnet--ns | 105/tcp | printer | 515/tcp | kerberos_master | 751/tcp | |||
| telnet | 23/tcp | pop-2 | 109/tcp | talk | 517/udp | krb5_prop | 754/tcp | |||
| smtp | 25/tcp | pop-3 | 110/tcp | ntalk | 518/udp | listen | 1025/tcp | |||
| time | 37/tcp | pop | 110/tcp | efs | 520/tcp | nterm | 1026/tcp | |||
| time | 37/udp | sunrpc | 111/tcp | route | 520/udp | kpop | 1109/tcp | |||
| rlp | 39/udp | sunrpc | 111/udp | timed | 525/udp | ingreslock | 1525/tcp | |||
| name | 42/udp | auth | 113/tcp | tempo | 526/tcp | tnet | 1600/tcp | |||
| whois | 43/tcp | sftp | 115/tcp | courier | 520/tcp | cfinger | 2003/tcp | |||
| domain | 53/tcp | uucp-path | 117/tcp | conference | 531/tcp | nfs | 2049/udp | |||
| domain | 53/udp | nntp | 119/tcp | netnews | 532/tcp | eklogin | 2105/tcp | |||
| mtp | 57/tcp | ntp | 123/tcp | netwall | 532/tcp | krb524 | 4444/tcp | |||
| bootps | /67udp | ntp | 123/udp | uucp | 540/tcp | irc | 6667/tcp | |||
| bootpc | 68/udp | netbios-ns | 137/tcp | klogin | 543/tcp | dos | 7000/tcp | |||
| tftp | 69/udp | netbios-ns | 137/udp | kshell | 544/tcp |
The following table is excerpted from RFC-1700. It lists the IP protocol types by assigned Internet Protocol number. In the Internet Protocl (IP), [DNN] [RFC791] there is a field called Protocol that identifes the next level protocol. This is an 8-bit field.
| Decimal | Keyword | Protocol |
| 0 | Reserved | |
| 1 | ICMP | Internet Control Message |
| 2 | IGMP | Internet Group Management |
| 3 | GGP | Gateway-to-Gateway |
| 4 | IP | IP in IP (encapsulation |
| 5 | ST | Stream |
| 6 | TCP | Tranmission Control |
| 7 | UCL | UCL |
| 8 | EGP | Exterior Gateway Protocol |
| 9 | IGP | any private interior gateway |
| 10 | BBN-RCC-MON | BBN RCC Monitoring |
| 11 | NVP-II | Network Voice Protocol |
| 12 | PUP | PUP |
| 13 | ARGUS | ARGUS |
| 14 | EMCON | EMCON |
| 15 | XNET | Cross Net Debugger |
| 16 | CHAOS | Chaos |
| 17 | UDP | User Datagram |
| 18 | MUX | Multiplexing |
| 19 | DCN-MEAS | DCN Measuring Subsystems |
| 20 | HMP | Host Monitoring |
| 21 | PRM | Packet Radio Measurement |
| 22 | XNS-IDP | XEROX NS IDP |
| 23 | TRUNK-1 | Trunk-1 |
| 24 | TRUNK-2 | Trunk-2 |
| 25 | LEAF-1 | Leaf-1 |
| 26 | LEAF-2 | Leaf-2 |
| 27 | RDP | Reliable Data Protocol |
| 28 | IRTP | Internet Reliable Transaction |
| 29 | ISO-TP4 | ISO Transport Protocol Class 4 |
| 30 | NETBLT | Bulk Data Transfer Protocol |
| 31 | MFE-NSP | MFE Network Services Protocol |
| 32 | MERIT-INP | MERIT Internodal Protocol |
| 33 | SEP | Sequential Exchange Protocol |
| 34 | 3PC | Third Party Connect Protocol |
| 35 | IDPR | Internet-Domain Policy Routing Protocol |
| 36 | XTP | XTP |
| 37 | DDP | Datagram Delivery Protocol |
| 38 | IDPR-CMTP | IDPR Control Message Transport Protocol |
| 39 | TP++ | TP++ Transport Protocol |
| 40 | IL | IL Transport Protocol |
| 41 | SIP | Simple Internet Protocol |
| 42 | SDRP | Source Demand Routing Protocol |
| 43 | SIP SR | SIP Srouce Route |
| 44 | SIP-FRAG | SIP Fragment |
| 45 | IDRP | Inter-Domain Routing Protocol |
| 46 | RSVP | Reservation Protocol |
| 47 | GRE | General Routing Encapsulation |
| 48 | MHRP | Mobile Host Routing Protocol |
| 49 | BNA | BNA |
| 50 | SIPP-ESP | SIPP Encap Security Payload |
| 51 | SIPP-AH | SIPP Authentication Header |
| 52 | I-NLSP | Integrated Net Layer Security TUBA |
| 53 | SWIPE | IP with Encryption |
| 54 | NHRP | NBMA Next Hop Resolution Protocol |
| 55-60 | Unassigned | |
| 61 | any host internal protocol | |
| 62 | CFTP | CFTP |
| 63 | any local network | |
| 64 | SAT-EXPAK | SATNET and Backaroom EXPAK |
| 65 | KRYPTOLAN | Kryptolan |
| 66 | RVD | MIT Remote Viritual Disk Protocol |
| 67 | IPPC | Internet Pluribus Packet Core |
| 68 | any distributed file system | |
| 69 | SAT-MON | SATNET Monitoring |
| 70 | VISA | VISA Protocol |
| 71 | IPCV | Internet Packet Caore Utility |
| 72 | CPNX | Computer Protocol Network Executive |
| 73 | CPHB | Computer Protocol Heart Beat |
| 74 | WSN | Wang Span Network |
| 75 | PVP | Packet Video Protocol |
| 76 | BR-SAT-MON | Backroom SATNET Monitoring |
| 77 | SUN-ND | SUN ND PROTOCOL-Temporary |
| 78 | WB-MON | WIDEBAND Monitoring |
| 79 | WB-EXPAK | WIDEBAND EXPAK |
| 80 | ISO-IP | ISO Internet Protocol |
| 81 | VMTP | VMTP |
| 82 | SECURE-VMTP | SECURE-VMTP |
| 83 | VINES | VINES |
| 84 | TTP | TTP |
| 85 | NSFNET-IGP | NSFNET-IGP |
| 86 | DGP | Dissimilar Gateway Protocol |
| 87 | TCF | TCF |
| 88 | IGRP | IGRP |
| 89 | OSPFIGP | OSPFIGP |
| 90 | Sprite-RPC | Sprite RPC Protocol |
| 91 | LARP | Locus Address Resolution Protocol |
| 92 | MTP | MulticastTransport Protocol |
| 93 | AX.25 | AX.25 Frames |
| 94 | IPIP | IP-within-IP Encapsulation Protocol |
| 95 | MICP | Mobile Internetworking Control Protocol |
| 96 | SCC-SP | Semaphore Communications Sec. Protocol |
| 97 | ETHERIP | Ethernet-within-IP Encapsulation |
| 98 | ENCAP | Encapsulation Header |
| 99 | any private encryption scheme | |
| 100 | GMTP | GMTP |
| 101-254 | Unassigned | |
| 255 | Reserved |
The Netopia router incorporates a full-featured packet filter that is able to deny or allow network traffic based on source or destination network or host address, source or destination port number or IP packet type. These filter features allow the Netopia to secure the local network from unwanted access while allowing trusted users to remain productive on the network.