Filtering protocols

With the protocol filter you can influence the handling of certain protocols for transmissions between interfaces, e.g. from the WLAN to the LAN. The use of appropriate rules allows the definition of which data packets should be inspected, interfaces for which the filter applies and which action should be performed on the data packets.

LANconfig: Interfaces > LAN > LAN bridge > Protocols

Command prompt: Setup > LAN-Bridge > Protocol-Table

Similar to a firewall rule, a protocol filter consists of two parts:

• The packet conditions defines the conditions that must be satisfied in order for the filter to be applied to a packet.
• The action defines what happens to the packet if the condition is met.

A packet filter is described by the following parameters:

Name

A name of your choice for the filter entry.

Protocol

The protocol that this filter is valid for. If '0' is entered as the protocol, the filter applies to all packets.

Subtype

The sub-protocol for which this filter is valid. If '0' is entered as the sub-protocol, the filter applies to all packets of the specified protocol.

First port / Last port

The port range that this filter is to be valid for. If '0' is entered as the start port, this filter will be applied to all ports of the corresponding protocol/sub-protocol. If '0' is entered as the end port, the start port becomes an end port.

Note: Lists with the official protocol and port numbers are available in the Internet at www.iana.org.

Remote MAC address

The MAC address of the client to which the packet is to be sent. If no destination MAC address is entered, the filter is applied to all packets.

IP assigned by DHCP

Setting this option to Yes or No activates the DHCP tracking. This checks whether the table Status > LAN-Bridge > DHCP-Table contains the source MAC address of a packet from a network user who obtained an IP address via DHCP. Additionally, a network can be specified for a filter rule. However, if a rule has set this parameter to Yes, a specified network could be ignored. Possible values:

• Yes: The rule applies if the source MAC address of the packet is listed in the table under Status > LAN-Bridge > DHCP-Table as an address that obtained an IP address via DHCP.
• No: The rule applies if this is not the case.
• Irrelevant: The source MAC address is not considered.

Important: If DHCP address tracking is enabled, any IP addresses usually entered are disregarded.

Network IP / Netmask

The IP address of the network mask to which this filter applies. Only those IP packets whose source and destination IP addresses lie within this network are captured by the rule. If no network is entered, the filter applies to all packets.

Match

By default, the source and the destination address are both checked. Here you can specify whether only the source or only the destination address is checked instead.

Interface list

List of the interfaces to which the filter applies. All of the LAN interfaces, DMZ interfaces, logical WLAN networks and point-to-point connections in the WLAN may be entered as interfaces. The following examples illustrate how interfaces are specified: 'LAN-1' for the first LAN interface, 'WLAN-2-3' for the third logical WLAN network on the second physical WLAN interface, 'P2P-1-2' for the second point-to-point connection on the first physical WLAN interface. Groups of interfaces may be specified in the form 'WLAN-1-1~WLAN-1-6' (logical WLANs 1 to 6 on the first physical WLAN interface) or with a wildcard as 'P2P-1-*' (all P2P connections on the first physical interface).

Important: Only filter rules with valid entries in the interface list are active. A rule with no specification of the interfaces does not apply to all of them - it is ignored instead.

Action

Action performed for the data packets processed by this rule:

Redirect IP address

Destination IP address for the "Redirect" action On redirection, the destination IP address of the packets is replaced by the Redirect IP address entered here. Furthermore, the destination MAC address is replaced by the MAC address determined using ARP for the Redirect IP address.

Important: If ARP was unable to determine the destination MAC address, the packet is dropped rather than redirected.

Example:

ARP, DHCP, ICMP are allowed to pass, Telnet and HTTP are redirected to 192.168.11.5 and all other packets are dropped.

If no filter rules are defined for an interface, all packets from and destined to it are transmitted without alteration. As soon as a filter rule has been defined for an interface, all packets to be transferred via this interface are checked prior to being processed.

1. As a first step, the information required for checking is read out of the packets:
   • DHCP source MAC
   • Destination MAC address of the packet
   • Protocol, e.g. IPv4, ARP
   • Sub-protocol, e.g. TCP, UDP or ICMP for IPv4 packets, ARP Request or ARP Response for ARP packets
   • IP address and network mask (source and destination) for IPv4 packets
   • Source and destination port for IPv4 TCP or IPv4 UDP packets
2. As a second step, this information is checked against the information from the filter rules. All those rules in which the source or destination interface is included in the interface list are considered. Checking of the rules for the individual values is as follows:
   • For DHCP source MAC, protocol and sub-protocol, the values read out of the packets are checked for consistency with the values defined in the rule.
   • With IP addresses, the source and destination address of the packet are checked to see whether they lie within the range formed by the IP address and the network mask of the rule.
   • Source and destination ports are checked to see whether they lie in the range between start port and end port.
   If none of the rule values specified (not filled by wildcards) agree with the values read out of the packet, the rule is not considered applicable and is disregarded. If several rules apply, the most accurate rule action is carried out. Parameters are more accurate the further down the list of parameters they are or the further right they appear in the protocol table.
   Important: If rules are defined for an interface, but there is no match with one of the rules for a packet from/for this interface, the default rule for this interface is used for the packet. The default rule is preconfigured for each interface with the 'drop' action but this is not visible in the protocol table. To modify a default rule for an interface, a rule with the name 'default-drop' is defined. Besides the interface naming, this rule can only contain wildcats and the required action.
   Checking of MAC addresses in packets sent over the respective interface takes on a different form to that with in-coming packets.
   • With out-going packets, the source MAC address read out of the packet is checked against the destination MAC address entered in the rule.
   • The destination MAC addresses read out of the packet are then checked to see whether they are listed as currently active DHCP clients.
   • Rules with the 'Redirect' action are ignored if they apply for an interface over which the packet is to be sent.
3. In the third step, the action associated with the applicable rule is carried out.

With the Redirect action, IPv4 packets can not only be transferred and dropped, they can also be communicated specifically to a particular destination. As a general rule, the destination IP address of the packet is replaced by the Redirect IP address entered. The destination MAC address of the packet is replaced by the MAC address determined by ARP and associated with the Redirect IP address.

In order for the redirected packets to find the correct sender on their "return trip", a dynamic table is compiled with automatic filter rules that apply to packets leaving via this interface. This table can be viewed under Status > LAN bridge > Connection table. Rules in this table have a higher priority than other matching rules with the 'Transfer' or 'Drop' actions.

Clients within wireless networks often have one aspect in common: They are highly mobile. Consequently, clients are not necessarily always connected to the same AP, but frequently change between APs and the related LANs.

The redirect function assists WLAN client applications to automatically find the correct target computer in the LAN. If a WLAN client's HTTP request from a particular logical wireless network is to be always directed to a particular server in the LAN, a filter setting with the "Redirect" action is set up for the appropriate protocol for the desired logical WLAN interface.

All requests with this protocol from this logical wireless network are automatically redirected to the target server in the LAN. The returning data packets are sent to the senders' addresses and ports according to the entries in the connection statistics, ensuring trouble-free operation in both directions.

DHCP address tracking keeps a record of which clients have received their IP addresses using DHCP. The relevant information for an interface is automatically maintained in a table under Status > LAN Bridge > DHCP Table. DHCP tracking is enabled on an interface if, for this interface, a minimum of one rule is defined where 'DHCP Source MAC' is set to 'Yes'.

When checking data packets, IP addresses and the IP network mask defined in the rule are not used. Consequently no check is made as to whether the destination IP address of the packet lies within the range specified. Instead, a check is made as to whether the source IP address of the packet matches the IP address assigned to the client via DHCP. The connection of the two IP addresses is made based on the source MAC address.

This check can be used to block clients which have received an IP address via DHCP, but which actually use a different IP address (either intentionally or inadvertently). A rule in which the DHCP Source MAC parameter is set to 'Yes' would not apply since the two addresses do not match. The packet would instead be processed either by other rules or the default rule.

In order for DHCP tracking to work, at least two more rules must be set up for this interface, rules which are not dependent on DHCP tracking. This is necessary since the required DHCP information is not exchanged until the end of DHCP handshake. This is why packets due to be sent beforehand must be allowed by rules which do not use DHCP tracking. These usually included TCP/UDP packets on port 67 and 68 and ARP packets.