When you changed the NAT, did you use a second public IP address, or
just change the old public IP to the new secondary private IP address?

I'm wondering if the traffic isn't routing to you. You might try this
test:
1. Take off the NAT, and leave the public IP address on the BMgr
server.
2. Unload IPFLT or add ICMP exception to allow ping to/from the public
NIC.
3. Ping the public address from BMgr, and internal hosts, to make sure
it works.
4. Load filters. Set filter debug=on and then set icmp forward filter
debug=1 to be able to see ICMP (allowed) packets. Or set icmp discard
filter debug=1 to see filtered pings, if your filtering denies ICMP.
Now ping from inside or the server and check the logger screen to see
if you can see the icmp packets there. If so, go on to the next step.
5. Ping the secondary from the outside. If you don't see any icmp
packets, then your traffic is not reaching the server. (You can also
use PKTSCAN to capture and view packets if you don't want to use filter
debug).
6. If you do see packets coming in, then put the NAT back on, and check
again. You want icmp filter exceptions in now, to allow inbound icmp,
so you can see the traffic after nat happening (or use pktscan.nlm).

That should tell you something useful.

You can also use ARP Debug to see the arp packets, and replies. If you
have bridged connection, you might be seeing some problematic arp
traffic, but my experience that is that if you have an arp issue, it
would affect all secondaries on a bridged connection, not just one.

If the IP address of the problem address could fall on a broadcast or
network address, depending on the subnet mask, perhaps the ISP made a
change to subnet mask that is causing traffic to your address not to
get to you. It is essential at this point to see if traffic is making
it to BMgr from the internet or not.

With icmp exceptions, or ipflt unloaded, you want to also tracert to
the address, and see if you get to the same last hop as if you trace to
the primary BMgr address. Could be that the ISP is routing that
address incorrectly.

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to http://www.craigjconsulting.com ***