am not having any luck getting a static NAT pass-through to work.

BM3.8/NW6.5 all patched to the latest patches (no betas). IPFLT is NOT
loaded.

My internal network on one LAN all have 10.100.xxx.xxx private addresses.
Dynamic NAT works great.

I have secondary public IP addresses bound to my public NIC. Static NAT
mapping between the secondary public IP addresses and the couple of
individual private addresses work just fine. In other words, all has been
working fine.

I need to give one of those internal resources its public IP address
(change it's private to its public).

OK, I went into the NAT table and changed the proper public <-> private to
public <-> public (identical addresses). I changed the internal computer
to it's public address/mask with the same default gateway the server is
using. The internal computer can now only ping itself; can't even ping
it's default gateway. I did reinitialize, and also restarted. I can not
get the pass-through connection to work.

Any thoughts will be well received.

Bob

Sorry for the double post. Have no idea how it happened.


Bob S wrote:
> am not having any luck getting a static NAT pass-through to work.
>
> BM3.8/NW6.5 all patched to the latest patches (no betas). IPFLT is NOT
> loaded.
>
> My internal network on one LAN all have 10.100.xxx.xxx private addresses.
> Dynamic NAT works great.
>
> I have secondary public IP addresses bound to my public NIC. Static NAT
> mapping between the secondary public IP addresses and the couple of
> individual private addresses work just fine. In other words, all has been
> working fine.
>
> I need to give one of those internal resources its public IP address
> (change it's private to its public).
>
> OK, I went into the NAT table and changed the proper public <-> private to
> public <-> public (identical addresses). I changed the internal computer
> to it's public address/mask with the same default gateway the server is
> using. The internal computer can now only ping itself; can't even ping
> it's default gateway. I did reinitialize, and also restarted. I can not
> get the pass-through connection to work.
>
> Any thoughts will be well received.
>
> Bob

Hi,

Bob S wrote:
>
> I need to give one of those internal resources its public IP address
> (change it's private to its public).

That won't work, without physically connecting that device to the public
network too, in which case BM and NAT won't come into play at all. What
exactöy are you trying to achieve?

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de

As a follow on, I've been through TID 10011263. No luck at all.

Hi,

Bob wrote:
>
> As a follow on, I've been through TID 10011263. No luck at all.

Did you see my reply? What you try to do there is completely impossible.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de

Hi,

Thanks so much for this information. Let me explain in more detail.

I have a couple of devices that can not function
in a public <-> private static NAT environment. They must be physically
assigned public IP addresses. These devices are on our private internal
campus network. There will be regular communication between these
devices and like devices on the Internet.

Perhaps you can provide meaning to this: (TID 10011263)

<Begin quote>
20. Q: Can a single NAT-enabled router allow some users
to utilize NAT and allow other users on the same Ethernet
interface to continue with their own IP addresses?
<snip>
Yes in 'static' or 'static and dynamic' mode. This is done
by configuring the non translated IP address as the same public and
private IP address in the mapping mode.
<end quote>


On Tue, 20 Nov 2007 18:42:28 +0000, Massimo Rosen wrote:

> Hi,
>
> Bob S wrote:
>>
>> I need to give one of those internal resources its public IP address
>> (change it's private to its public).
>
> That won't work, without physically connecting that device to the public
> network too, in which case BM and NAT won't come into play at all. What
> exactöy are you trying to achieve?
>
> CU,

Hi,

Bob S wrote:
>
> Hi,
>
> Thanks so much for this information. Let me explain in more detail.
>
> I have a couple of devices that can not function
> in a public <-> private static NAT environment. They must be physically
> assigned public IP addresses.

Then they have to be physically connected to the public network too.
Although I wonder what type of devices that is. Only very few things
really can't work with a static NAT.

> Perhaps you can provide meaning to this: (TID 10011263)

No. It's nonsense. I'll get it changed or clarified.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de

In article <pan.2007.11.14.18.14.40.590247@TLCDeaf.org>, Bob S wrote:
> OK, I went into the NAT table and changed the proper public <-> private to
> public <-> public (identical addresses). I changed the internal computer
> to it's public address/mask with the same default gateway the server is
> using. The internal computer can now only ping itself; can't even ping
> it's default gateway. I did reinitialize, and also restarted. I can not
> get the pass-through connection to work.
>
This makes no sense.

Why does the static NAT you had before not work for your purposes?

What you did with the nat to itself was essentially tell the BMgr server to
send any traffic out on that address with a source address of that address.
This can be useful in very limited circumstances. However, it makes no
sense in this application. Having the internal device with the same address
- and on the internal segment to boot - is simply making that internal
device unusable.

Static NATing the internal device is the correct approach. Perhaps you just
needed to update some filtering to make it work in the old config.

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

Hi Craig

The devices on the internal private network require they be configured
with their assigned public IP addresses. As for filtering, IPFLT is not
loaded; never has been. Let's not get side tracked as to why these
devices can not work behind a static public <-> private NAT. Already been
through this with the vendors and others plus have looked at the packet
traces. For the curious, they work fine talking with their counterparts
on the Internet; they just can not talk to each other internally on the
private network if they are assigned a private IP address. And, it's
because they have to call home to mama before they can talk to each other;
a process that gets corrupted when wanting to talk with each other on a
private network. It's limitations in the way the company has implemented
certain protocols; they admit it; are aware of it; but has no intentions
of addressing this issue in the near future.

Right now I'm looking at setting up a Vlan connected to a switch on the
public side of my router. Your thoughts?

However, I certainly would like to know your thoughts on what senarios
would be appropriate for the public <-> public address mapping that the
TID 10011263 says can be done?

Thanks Craig, hope your holidays are fun.

Bob

On Sat, 24 Nov 2007 16:35:56 +0000, Craig Johnson wrote:

> In article <pan.2007.11.14.18.14.40.590247@TLCDeaf.org>, Bob S wrote:
>> OK, I went into the NAT table and changed the proper public <-> private to
>> public <-> public (identical addresses). I changed the internal computer
>> to it's public address/mask with the same default gateway the server is
>> using. The internal computer can now only ping itself; can't even ping
>> it's default gateway. I did reinitialize, and also restarted. I can not
>> get the pass-through connection to work.
>>
> This makes no sense.
>
> Why does the static NAT you had before not work for your purposes?
>
> What you did with the nat to itself was essentially tell the BMgr server to
> send any traffic out on that address with a source address of that address.
> This can be useful in very limited circumstances. However, it makes no
> sense in this application. Having the internal device with the same address
> - and on the internal segment to boot - is simply making that internal
> device unusable.
>
> Static NATing the internal device is the correct approach. Perhaps you just
> needed to update some filtering to make it work in the old config.
>
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on
> BorderManager, go to http://www.craigjconsulting.com ***