=================
TABLE OF CONTENTS
=================

1. List of IPFLT31 debug commands and examples for troubleshooting Border
Manager packet filtering issues

2. Information required by NTS when opening calls with Novell Technical Support

3. IPFLT31 functionality related to filter processing

4. Additional IPFLT31 SET commands

==================================
1. IPFLT31 DISCARD DEBUG COMMANDS
==================================

IPFLT31.NLM ships with various debug commands available to help customers
troubleshoot their own packet filtering problems.

In most cases the problem lies with the fact that an application protocol is not
being allowed through the firewall. The solution to the problem is to add an
exception filter to allow the specific application traffic through. Such debug
commands allow users to identify the various packet types on the network, and
modify their filters accordingly to pass or block the traffic.

IPFLT31 exports a number of commands, which may be used to help debug packet
filtering issues. These commands can be global i.e. turn on all debug settings,
or individual i.e. turn on only a few required settings. Globally, the following
list of commands exist

(a) ipflt_debug_help - Display all the available debug commands coming with
ipflt31.nlm. This is useful in that it displays all the available commands on
the system console.

(b) ipflt_debug_on - Enable packet forwarding filter debug. This option will
enable all of the SET commands mentioned below with the exception of the three
"Set Route" commands. It will list all forwarded and discarded traffic going
through the filters. This command is useful when you have no idea as to what
traffic is being blocked or forwarded. If you are experiencing a problem with
one specific application, the individual commands mentioned later in the
document should be used.

(c) ipflt_debug_off - Disable all filter debug. This option will disable each
and every one of the SET commands mentioned below. Using the "Set Filter Debug =
off" at the server console has the same effect.

(d) ipflt_route_debug -  Enable routing filter debug. This option will enable
the three "Set Route" commands mentioned below. This command should only be used
when customers suspect that the routes the system knows about are not being
advertised.

It is also possible to set individual filters on to troubleshoot filter problems
at specific levels. Below is a list of individual set commands (see list (i) to
(xiv)), and examples of how they may be used to troubleshoot problems. NOTE that
the "Set Filter Debug=on" must first be set at the server console for any of
these individual SET commands to have an effect.

When the SET commands are enabled, the system console will display the state of
the packet as seen by the IPFLT31 module i.e. it will display a message
indicating that the packet has been 'discarded' by the filter if the discard SET
command is enabled, or 'forwarded' by the filter if the forward SET command is
enabled. To see both discarded and forwarded packets for a specific protocol,
both SET commands for that protocol must be enabled.

(i) Set IP Discard Filter Debug=1/0

This command starts or stops the IP Packet Discarding Filter Debug. Any
discarded IP packet that is processed by the filtering module (IPFLT) will be
displayed on the screen.

The advantage of using this debug is that customers can view all IP traffic
being discarded by the filters, as opposed to just TCP or UDP discards. The
downside however is that we capture much more data with this filter and need to
trace through more data. If customers believe that IGMP (active if PIM is enabled)
packets are being incorrectly dropped or allowed through, then setting this
parameter ON for troubleshooting makes sense.

(ii) Set IP Forward Filter Debug=1/0

This command starts or stops the IP Packet Forwarding (as opposed to discarded
packets addressed by (i) above) Filter Debug. Any Forwarded IP packet that is
processed by the IPFLT31.NLM will be displayed on the screen.

The advantage of using this debug switch is that you can verify that packets
configured to be allowed through, are indeed so.

(iii) Set TCP Forward Filter Debug=1/0

This command Starts or Stops TCP Packet Forwarding Filter Debug. When enabled, all
forwarded TCP packets will be written to the system console.

This option should be used in cases where SMTP, POP3, FTP, HTTP, TELNET or other
TCP based applications fail to work correctly with the filters enabled. Once
enabled, verify that you can see the forwarded TCP packets at the system
console.

(iv) Set TCP Discard Filter Debug=1/0

This command Starts or Stops TCP Packet Discarding Filter Debug. When enabled, all
discarded TCP packets will be written to the system console.

This option should be used in cases where SMTP, POP3, FTP, HTTP, TELNET or other
TCP based applications fail to work correctly with the filters enabled. If the
packets should be allowed through and yet you see your TCP packets being  
discarded, add exception filters to allow the blocked traffic through.

Looking at an example where we used this set command. A TELNET server is running
on the Border Manager server 130.57.61.56. The default Border Manager filters
are in place. The problem is that Telnet clients complain that they cannot
telnet to the server.
The fact that TELNET, a TCP based application, is the only application that
seems to generate support calls, we decide to enable the TCP discard debug
commands. Doing this gave us the following output.

SJF-ENG-PADDY5:set tcp discard filter debug=1
TCP Discard Filter Debug set to 1
******************************************************************************
OUTBOUND packet to "Discard"
Protocol Type=(TCP)             Protocol Flag=(SYN)
Source Address=(130.57.61.137)  Destination Address=(130.57.61.56)
Source Port=(1123)              Destination Port=(23)
Source TOS=( Dynamic)           Destination TOS=(Telnet)
Source Interface=(1)            Destination Interface=(1)
Source Circuit=(42553)          Destination Circuit=(0)
Source GroupID=(0)              Destination GroupID=(0)

Discard filter rule from "Exceptions" list
Filter Protocol Type=(IP)
Source Interface Type=(BOARD)   Destination Interface Type=(Any)
Source Address=(Any Address)    Destination Address=(Any Address)
Source Interface Number=(1)     Destination Interface Number=(0)
Source Port Range=(0-0)         Destination Port Range=(0-0)
Source TOS=(Reserved)           Destination TOS=(Reserved)
Source Group Name=(None)        Destination Group Name=(None)
Source Group ID=(0)             Destination Group ID=(0)
Source Remote System ID=(None)  Destination Remote System ID=(None)
Source Circuit=(0)              Destination Circuit=(0)

From this debug output, we can see that the TCP SYN requests from the client
(130.57.61.137) are getting discarded and never reach the server. To get around
the problem, we needed to add an exception filter to allow Telnet packets
through. The exception rule was as follows:

Source interface = private interface of BM server where client is located
Public interface = public interface of BM server
Packet type = Telnet (protocol TCP, destination port 23)
Source address and destination addresses were left at <any> although customers
can enhance security by putting in IP addresses of Telnet servers made
accessible to clients.

(v)  Set UDP Forward Filter Debug=1/0

This command Starts or Stops UDP Packet Forwarding Filter Debug. When enabled, all
forwarded UDP packets will be written to the system console.

This option should be used in cases where DNS, SNMP, NFS, SLP or other UDP based
applications fail to work correctly with the filters enabled. Once enabled,
verify that you can see the forwarded UDP packets at the system console.

(vi) Set UDP Discard Filter Debug=1/0

This command Starts or Stops UDP Packet Discarding Filter Debug. When enabled, all
discarded UDP packets will be written to the system console.

This option should be used in cases where DNS, SNMP, NFS, SLP or other UDP based
applications fail to work correctly with the filters enabled. Once enabled,
verify that you can see the forwarded UDP packets at the system console. If the
packets should be allowed through and yet you see your UDP packets being
discarded, add exception filters to allow the blocked traffic through.

An example where this SET command would be useful would be troubleshooting the
following SNMP (UDP based application) problem.
The customer is running TCPCON to try and query SNMP statistics on another local
server. When he runs TCPCON on his box (130.57.61.56) and points the "SNMP
Access Configuration" to 130.57.62.2, he gets "Request Timed Out" messages. By
setting the "Set UDP Discard Filter Debug=1", we were able to see the following
at the server console.

All allow rules from the exception list were initially parsed but no specific
entry existed that would allow the SNMP protocol. As a result, we would hit the
main rule that blocks everything not in the exception list. To overcome this
problem, simply add an exception to allow SNMP packets out.

******************************************************************************
OUTBOUND packet to "Discard"
Protocol Type=(UDP)             Protocol Flag=(NONE)
Source Address=(130.57.61.56)   Destination Address=(130.57.62.2)
Source Port=(1030)              Destination Port=(161)
Source TOS=(Dynamic)            Destination TOS=(SNMP)
Source Interface=(1)            Destination Interface=(1)
Source Circuit=(32847)          Destination Circuit=(32847)
Source GroupID=(0)              Destination GroupID=(0)

Discard filter rule from "Exceptions" list
Filter Protocol Type=(IP)
Source Interface Type=(BOARD)   Destination Interface Type=(Any)
Source Address=(Any Address)    Destination Address=(Any Address)
Source Interface Number=(1)     Destination Interface Number=(0)
Source Port Range=(0-0)         Destination Port Range=(0-0)
Source TOS=(Reserved)           Destination TOS=(Reserved)
Source Group Name=(None)        Destination Group Name=(None)
Source Group ID=(0)             Destination Group ID=(0)
Source Remote System ID=(None)  Destination Remote System ID=(None)
Source Circuit=(0)              Destination Circuit=(0)
******************************************************************************

(vii) Set ICMP Forward Filter Debug=1/0

This command Starts or Stops ICMP Packet Forwarding Filter Debug. When enabled,
all forwarded ICMP packets will be written to the system console.

This option should be used in cases where users cannot PING, or receive ICMP
route updates with the filters enabled. Once enabled, verify that you can see
the forwarded ICMP packets at the system console.

(viii) Set ICMP Discard Filter Debug=1/0

This command Starts or Stops ICMP Packet Discarding Filter Debug. When enabled,
all discarded ICMP packets will be written to the system console.

This option should be used in cases where users cannot PING, or receive ICMP
route updates with the filters enabled. Once enabled, verify that you can see
the discarded ICMP packets at the system console.

Below is an example from a Server where ICMP is being blocked. By enabling the
ICMP Discard Filter Debug switch, we were able to see that
1) the ICMP packet was indeed discarded and;
2) the configured rule that resulted in the ICMP packet being discarded (Discard
filter rule from "Exceptions" list)

SJF-ENG-PADDY5:set icmp discard filter debug=1
ICMP Discard Filter Debug set to 1
SJF-ENG-PADDY5:ping 130.57.4.1
Loading module PING.NLM
  TCPIP Ping Utility NW5SP3.250699
  Version 4.23    June 25, 1999
  Copyright 1994-1999 Novell, Inc.  All rights reserved.
***********************************************************************
OUTBOUND packet to "Discard"
Protocol Type=(ICMP)            Protocol Flag=(NONE)
Source Address=(130.57.62.38)   Destination Address=(130.57.4.1)
Source Port=(0)           Destination Port=(0)
Source TOS=(70)           Destination TOS=(70)
Source Interface=(1)            Destination Interface=(1)
Source Circuit=(56955)          Destination Circuit=(56955)
Source GroupID=(0)              Destination GroupID=(0)

Discard filter rule from "Exceptions" list
Filter Protocol Type=(IP)
Source Interface Type=(BOARD)   Destination Interface Type=(Any)
Source Address=(Any Address)    Destination Address=(Any Address)
Source Interface Number=(1)     Destination Interface Number=(0)
Source Port Range=(0-0)         Destination Port Range=(0-0)
Source TOS=(Reserved)           Destination TOS=(Reserved)
Source Group Name=(None)        Destination Group Name=(None)
Source Group ID=(0)             Destination Group ID=(0)
Source Remote System ID=(None)  Destination Remote System ID=(None)
Source Circuit=(0)              Destination Circuit=(0)
***********************************************************************

(ix) Set SKIP Forward Filter Debug=1/0

This command Starts or Stops SKIP Packet Forwarding Filter Debug. When enabled,
all forwarded SKIP packets will be written to the system console. NOTE that SKIP
is the communication protocol used between VPN hosts.

This option should be used in cases where users cannot communicate with remote
services through a VPTUNNEL with the filters enabled. Once enabled, verify that
you can see the forwarded SKIP packets at the system console.

(x) Set SKIP Discard Filter Debug=1/0

This command Starts or Stops SKIP Packet Discarding Filter Debug. When enabled,
all discarded SKIP packets will be written to the system console. NOTE that SKIP
is the communication protocol used between VPN hosts.

This option should be used in cases where users cannot communicate with remote
services through a VPTUNNEL with the filters enabled. Once enabled, verify that
you can see the forwarded SKIP packets at the system console. If the packets
should be allowed through and yet you see your SKIP packets being discarded, add
exception filters to allow the blocked traffic through (or in the case of the
SKIP traffic, simply rerun the default filters through BRDCFG).

(xi) Set Others Forward Filter Debug=1/0

This command Starts or Stops Others Packet Forwarding Filter Debug
This is the default scenario when a packet that does not have an IP, UDP, TCP,
SKIP or ICMP packet type is processed by the filtering modules. NOTE that this
will rarely happen unless customers are running packet types not defined above
such as GRE, OSPF for example.

(xii) Set Others Discard Filter Debug=1/0

This command Start or Stop Others Packet Forwarding Filter Debug
This is the default scenario when a packet that does not have an IP, UDP, TCP,
SKIP or ICMP packet type is processed by the filtering modules. NOTE that this
will rarely happen unless customers are running packet types not defined above
such as GRE, OSPF for example.

(xiii) Set Route Filter Debug=1/0

This command Starts or Stops the Route Filter Debug. Enabling this SET command
dumps some useful information to the system console indicating whether specific
routes currently existing in the routing table will get advertised or not within
RIP, OSPF external route, or EGP packets, as well as some information about
those routes.

(xiv) Set Route Allow Filter Debug=1/0

This command Starts or Stops Route Allow Filter Debug. With this filter enabled,
routes that are allowed in the RIP, OSPF external route or EGP packets are
displayed at the server console. If customers believe that the routes being
advertised via RIP, OSPF or EGP are missing information, they may be able to use
this SET command to verify that the route is indeed there.

(xv) Set Route Deny Filter Debug=1/0

This command Starts or Stops Route Deny Filter Debug. With this filter enabled,
routes that are not allowed in the RIP, OSPF external route or EGP packets are
displayed at the server console. If customers believe that the routes being
advertised via RIP, OSPF or EGP are missing information, they may be able to use
this SET command to verify that the route is being blocked.

An example of where this may help would be the following case with the default
filters in place. My server has one LAN card (130.57.61.56). With RIP enabled
and the split horizon algorithm running (default scenario), my server will not
advertise the 130.57.60.0/255.255.252.0 network back out onto the LAN. This
works as defined by the specifications, and prevents routing loops. The output
at the system console would show:-
Route to deny...
Routing protocol of peer is RIP
Rip peer address=130.57.60.0

=============================================================
2. Information required by NTS when opening support incidents
=============================================================

NOTE that sample filters for the most common setups (HTTP, DNS, SMTP, POP3)
exist in the documentation - please reference this material before escalating
calls to Novell NTS. The documentation is also available on-line from
http://www.novell.com/documentation/lg/bmee3.5/docui/index.html. In order to
quickly provide customers with solutions to their filtering problems, all open
incidents should include the following information:-

1. Network layout - this should include all IP addresses of services that the
customer is trying to access, as well as the IP addresses configured on the
Border Manager server

2. Description of problem - A clear explanation of what services are failing
when the packet filters are running e.g. I cannot access my SMTP mail through
the packet filtering firewall.

3. Console.log file showing the output of the debug commands mentioned above.
NOTE that conlog.nlm logs 100kB of information by default. Should your system
be processing a lot of IP traffic, it is recommended that the log file be
increased to 1MB by loading conlog.nlm with the paremeter 'maximum=1000'.

* If you are unsure about what protocols your applications may be
using, the output of the "ipflt_debug_on" system console command will indicate
what packets are being allowed and discarded by the filters.

* If you know exactly what protocol your failing application is
using, the individual set commands should be set e.g. if FTP is failing, set the
"Set TCP Discard Filter Debug=1" and "Set TCP Forward Filter Debug=1". NOTE that
there may be other protocols influencing the applications functionality such as
DNS.

========================================
3. Order filters actually get processed
========================================

IP Packet filtering calls take place within TCPIP.NLM under three separate
scenario's:

a) When an incoming packet is processed and the final destination is our local
IP address
b) When an incoming packet is processed and the final destination is not our
local address i.e. the packet needs to be routed by our stack and;
c) When an outgoing packet is being transmitted and our local IP address is the
source IP address

In each of the above cases, control is temporarily passed to the IPFLT31 module
to verify whether the incoming, outgoing or forwarded packet must be allowed
through, or discarded. The IPFLT31 modules sole job is to communicate to
TCPIP.NLM that the packet should be allowed or discarded. TCPIP in turn proceeds
with it's transmit, receive or forward routines if an allow is returned by
IPFLT31, or drops the packet if the deny was returned.

IPFLT31.NLM's processing goes as follows:-

1. Check if the "SET Filter Local Loopback Packets" command is enabled. As
NetWare 5 is running on top of TCPIP, all local loopback traffic must be allowed
(return allow to TCPIP) even if there exists a deny ALL filter so that local
service or application can still function normally. Forward only locally
generated packets or loopback IP addresses. NOTE that source and destination IP
address are always the same.

2. Check if the " SET Filter Packets With IP Header Options " is enabled and if
so, drop all packets contain "options" in IP header by returning a discard to
TCPIP.

3. Check for fragmentation attacks where the fragmentation fields are enabled
(fragmentation offset not equal to zero, or the more fragments flag set in the
IP header) and TCPs SYN/FIN/RST are also enabled. If this is the case, return a
discard to TCPIP.

4. Check for illegal source IP addresses and return discard if found. Examples
include 255.255.255.255, xxx.255.255.255, xxx.xxx.255.255, xxx.xxx.xxx.255,
xxx.xxx.xxx.0, multicast. NOTE that it's ok to drop destination IP address of
0.0.0.0 but do not drop source of 0.0.0.0 (DHCP client). Some implementations of
TCP/IP are vulnerable to packets that are crafted in a particular way (a SYN
packet in which the source address and port are the same as the destination i.e.
the LAND attack). In order to defend against LAND attack, we must drop all SYN
packets in which both the source IP and port are the same as the destination
i.e. spoofed. UDP can also be used to similar attack TCPIP stacks. NOTE that
Novell's TCPIP stack does not suffer from this land attack.

5. Check if the "SET Filter Subnet Broadcast Packets" parameter is enabled and
if so, drop all IP forwarding broadcast address with the xxx.xxx.xxx.255 or
xxx.xxx.xxx.0.

6. Check if anyone is trying to spoof our local source IP address. This is done
by first verifying if we're in forwarding or Local delivery mode (not transmit)
and secondly, if the source IP address belongs to this router but the packet
originated from external source (spoof). If this is the case, drop it.

7. Check if we're being 'smurf' attacked. The smurf attack relies on the router
serving a large multi-access broadcast network to frame an IP broadcast address
(such as 10.255.255.255) into a layer 2 broadcast frame (for Ethernet,
FF:FF:FF:FF:FF:FF). Generally, with IP providers and IP applications as we know
them today, this behavior should not be needed. It is recommended that
directed-broadcasts be turned off via TCPCON, to suppress the effects of this
attack. This is off by default.

8. Search the filter cache or filter database to see if the packet we're
processing has a specific rule that could be applied to it. NOTE that at this
stage, we have all the details about the packet (ip addresses, interface
information, protocol, port numbers, etc) from TCPIP and we know the
corresponding information from the configured filters. The filters are processed
in the following order to check for hits:

a) Check the exception filter list to see whether a rule exists that matches our
IP packet. If the default action is to DENY packets in the filter list, the
exception list lists packets that should be allowed. If we get a hit here, send
an allow message to TCPIP so that the stack continues processing the packet. If
the default action is to ALLOW packets in the filter list, send a deny message
to TCPIP so that it will drop the packet.

b) Assuming that the exception rule failed to provide a hit, the filters are
then processed in sequence for a hit. If no filters match the packet being
processed, we check for the default ACTION specified.

c) If the default ACTION specified is to PERMIT packets not in filter list, then
an allow will be sent back to TCPIP to continue processing the packet. If on the
other hand the default action is to DENY packets not in filter list, the deny
message will be sent back to TCPIP so that it drops the packet.

NOTE: If a match exists, and the default policy is to permit packets in the
filter list, we check to see if stateful filtering is enabled.

* If it is, we create a reverse filter and return allow to TCPIP

* If it isn't return a discard message for TCPIP to drop the packet
 

========================================
4. Other IPFLT31 available SET Commands
========================================

The following SET commands may be used to change the behaviour of the filters.
It is NOT recommended that these commands be changed from their default as they
may have a negative impact on performance and application functionality is used
incorrectly.

1. SET Filter Subnet Broadcast Packets - When this command is set to ON, the
filter modules will defend private hosts against destination IP broadcast
address attack through discards. (Settable only in AUTOEXEC.NCF) Default
Setting: ON

2. Filter Local Loopback Packets - When this command is set to ON, local
loopback packet will be subjected to filtering. Set it OFF to enhance server
performance by bypassing filter inspection. NOTE that some applications e.g.
GroupWise, make use of the loopback interface, in which case they will fail when
set to OFF. (Settable only in AUTOEXEC.NCF) Default Setting: ON

3. Shutdown Public Interface On Log Failure - When this command is set to ON,
IPFLT31 will deny IP traffic to/from public interface when logging fails. Set it
to OFF to ignore logging failure and continue to permit predefined IP traffic
to/from public interface. (Settable only in AUTOEXEC.NCF) Default Setting: ON

4. Filter Packets With IP Header Options - When this command is set to ON, IPFLT
will deny all IP packets with IP header option. (Settable only in AUTOEXEC.NCF)
Default Setting: ON

5. Filter Log Packets Without Matching Rule - When this command is set to ON
IPFLT will log all TCP/IP packets without matching filter rules. (Settable only
in AUTOEXEC.NCF) Default Setting: OFF.