Protocol filters

With the protocol filter you can influence the handling of certain protocols during transfer 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: Wireless LAN / Security / Protocols

WEBconfig: LCOS menu tree / 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 protocol entered.
• Start port and end 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 of the official protocol and port numbers are available in the Internet under www.iana.org.
• Destination 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.
• DHCP source MAC: Enabling of DHCP address tracking.
  • Yes: The rule applies if the source MAC address of the packet is listed in the table under Status > LAN Bridge Statistics > DHCP Table as an address which obtained an IP address using DHCP.
  • No: The rule applies if this is not the case.
  • Irrelevant: The source MAC address is not considered.
  Note: If DHCP address tracking is enabled, any IP addresses usually entered are disregarded. Please refer to for further information.
• IP network and 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.
• 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~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).
  Note: 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 captured using 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.
  Note: 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 rejected.

• Procedure for filter test

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, IPX, 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.
   Note: 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 pre-configured 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.
   • Redirect function
   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: a high degree of mobility. Consequently, clients are not necessarily always connected to the same access point, but frequently change between access points 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
   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 Statistics > 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'.
   Note: The number of clients which may be connected to an interface via DHCP can be configured in the Port table under Setup > LAN Bridge > Port Data. Setting the entry to '0' means that any number of clients can register at this interface via DHCP. If the maximum number of DHCP clients is exceeded by a further attempt to register, the oldest entry in the list is deleted.
   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.
   Note: If DHCP tracking is enabled on an interface, packets received on this interface from DHCP servers are automatically dropped.