Static NAT to Groupwise problem

[>]

We are running GW6 on a NW6 sp3 server. We have BM 3.7 running on another NW6 sp3 server.

Currently the GW6 server is open to outside access on public IP xxx.xxx.xxx.65, port 1677. It is also open internally on a private IP 172.17.6.2, port 1677. Access via the internet on the public side works as does internal access via the private IP.

We are trying to set up public access via static NAT and BM 3.7 to the private IP.
A secondary public IP address, xxx.xxx.xxx.11 was created on the BM 3.7 server and linked in the NAT translation table to 172.17.6.2 in inetcfg. NAT Implicit Filtering is disabled. Filter exceptions were set up per Craig Johnson's Beginner's Guide to Configuring Filter Exceptions for GW access. We have checked the filter configurations and they do match the example in the book.

With filtering on, nothing gets through. With it off, we can ping the secondary address and using set tcp ip debug, see that it reaches the GW6 server which responds. Similarly we can try to access Groupwise via the secondary ip address. Debug shows that its getting through to the GW6 server, and the server replies, but the connection fails. (Clarification, this is NOT web access but simply using the GW client.)

Obviously we're doing something or several things wrong, but are not sure where to go from here. Any suggestions would be greatly appreciated!

[Craig Johnson]

In article <LgFKb.7046$VM1....@prv-forum2.provo.novell.com>, Wco...@jheng.com wrote:
> Debug shows that its getting through to the GW6 server, and the server replies, but the connection
fails. (Clarification, this is NOT web access but simply using the GW client.)
>

What is the exact debug output for the reply packet? This indicates a problem with the filter exception
for the return traffic.

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

[>]

That's just it. I know there is a filtering problem, but what I'm describing is happening with filtering turned off (unload ipflt).
The GW server replies, but the packets do NOT show up at the BM server.

>>> Craig Johnson<cra...@ix.netcom.com> 01/06/04 06:53PM >>>

[Craig Johnson]

In article <hIdLb.8885$VM1....@prv-forum2.provo.novell.com>, Wco...@jheng.com wrote:
> That's just it. I know there is a filtering problem, but what I'm describing is happening with filtering turned off (unload ipflt).
> The GW server replies, but the packets do NOT show up at the BM server.
>

Then you have a routing issue there. Does the GW server have a default route?

Why do you think there is a filtering issue with filters not even loaded?

[>]

Maybe the original post wasn't clear on that - "With filtering on, nothing gets through. With it off, we can ping the secondary address and using set tcp ip debug, see that it reaches the GW6 server which responds."
When filtering is on, I cannot ping through the NAT'ed address to the GW6 server.
When I unload ipflt, I can successfully ping it.

There may very well be a routing issue, I will double check that as soon as I can Unfortunately in the last few days, hardware & software has been crashing left & right - the main tape backup unit, ArcServe causing cpu utilization to lock at 100% ,flakey NIC drivers in work stations, mystery crashes in AutoCad, etc. so this problem hasn't gotten much attention lately. Looks like I may be posting in a number of these forums.

Thanks

>>> Craig Johnson<cra...@ix.netcom.com> 01/08/04 08:39PM >>>

[Craig Johnson]

In article <R5ALb.10222$VM1....@prv-forum2.provo.novell.com>, Wco...@jheng.com wrote:
> Maybe the original post wasn't clear on that - "With filtering on, nothing gets through. With it off, we
can ping the secondary address and using set tcp ip debug, see that it reaches the GW6 server which
responds."
>

OK, I think what you need to find out is if the GW server is actually sending those replies back out or
not. I've seen cases where NetWare servers look like they are sending packets, but are not, and it is
usually related to some weird issue with the default route. (Try deleting it in TCPCON and adding it
back).

I assume you have run debug on both servers to see icmp packets coming into the BMgr server, getting to the
GW server, and not seeing a reply back on the BMgr server.