Environment
Novell BorderManager 3.8
Novell BorderManager 3.9
Novell NetWare 6.5 Support Pack 6
NAT.NLM Version 10.00.04 January 6, 2005
Situation
Customer has 3 different subnet bound to the same public nic:
83.xxx.xxx.36/30, where 83.xxx.xxx.38 is bound to the nic.
83.xxx.xxx.40/29, where 83.xxx.xxx.41 is bound to the nic.
212.xxx.xxx.32/29, where 212.xxx.xxx.34 is bound to the nic.
Customer has dynamic nat enable on 83.xxx.xxx.38 and works fine but the issue is with the static nats as follow:
83.xxx.xxx.42 ->
192.168.4.11 works
83.xxx.xxx.43 -> 192.168.3.11 does not work
83.xxx.xxx.44 -> 192.168.6.11 does not work
83xxx.xxx .45 -> 192.168.0.9 works
83.xxx.xxx.46 -> 192.168.0.10 works
Trace shows that when accessing 83.xxx.xxx.43, connection is immediately reset and the RST packet is sent by the 83.xxx.xxx.38 address (first bound and used as outgoing source).
Dumping the ip address to bit level reveals:
83.xxx.xxx.41 -> 01010011.xxxxxxxx.xxxxxxxx.00101001
83.xxx.xxx.42 -> 01010011.xxxxxxxx.xxxxxxxx.00101010
83.xxx.xxx.43 -> 01010011.xxxxxxxx.xxxxxxxx.00101011
83.xxx.xxx.44 -> 01010011.xxxxxxxx.xxxxxxxx.00101100
83.xxx.xxx.45 -> 01010011.xxxxxxxx.xxxxxxxx.00101101
83.xxx.xxx.46 -> 01010011.xxxxxxxx.xxxxxxxx.00101110
255.255.255.248
83.xxx.xxx.37 -> 01010011.xxxxxxxx.xxxxxxxx.00100101
83.xxx.xxx.38 -> 01010011.xxxxxxxx.xxxxxxxx.00100110
255.255.255.252
That the two non working addresses (.43 and .44) are finishing in 00 and 11 which are broadcast addresses so it looks like nat has an issue with the subnet mask used as with the /29 mask, this addresses are valid.
Resolution
Reported to engineering.
As a workaround, we change the subnet mask to 255.255.255.240, so merging both subnet in one, 83.xxx.xxx.33/28. After that, all static nats were working fine.
Additional Information
Thanks to Thorsten Trittschack to find and report the issue and help with the workaround