Apr. 8, 2002: This bug should be fixed with the TCP590N.EXE patch. Bug in TCPCFG.NLM in NW51SP4.EXE and with NW6SP1.EXE as well.. Result is that NAT Implicit Filtering gets enabled every time you start INETCFG. This will cause inbound traffic to reverse proxies, and (probably) to static NAT to fail. If you do not use
the TCP590N patch, be sure to SET NAT DYNAMIC MODE TO PASS THRU=ON, and you should probably do that after any Reinitialize System command.
If you take the TCPCFG.NLM from the TCP590N.EXE patch, and use it on your NetWare 6 SP1 server, that should fix the problem for NetWare 6 - just don't try to use the TCPIP files from 5.90n on a NetWare 6 server.
Dec. 17, 2001: NAT600D.EXE is available, and may help with some NAT issues.
There are a number of issues regarding NAT that may look similar. I don't really know how to title this tip, since you could be seeing:
a) The 'sleepy NAT issue - look at this link for information
b) A problem with an old NAT (ver. 1.03) after installing BorderManager 3.6 and not installing the latest NetWare support pack afterward. See tip #1 for information about that.
c) ARP issues with NAT when the public and private interfaces are connected to the same hub or switch.
d) NAT simply doesn't seem to work at all - the subject of this tip. (Also what is meant in TID's 10013831 and 10013832.)
The situation I want to cover here generally occurs if you have renamed the public interface at some point. The symptoms are (generally) as follows:
1. Dynamic NAT isn't working even though you have it correctly set up on the public IP binding.
2. Static NAT (for inbound traffic) isn't working either, even though it is correctly set up.
By 'correctly set up', I mean that you look in INETCFG and everything is fine. Yet, if you use SET TCP IP DEBUG=1 to look at your IP traffic, you can see that packets are being forwarded and NOT being NAT'd. (You see packets going out, with the private IP address, and of course no replies come back). Sometimes NAT.NLM will not even be loaded, though it
usually is.
The cause is duplicated interface definition in the SYS:ETC\TCPIP.CFG file. The cure is a simple edit of that file. Here is an example.
AutonomousSystem 0
Protocol rip on {
Interface {
Address 192.168.10.254
Port PRIVATE_EII
Status on
Cost 1
Poison off
SplitHorizon on
UpdateTime 30
GarbageTime 120
ExpireTime 180
OriginateDefault off
Version ripI
Mode normal
}
Interface {
Address 10.70.0.107
Port PUBLIC_EII
Status on
Cost 1
Poison off
SplitHorizon on
UpdateTime 30
GarbageTime 120
ExpireTime 180
OriginateDefault off
Version ripI
Mode normal
}
Interface {
Address 10.70.0.107
Port PUBLIC_EII
Status on
Cost 1
Poison off
SplitHorizon on
UpdateTime 30
GarbageTime 120
ExpireTime 180
OriginateDefault off
Version ripI
Mode normal
}
}
Protocol egp off {
}
Protocol ospf off {
Interface {
Address 192.168.10.254
Port PRIVATE_EII
Status on
Cost 1
AreaId 0.0.0.0
Priority 1
RetransmissionInterval 5
TransitDelay 1
HelloInterval 10
RouterDeadInterval 40
Nbma {
PollInterval 120
Neighbor {
}
}
}
Interface {
Address 10.70.0.107
Port PUBLIC_EII
Status on
Cost 1
AreaId 0.0.0.0
Priority 1
RetransmissionInterval 5
TransitDelay 1
HelloInterval 10
RouterDeadInterval 40
Nbma {
PollInterval 120
Neighbor {
}
}
}
Interface {
Address 10.70.0.107
Port PUBLIC_EII
Status on
Cost 1
AreaId 0.0.0.0
Priority 1
RetransmissionInterval 5
TransitDelay 1
HelloInterval 10
RouterDeadInterval 40
Nbma {
PollInterval 120
Neighbor {
}
}
}
}
Interface {
Address 192.168.10.254
Port PRIVATE_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Disabled
}
b>Interface {
Address 10.70.0.107
Port PUBLIC_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Dynamic
}
Interface {
Address 10.70.0.107
Port PUBLIC_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Disabled
}
ForwardIPSourceRouting off
NATFiltering on
The problem is right at the end. Notice the last two "Interface" entries - there are TWO ENTRIES for an interface named PUBLIC_EII with address 10.70.0.107. In this example, there are no static NAT entries, but if there were, they would be easily seen in the first of these last two entries. Note that the first entry has "NATStatus Dynamic" while the second has "NATStatus Disabled".
In this example, outbound traffic was not being dynamically NAT'd. INETCFG would see the setting for the first PUBLIC_EII interface and change NAT to dynamic or disabled just fine, whatever you put in. But the SECOND entry would never show up in INETCFG, and when INITSYS.NCF ran (in AUTOEXEC.NCF) or if a Reinitialize System was done, NAT would be enabled by the first entry, and then immediately disabled again by the second entry.
(There are also other duplicate entries in for the public interface in the routing protocols sections of the file. These don't happen to be causing an issue in this example, but should be deleted in the same way as described below).
The cure is very simple. First, make a backup copy of the file! Then, use a text editor, like Notepad, to delete the last Interface entry. Here is the last part of the above TCPIP.CFG file as it should be.
< first section of this file not shown...>
Interface {
Address 192.168.10.254
Port PRIVATE_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Disabled
}
Interface {
Address 10.70.0.107
Port PUBLIC_EII
Type lan
RouterDiscovery no
SolicitationAddress multicast
NATStatus Dynamic
}
ForwardIPSourceRouting off
NATFiltering on
In the example above, you see only the last part of the TCPIP.CFG file, and the problem interface entry has been removed.
Once you have edited the file, Reinitialize System to put the changes into effect.
If you really screwed up the file when editing it, and didn't make a backup copy, delete it and re-enter the routing, NAT Implicit Filtering, and NAT entries in INETCFG.