Jeff, Thanks for you reply. I figured out the return route as the problem based on the output of tcpdump, but your reply is much appreciated by me and I'm sure others trying to learn more about networking will appreciate the information also. In the hopes that I can contribute information I'll explain more about the situation.
I'm trying to change something that was done earlier as a quick fix by someone else. In the beginning there was just the internal net, .8.0, and it was shared by both Linux and Windows machines (the latter in accounting). The Windows machines would suffer (more than normal) crashes, which was eventually correlated with big file transfers between Linux machines in engineering - PCB layout files for example. The quick fix was to stuff another NIC in the firewall and let it be the gateway between two subnetworks, (the Windows machines use a Linux/Samba server that also has engineering partitions). That took the traffic off the NICs in the Window boxes and made them as happy as can be expected. The Windows machines are all running on 10Mbs NICs, whereas the Linux machines on the .8.0 net were upgraded to 100 Mbs NICs once they were on a separate subnet. I discovered the connection via the firewall not too long ago when I became involved in upgrading a new server and new firewall. The leaf Bering machine is pretty much ready to deploy. The .8.24 machine will be the new Linux/Samba server once it's in place, so I plugged a 10 Mbs NIC into it on eth1 and cross connected it to another Debian box for testing. My plan of attack is this. 1) Pull the cable out of firewall for the Windows subnet and plug it into the NIC on the `will be' server, with routing setup so that the Window boxes can still access the old server. I'm assuming that the Netgear switch will soon learn the new MAC address for the .3.254 gateway. 2) Get the LEAF Bering firewall deployed - with one less NIC than the present one. 3) Shut off the Windows boxes and move their home directories to the new server. 4) Pull the old server off-line. 5) Give the new server an alias using the IP number of the old server. 6) Turn on the Windows machines. 7) Put on my hard hat. -- Sincerely, David Smead http://www.amplepower.com. On Sat, 18 May 2002, Jeff Newmiller wrote: > On Sat, 18 May 2002, David Smead wrote: > > > Tom, > > > > thevenin:/etc# cat /proc/sys/net/ipv4/ip_forward > > 1 > > > > I did that explicitly. I probably should have installed shorewall but > > since all I want to do is forward all traffic between two internal nets I > > figured it would be easy enough just to dump a few rules into iptables. > > > > Wrong! > > "forward all traffic between two internal nets" = bridging, not routing, > and you would need to use the same network across both sides of the > bridge. > > When it comes to routing, EVERY MACHINE has to know how to get to every > other machine. Mostly this is accomplished with default routes to keep > things sane... but on the internet backbone the routing tables are > horrendous to make up for that localized simplicity. You are starting to > internetwork your own networks, so here is where the rubber hits the road > in terms of learning. You have to look at the routing tables at every > involved machine and ask yourself how they will know to send packets to > the next hop along the way. Every involved machine in this case is at > least three machines: your .3.245, .3.254/.8.24, and whatever machine you > want to communicate with in .8.0/24. And packets have to know how to go > both directions. > > _IF_ your machine with NICs 192.168.3.254 and 192.168.8.24 is set up as > the default route for all other machines on both networks, you should be > able to make this work easily. I suspect 192.168.8.24 is NOT the default > route for all machines on 192.168.8.0/24, so they are dropping the > return packets because they aren't smart enough to know what to do > with those packets yet. You have a couple of choices: > > a) make it so (default routes both directions) > b) put appropriate routing entries in the router that IS the default > route for all machines on 192.168.8.0/24 so that packets destined > for 192.168.3.0/24 get sent to 192.168.8.24 ... this will pass traffic > that traffic across the .8.0 segment twice... inefficient. > c) put extra routing entries in every machine on .8.0/24 so they know to > use 192.168.8.24 > d) use masquerading to give .3.0/24 second class status in .8.0/24 > e) change the machines in .3.0/24 over to .8.0/24 addresses, and bridge > or subnet proxy-arp through the debian box, (or just wire them together). > > > --------------------------------------------------------------------------- > Jeff Newmiller The ..... ..... Go Live... > DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... > Live: OO#.. Dead: OO#.. Playing > Research Engineer (Solar/Batteries O.O#. #.O#. with > /Software/Embedded Controllers) .OO#. .OO#. rocks...2k > --------------------------------------------------------------------------- > > > > > _______________________________________________________________ > Hundreds of nodes, one monster rendering program. > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > > ------------------------------------------------------------------------ > 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 > _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ------------------------------------------------------------------------ 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
