In article <pan.2007.11.26.15.41.44.60803@TLCDeaf.org>, Bob S wrote:
> The devices on the internal private network require they be configured
> with their assigned public IP addresses.

Hmm - why?

Some devices need to be accessed from both sides of a NAT, and as such they
need to be configured for a URL instead of an IP address. (Web servers, for
instance)

Some devices give out a connection address to gets pushed to a client, which
gives issues with NATs. Citrix is one, but they have an altaddr switch
designed to push out a second address choice for situations like this.
Others (like iFolder) are better off using a URL.

Using a URL generally means putting in an internal DNS server (not hard) or
using a hosts entry (not hard, if accessing a device via BMgr proxy).

If these devices really want a public address, then you're going to need to
put them on the public subnet.

> 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.

Ah...

> 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.

Well, this is a company that has decided they don't want to work with a
firewall. I don't think much of that approach, but it sounds like nothing
can be done about it.


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

Essentially it sounds like you would simply be cabling a public connection
through to the devices and sticking them on the public side, using a VLAN to
segment the same switch. Which sounds fine if done correctly, but perhaps it
is just as easy to punch down cabling from a public switch right to the
ports involved in your cable plant.
>
> 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?

I'm not sure I know if there is some specific section of that TID you are
curious about. I skimmed through it and didn't see anything unusual there I
didn't know.

You definitely cannot stick a public IP address on a device, put it on the
private network, and somehow have NAT on the same or other public device get
traffic to it. But at least now I know what your thinking is.

Hmmm.

Hmmm.

OK - is there any way to put TWO addresses on the devices? If you could put
both the public and private addresses on a device, it *might* work to static
NAT the public address on the BMgr server to the private address on the
device. BMgr would have to only communicate to the device on its private
address, so it is absolutely essential that the device have a private
address.

Hmmm.

Now I'm getting a bit into the realm of 'wonder if this weird idea would
work'?

Suppose you NAT'd the public IP address on BMgr to a private address.
However, the private IP address was not assigned on the device, but instead
you also have the public IP address there. The first trick is to get BMgr
to actually get traffic to the device. The second trick is to get traffic
from the device back to BMgr.

In the first trick, it may be possible to put a static ARP table entry on
the BMgr server to tell the server that a private IP address for the device
is equal to the devices MAC address. In my thinking, BMgr would then simply
push the traffic to the MAC address, solving part A of this problem.

In the second trick, you would need to do the same thing on the device. Put
in a public address on the device as the default route, and then somehow put
in a static ARP entry for the BMgr private NIC for that address.

In theory, when packets hit either BMgr or the device, they end up going to
MAC addresses via layer 2 of the OSI model. Putting in static ARP entries
shortcuts the ARP lookup that translates IP addresses to MAC addresses.
(Having old ARP entries in memory on BMgr servers is why you can still have
static NAT inbound work to a device for some time even when you delete the
secondary IP address from the server, until the ARP table times out on the
routers involved).

I'm actually pretty sure you could set this up on BMgr and get the inbound
packets to go to the device. I'm a lot less confident that the devices
would have the capability to allow you to manipulate ARP tables in the same
way. However, maybe you could do something with a managed switch in front
of the devices.

Here's another approach. Stick another NIC in the server. Subnet your
existing public network into two segments. (You will lose some addresses in
the process). Put a small part of the subnet on the new NIC, and stick the
devices there, with public IP addresses on them. You would also have to
subnet the router in front of BMgr, and add a static route there to point to
BMgr for the other part of the (original) public subnet. The advantage of
this approach is that you could put filtering on the NIC to control traffic
to and from the devices.

But really, the simplest answer here would be to stick the devices on the
public side and give them public addresses. Issues here would be a) no
firewall to protect them (unless you set up ACL's on the internet router in
front of them), and b) perhaps they don't work well with a NAT hop between
internal clients and the devices.


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

At the moment can't spend more than a second. However, it was point #20
in the TID 10011263

Bob

On Tue, 27 Nov 2007 17:33:32 +0000, Craig Johnson wrote:

> In article <pan.2007.11.26.15.41.44.60803@TLCDeaf.org>, Bob S wrote:
>> The devices on the internal private network require they be configured
>> with their assigned public IP addresses.
>
> Hmm - why?
>
> Some devices need to be accessed from both sides of a NAT, and as such they
> need to be configured for a URL instead of an IP address. (Web servers, for
> instance)
>
> Some devices give out a connection address to gets pushed to a client, which
> gives issues with NATs. Citrix is one, but they have an altaddr switch
> designed to push out a second address choice for situations like this.
> Others (like iFolder) are better off using a URL.
>
> Using a URL generally means putting in an internal DNS server (not hard) or
> using a hosts entry (not hard, if accessing a device via BMgr proxy).
>
> If these devices really want a public address, then you're going to need to
> put them on the public subnet.
>
>> 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.
>
> Ah...
>
>> 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.
>
> Well, this is a company that has decided they don't want to work with a
> firewall. I don't think much of that approach, but it sounds like nothing
> can be done about it.
>
>
>> Right now I'm looking at setting up a Vlan connected to a switch on the
>> public side of my router. Your thoughts?
>
> Essentially it sounds like you would simply be cabling a public connection
> through to the devices and sticking them on the public side, using a VLAN to
> segment the same switch. Which sounds fine if done correctly, but perhaps it
> is just as easy to punch down cabling from a public switch right to the
> ports involved in your cable plant.
>>
>> 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?
>
> I'm not sure I know if there is some specific section of that TID you are
> curious about. I skimmed through it and didn't see anything unusual there I
> didn't know.

Point #20

>
> You definitely cannot stick a public IP address on a device, put it on the
> private network, and somehow have NAT on the same or other public device get
> traffic to it. But at least now I know what your thinking is.
>
> Hmmm.
>
> Hmmm.
>
> OK - is there any way to put TWO addresses on the devices? If you could put
> both the public and private addresses on a device, it *might* work to static
> NAT the public address on the BMgr server to the private address on the
> device. BMgr would have to only communicate to the device on its private
> address, so it is absolutely essential that the device have a private
> address.
>
> Hmmm.
>
> Now I'm getting a bit into the realm of 'wonder if this weird idea would
> work'?
>
> Suppose you NAT'd the public IP address on BMgr to a private address.
> However, the private IP address was not assigned on the device, but instead
> you also have the public IP address there. The first trick is to get BMgr
> to actually get traffic to the device. The second trick is to get traffic
> from the device back to BMgr.
>
> In the first trick, it may be possible to put a static ARP table entry on
> the BMgr server to tell the server that a private IP address for the device
> is equal to the devices MAC address. In my thinking, BMgr would then simply
> push the traffic to the MAC address, solving part A of this problem.
>
> In the second trick, you would need to do the same thing on the device. Put
> in a public address on the device as the default route, and then somehow put
> in a static ARP entry for the BMgr private NIC for that address.
>
> In theory, when packets hit either BMgr or the device, they end up going to
> MAC addresses via layer 2 of the OSI model. Putting in static ARP entries
> shortcuts the ARP lookup that translates IP addresses to MAC addresses.
> (Having old ARP entries in memory on BMgr servers is why you can still have
> static NAT inbound work to a device for some time even when you delete the
> secondary IP address from the server, until the ARP table times out on the
> routers involved).
>
> I'm actually pretty sure you could set this up on BMgr and get the inbound
> packets to go to the device. I'm a lot less confident that the devices
> would have the capability to allow you to manipulate ARP tables in the same
> way. However, maybe you could do something with a managed switch in front
> of the devices.
>
> Here's another approach. Stick another NIC in the server. Subnet your
> existing public network into two segments. (You will lose some addresses in
> the process). Put a small part of the subnet on the new NIC, and stick the
> devices there, with public IP addresses on them. You would also have to
> subnet the router in front of BMgr, and add a static route there to point to
> BMgr for the other part of the (original) public subnet. The advantage of
> this approach is that you could put filtering on the NIC to control traffic
> to and from the devices.
>
> But really, the simplest answer here would be to stick the devices on the
> public side and give them public addresses. Issues here would be a) no
> firewall to protect them (unless you set up ACL's on the internet router in
> front of them), and b) perhaps they don't work well with a NAT hop between
> internal clients and the devices.
>
>
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on
> BorderManager, go to http://www.craigjconsulting.com ***

In article <pan.2007.11.27.21.12.59.613864@TLCDeaf.org>, Bob S wrote:
> At the moment can't spend more than a second. However, it was point #20
> in the TID 10011263
>
OK - I see what you mean now. It's interesting, and I think it might work
just fine, but it's not applying to your situation.

What I think it is trying to say is that there is way to pass a particular
public IP address through static NAT without it going out on the
public-side address. I've never tried this to see if it would work, but
here is my interpretation of the concept.

First, there is a requirement here that the private side of BMgr is
configured with actual registered public addresses. This rarely occurs,
and is not applicable to your situation. We're talking two different
public subnets, one on each side of BMgr. It means that you would be
able to turn off NAT completely and still have both inbound and outbound
traffic passing through BMgr to the Internet because both sides have
registered public addresses, and routing is correctly configured.

In this extremely rare situation, if you turned on dynamic NAT, all
outbound traffic would come from the single BMgr public-side address. The
NAT would also prevent inbound traffic from getting to the internal
(public) addresses. If you did normal static NAT, it would do the usual
one-to-one mapping of one private-side address to one public-side address.

Now - if you were, in this case, to static NAT, on the public interface,
one private-side address to itself, what I think would happen is that the
packets going out of BMgr would hit that last step, and be readdressed
with that NAT address. Thus, if a packet got through BMgr from that
particular address, it would be shoved out to the internet with the same
address. What I'm not clean on is what would happen to the inbound
replies to that address. They would come back to the BMgr public side,
because routing would be set up to get them that far, but I don't see how
BMgr would have an ARP table entry to accept them back into the
public-side NIC just because there is a static NAT entry for it. And you
can't have the same address actually exist on both public and private
interfaces.

So - I'm not sure that the last sentence in point #20 actually gives
anything that can be used, and it definitely doesn't apply in your
situation (since you don't have two public subnets, one on each side of
BMgr).


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

Several square mile campus; 20+ buildings; all with several of these
problematic devices. I have fiber between each building. Physical
"upgrades" or "changes" really not practical.

What I did last night/this morning was put these devices on their own VLAN
connected directly to a switch on the Internet side of the router.
Assigned them all their public IP addresses, removed the secondary IP
assignements on the router's public NIC, removed the router's static NAT;
works like a champ.

You had some interesting thoughts on ARP. I'm wanting to take a closer
look at them when I have the time.

Thanks Craig

Bob

On Tue, 27 Nov 2007 17:33:32 +0000, Craig Johnson wrote:

> In article <pan.2007.11.26.15.41.44.60803@TLCDeaf.org>, Bob S wrote:
>> The devices on the internal private network require they be configured
>> with their assigned public IP addresses.
>
> Hmm - why?
>
> Some devices need to be accessed from both sides of a NAT, and as such they
> need to be configured for a URL instead of an IP address. (Web servers, for
> instance)
>
> Some devices give out a connection address to gets pushed to a client, which
> gives issues with NATs. Citrix is one, but they have an altaddr switch
>
<snip>