At 02:37 PM 2/23/2004 -0500, Robert K Coffman Jr - Info From Data Corporation wrote:
Ray,

Thanks for the response. Answers/comments inline:


>Offhand, I cannot think of a way to do what you want to do. Control of >gateway addresses is a function of the routing table, not of ipchains or >iptables. But perhaps I'm missing something. It might help if you clarified >a couple of things in your most recent posting.

>First, when you say the old router "could reach them all externally or
>internally via the public IP" what is the "the" IP you mean? Do you mean
>all 6 addresses were reachable via (probably) proxy arp? Or do you only
>mean the servers had reachable services via port forwarding? Or something
else?

The machines I'm referring to had IPs in the same subnet(mask/gateway) as
the external interface on the router.

This doesn't deal with my uncertainty about the old setup. Was the old router able to handle the address "xxx.xxx.xxx.142" or not? That is, did it somehow (either as its own interface with port forwarding, or via proxy arp) make that address visible on the external interface, and could it route traffic going from the server using that address successfully? If yes, you do want to understand how your predecessor accomplished it. If no, then the setup of the old router is irrelevent to your present need.


 One thing I do know is that the old
router had both interfaces plugged into the same switch, which is one of the
things I'm trying to correct.

Were the "LAN" servers we're talking about also plugged into this same switch? I suppose they must have been.


With that physical setup, and knowing as little about the configuration of the prior router as we seem to, I would not assume it was routing traffic to and from the other public addresses; the ISP may have been reaching them directly, without firewalling. It may only have been NAT'ing whatever private-address IPs were used by workstations ... the physical setup you (sort of) describe could do this, while not offering any firewalling or routing whatsoever to the public-address servers.

Even if you can't check the old router, can you check the old configurations of the servers? What did their routing tables look like? (If you feel you must conceal the actual addresses, please don't turn them into jabberwocky ... use some convention that lets us easily distinguish different hosts, gateway addresses, and netmasks.) Did they have the old router's internal IP address as their default gateway or the ISP gateway appropriate to each distinct "network"?

It's really hard to get this offbeat sort of setup working blindfolded. If you can't get this type of info, that's what your client is doing to you (and you, in turn, are doing to us).

>Second, while I understand (though do not really sympathize with) your
>desire to keep the IP addresses themselves secret, we really do need to
>know the relationship between the "xx.xx.xx" in "xx.xx.xx.25" and the
>"xxx.xxx.xxx" in "xxx.xxx.xxx.141". Are they on the same /24, to be
specific?

Once I'm up and firewalled properly I'll be happy to publish them :)

In the meantime, please figure out a way to conceal them that does not leave out information we need to know.


For example, I've assumed throughout my replies that the ISP addresses are public (routable) addresses. If they are private addresses -- some ISPs use them with customers, then do NAT upstream -- then pretty much everything I've been saying up till now is blather.

A more immediate example is the vague way you explain traceroute results below.


Not same /24.  Where I have "xx" above, it indicates two actual digits, and
for the other, three.  Anyway, here are the specifics:

xx.xx.xx.26-30
subnet mask 248
gw xx.xx.xx.25

xxx.xxx.xxx.142
subnet masklen 252
gw xxx.xxx.xxx.141

Traceroutes to both address types take same path to their destination.

What does this mean exactly? Do they all go through xx.xx.xx.25, then? Or is the penultimate address reported some different a.b.c.d value, possibly one that is the opposite-side interface of a router that services both of your gateway addresses?



>If so, it *might* work to cheat ... let the rotuer and *all* the servers
use "xx.xx.xx.25", or perhaps "xxx.xxx.xxx.141", as their gateway. Incoming
traffic will still (probably) flow through the separate gateways ... but
IP-based routing is, by design, quite tolerant of using different routes in
the different directions. (Actually, it might work to do this cheat even if
the 2 networks are not part of the same /24; it depends on configuration
decisions at the ISP's end.)

Understood.  I will try it.  Am I correct in saying that both of these
addresses have to reachable in 1 hop from the firewall??

No. The firewall needs a working route to each of these addresses, and it needs immediate (looks like 1-hop, though there may be weirdnesses like proxy arp at the ISP end) access to whichever of them it will use as its gateway.



>If you try this, you will need a route on the router to "xxx.xxx.xxx.141",
so it can receive traffic from that gateway and acknowledge it. But it need
not be a gateway entry, just an ordinary route.

Ok.

>Finally, am I correct in inferring that these two external networks ---
xx.xx.xx.24/29 and xxx.xxx.xxx.140/30 -- are on the same physical interface
(eth0, I imagine) ... the same DSL or T1 or whatever? If they are on
different interfaces, most of what I've said does not make sense for you
... and you'll have to give us those details to get good advice.

They are on the same interface, same T1, which is what made it confusing to
me.

I bet. This is an unusual setup, at a minimum ... though hardly an impossible one ... IP-based routing is awfully flexible, part of why it is also so sturdy.






-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to