On Wed, 15 Nov 2000, Andrew wrote: > Hello, > > I appreciate all the comments, Let's keep it up. I promise I'll post the whole > thing when I have it all figured out. My mental picture is slowly filling out. > Three specific things I've got to know though: (diagrams are just for reference) > > > LAN > > > | (172...) > > > | (eth1) > > > _/\__/\_ +---+----+ _/\__/\_ > > > / \ (63...) | | (204...) / \ > > > ( Internet )-----------+ Router +----------( Internet ) > > > \_ __ _/ (eth0) | | (eth2) \_ __ _/ > > > \/ \/ +----+---+ \/ \/ > > > (eth3)| 63.. > > > | 204.. > > > | > > > --+---------------+----------+-- <---single physical > > > | | net > > > | | (i.e. one hub) > > > | | > > > +---+---+ 63..1 +---+---+ 63..2 > > > | Linux | 63..4 | Linux | 63..3 > > > +-------+ 204..1 +-------+ 204..2 > > > 204..4 204..3 > 1. If I modify the TOS field on incomming packets with IPchains, and then route > those packets to the proper internal server on my protected network, when that > server replies, what do the TOS fields in the reply packets look like? Are they > copies of the ones that came from the outside initiating the connection routed > through my router? (I hope that's the case) Or does the kernel on the replying > machine invent some new TOS value for those packets? I really do not know. > 2. On a machine with two IP addresses on the same nic (A and B). If someone on > the internet makes a connection to IP address A. What is the source address of > reply packets in the IP header diagram above? A? (I hope that's the case too.) Yes, reply packets originate from the exact same IP address as the originating packets were sent to. At least as far as I understand the IP RFC's > 3. Finally, is it necessary for the router box above to have two addresses on > the internal network. Does it matter that the default gateway that packets, > having a 204.. source address, go to might be a 63.. address? (or vice versa, as > long as all machines are connected to the same physical network) If it doesn't > then there is no need for a second IP address on the internal side of the router > (eth3 above). If it does matter, can I put in some fancy next-hop routes on the > servers based on what the source address of reply packets ends up being? (This > would essentially completely ignore the default route) As long as there is a route from the nodes having a 204... address via the router, the IP address of the router does not matter. Let me clarify a little more. Suppose the Router only has a 63... address on the eth3 interface. To route 204 addresses from the internal servers you would set it up so that *all* addresses *but* the address of that specific internal server are routed via the Router. In the Router you can then decide where to send the packets. They will have the correct source and destination addresses, so that is not a big problem. > Something to remember (it may or may not matter to you): Valid packets coming in > on eth2 (204... above) will have a 204... destination address. Also Valid > packets coming in on eth0 (63... above) will have a 63... destination address. > Marking the packets as they come in is merely so that we can route them back on > the same interface they came in on. I don't want assymetric routes. Oh, but in that case you won't even need to do the marking. The information you need is already fully encapsulated in the IP addresses inside the packet. Ofcourse, I'm assuming there's no nasty machine doing dastardly deeds on that internal network of yours... :) Doei, Arthur. -- /\ / | arthurvl@xxxxxxxxxx | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching
