Keep your champagne, just send me the configuration files you modified so I can put them into the QoS HOWTO :-)
Congratulations!!!! Jack On Fri, 1 Feb 2002, Reginald R. Richardson wrote: > Jack...Jack.. > > U should see me man...I'm jumping for joy, my family thinks i'm going CRAZY....It's >working....it's work.... > > this is the key to it > http://lists.samba.org/pipermail/netfilter/2000-November/006089.html > i did this on box3, and now that the default route is off...i can BROWSE the net >from WS 192.168.10.3 but i can't ping, which is understandable, cause i didn't >include any rule for icmp as yet... > > Yeppie...yeppie... > > Time for some CHAMPAGINE.. > do u care for some??? > > > On Wed, 30 Jan 2002 06:25:52 -0800 (PST), Jack Coates wrote: > >I don't know for sure; I quit trying when it became clear that this > >is > >impossible to do with one box, so I don't remember the syntax. > >Looking > >at http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO-11.html, it looks > >like the rule you want is possible, just copy the example and use 80 > >instead of 25. If you've already done that and you're sure the rest > >of > >your rules are okay, I don't know. > > > >Here's a question for you though -- can you establish a TCP > >connection > >along the test path _without_ HTTP, e.g. bypassing the port 80 rule? > >What happens if you ping from the test workstation, is it > >successful? If > >neither is possible, then you might look at whether BOX1 can even > >route > >anything to 192.168.10.0 at all. Linux 2.2 kernels are supposed to > >handle this sort of local routing themselves, but... > > > >For that matter, there are also some default settings in Dachstein > >which > >prevent having RFC1918 addressing on both sides, not sure what you > >change to fix that. Sorry if you already have. > > > >Good luck! > >Jack > > > >On Tue, 29 Jan 2002, Reginald R. Richardson wrote: > > > >> Jack, what u say makes lots of sense to me, i do have it set that > >>all HTTP traffic be sent to box1 via eth2(box3) > >> > >> Well, with my limited amount of linux experience, i need some help > >>on the commands of getting done what u suggested and that is: > >> > >> "the rule should be to send all traffic with a DESTINATION port of > >>80 to BOX1, but route SOURCE 80 normally" > >> > >> Below is my ip ru listing, with the fwmark of 2 for HTTP (port > >>80), which is then routed to 192.168.1.6(box1) via dev eth2 (box3) > >> > >> All i need is a simple how-to, one the command line for my > >> ip route for the TABLE "Cable" > >> as u can see below it's only just routing all traffic to > >>192.168.1.6 via dev eth2 > >> > >> thnks > >> > >> ip ru ls > >> 0: from all lookup local > >> 32764: from all fwmark 1 lookup adsl > >> 32765: from all fwmark 2 lookup cable > >> 32766: from all lookup main > >> 32767: from all lookup default > >> > >> # ip ro ls table cable > >> default via 192.168.1.6 dev eth2 > >> > >> # ipchains > >> Chain input (policy ACCEPT: 100740 packets, 8739050 bytes): > >> prot opt tosa tosx ifname mark outsize source destination > >>ports > >> tcp ------ 0xFF 0x00 * 0x2 192.168.10.0/24 0.0.0.0/0 * > >>-> 80 > >> udp ------ 0xFF 0x00 * 0x2 192.168.10.0/24 0.0.0.0/0 > >>*-> 80 > >> Chain forward (policy ACCEPT: 75921 packets, 6589166 bytes): > >> Chain output (policy ACCEPT: 95403 packets, 8331173 bytes): > >> > >> > >> > >> On Tue, 29 Jan 2002 07:11:07 -0800 (PST), Jack Coates wrote: > >> >Looking at the timestamps, I have BOX3-eth1 and BOX3-eth2 > >>backwards. > >> >BOX3 is doing something wrong with the return traffic, and my > >>guess > >> >is > >> >that its policy routing rule says to send ALL HTTP-related > >>traffic to > >> >BOX1. If so, the rule should be to send all traffic with a > >> >DESTINATION > >> >port of 80 to BOX1, but route SOURCE 80 normally. > >> > > >> >Hope that helps, > >> >Jack > >> > > >> >On Mon, 28 Jan 2002, Jack Coates wrote: > >> > > >> >> Well, here's what I've got so far -- I didn't get any sleep last > >> >>night > >> >> and need to go fix that, but here's a few questions and > >> >>assumptions: > >> >> > >> >> SYN 192.168.10.3:2727 -> eth1[BOX3]eth2 -> eth1[BOX1]ppp0 > >> >> NAT:62.234.0.234.61706 -> www.monkeynoodle.org:80 > >> >> > >> >> packet goes into BOX3 > >> >> 06:34:16.517303 192.168.10.3.2727 > 66.1.155.123.80: S > >> >> 1254467949:1254467949(0) win 16384 <mss 1460,nop,nop,sackOK> > >>(DF) > >> >> packet comes out of BOX3 > >> >> 06:34:16.517089 192.168.10.3.2727 > 66.1.155.123.80: S > >> >> 1254467949:1254467949(0) win 16384 <mss 1460,nop,nop,sackOK> > >>(DF) > >> >> packet goes into BOX1 and gets NAT'd > >> >> ASSUMPTION -- BOX1's clock is 15 seconds fast. > >> >> packet comes out of BOX1 > >> >> 06:34:31.223667 62.234.0.234.61706 > 66.1.155.123.80: S > >> >> 1254467949:1254467949(0) win 16384 <mss 1460,nop,nop,sackOK> > >>(DF) > >> >> > >> >> 2/10ths of a second later... > >> >> 192.168.10.3:2727 <- eth1[BOX3]eth2 <- eth1[BOX1]ppp0 > >> >> NAT:62.234.0.234.61706 <- www.monkeynoodle.org:80 ACK > >> >> > >> >> packet goes into BOX1 and gets NAT'd > >> >> 06:34:31.443667 66.1.155.123.80 > 62.234.0.234.61706: S > >> >> 3199824407:3199824407(0) ack 1254467950 win 5840 <mss > >> >> 1412,nop,nop,sackOK> (DF) > >> >> the BOX3-eth2 trace never shows packets coming back from the > >> >>Internet, > >> >> only leaving. > >> >> ASSUMPTION: packet goes into BOX3 > >> >> packet comes out of BOX3 > >> >> 06:34:16.747496 66.1.155.123.80 > 192.168.10.3.2727: S > >> >> 3199824407:3199824407(0) ack 1254467950 win 5840 <mss > >> >> 1412,nop,nop,sackOK> (DF) > >> >> > >> >> I'll finish up tomorrow night, but BOX3 ETH2 is a place to start > >> >> looking. > >> >> Jack > >> >> > >> >> > >> >> On Mon, 28 Jan 2002, Reginald R. Richardson wrote: > >> >> > >> >> > Ok Jack, talk to me know, have some info for you...i think we > >> >>going to get it talk now, i think i see the problem, but > >> >> > the solution, i need you helping minds again... > >> >> > > >> >> > Attached you'll find tcpdump files of what's happening with > >> >>these Routers overhere in Europe.. > >> >> > > >> >> > My understanding of the DUMP, is not up to par, but according > >>to > >> >>me this is what i see and assumed, but as always, u can > >> >> > correct if i'm wrong.. > >> >> > > >> >> > Workstation 192.168.10.3 is sending his HTTP (80) traffic to > >>his > >> >>default router Box3 (eth1) 192.168.10.254, and i can > >> >> > clearly see him forward it according the the CABLE rule > >> >>(fwmark2) to Box1 (eth), so no problem there, after that short > >> >> > journey, i see Box1 (eth1) forwards it to the Internet via > >>ppp0, > >> >>so everybody happy there....... > >> >> > > >> >> > No the Internet "www.monkeynoodle.org" kindly accepts this > >> >>request, and for some reason or the other, decides to answer > >> >> > to this poor request coming from europe......as i check > >>again, i > >> >>can see PPP0 telling www.monkeynoodle.org, yes, yes..i > >> >> > sent u a request...so gimme my reply, and he kindly answers > >> >>that reply, and forwards it to his next door neighbour > >> >> > (box1 eth1), no he feels good, that he gets his reply back, > >>and > >> >>being a good guy, he sends it back down the chain to > >> >> > BOX3 eth2, > >> >> > No box2 see this Port 80 packet coming in LOUD and clear...and > >> >>kindly answers it with joy, to forward it back to the > >> >> > poor Workstation, that's waiting in vain for a reply, but eth2 > >> >>has to send it via his neighbour, which is BOX3 eth1, > >> >> > which i can clearly see him doing..... > >> >> > > >> >> > But wait just one sec there..(Houston, i think we have a > >> >>problem), yep....eth1 is either refusing to answer, or he's > >> >> > just not seeing this Port80 packet coming to him from eth1 > >> >>...TIMEOUT...RAIN CHECK..... > >> >> > > >> >> > Now were here wondering WHAT the hell went wrong, is that, > >>eth1 > >> >>is angry with his neighbour eth2 and refuse to answer, > >> >> > or is it that he don't know the way back to send the packet > >>back > >> >>to the poor workstation (192.168.10.3). > >> >> > > >> >> > Now, help us (me, myself and I) out there, what is missing > >> >>here...well i think you read my entire ip routes and ip > >> >> > tables etc, so u have enough info to see whaz wrong, if any > >>more > >> >>info is needed please let me know and i'll send it > >> >> > live and direct to you... > >> >> > > >> >> > attached u'll find tcpdumps, and somekind of ASCII netdiagram > >> >>of HomeNet in Europe....struggling to offer Mommy, Daddy > >> >> > and kids a descent internet connection.. > >> >> > > >> >> > BTW:i was looking at leaf for the ipcheck, but ain't find > >> >>it...do u have a link for me... > >> >> > thnks for the help so far.. > >> >> > > >> >> > I think we going to get it work now.....but this is PHASE I, > >> >>Phase II to follow, that is PORT FORWARDING, had some > >> >> > problems with it, but will check it out again, after we have > >> >>this running like a TRAIN > >> >> > > >> >> > Once again, thanks for your help and your ENERGY..... > >> >> > I think i'll get this one working, i'm seeing the LIGHT, > >>better > >> >>than when i was trying it with 1BOX, and two, external > >> >> > interfaces... > >> >> > > >> >> > I HAVE A DREAM/HOPE, that it gonna work.. > >> >> > > >> >> > cheers > >> >> > Reggie > >> >> > > >> >> > > >> >> > On Sat, 26 Jan 2002 15:35:55 -0800 (PST), Jack Coates wrote: > >> >> > >On Sat, 26 Jan 2002, Reginald R. Richardson wrote: > >> >> > > > >> >> > >> Jack../Charles > >> >> > >> > >> >> > >> we starting to see some light, but i guess that the lack of > >> >>some > >> >> > >>Linux Firewall > >> >> > >> knowledge holding us back over here... > >> >> > >> but here's what.. > >> >> > >> > >> >> > >> > >> >> > >> On my BOX3 Non NAT/Firewall Box > >> >> > >> if i add a default route on this box, via the CABLE Router > >> >>(Box1), > >> >> > >>then all > >> >> > >> HTTP traffic goes out to the internet without a problem, > >>and > >> >>also, > >> >> > >>all the > >> >> > >> other traffic that has to go to the internet via Box2, > >>goes to > >> >> > >>Box2, so here i > >> >> > >> can see that Box3, is sending the traffic to the correct > >> >>InterNet > >> >> > >>Router, so in > >> >> > >> other words, he's a very nice Traffic Police, he's routing > >>as > >> >> > >>COMMANDED too.. > >> >> > >> > >> >> > >> For some reason, i can't figure out, why the return traffic > >> >>is not > >> >> > >>going back > >> >> > >> to the workstation without any problem.. > >> >> > >> > >> >> > > > >> >> > >To figure this out you need to use tcpdump; it's probably > >> >>getting > >> >> > >lost > >> >> > >between box1 or 2 and box3. > >> >> > > > >> >> > >> but what i found strange, is that from the moment i say the > >> >>the > >> >> > >>default gateway > >> >> > >> is box 1 eg. > >> >> > >> > >> >> > >> "ip route add 0/0 via 192.168.1.6" (box1), then i have no > >> >>problem > >> >> > >>internet > >> >> > >> traffic proceeds, but from the moment i removed this > >>route, no > >> >> > >>more internet... > >> >> > >> > >> >> > >> to the little knowledge i have, i don't believe that BOX3 > >> >>should > >> >> > >>have an > >> >> > >> default route, because i assume that the LOOKUP table is > >> >>supposed > >> >> > >>to tell him > >> >> > >> where to send the data for the specific Traffice Type. > >> >>(correct me > >> >> > >>if i'm > >> >> > >> wrong) > >> >> > >> > >> >> > > > >> >> > >Maybe... a default route could be helpful if you get > >>everything > >> >>else > >> >> > >configured right. > >> >> > > > >> >> > >> On Box1 and Box2, is the normal settings that came by > >> >> > >>default..with Dachsten > >> >> > >> onliest changes i have in those boxes is a static route > >>back > >> >>to the > >> >> > >> 192.168.10.0 network, and i commented out the ipchains > >> >>commands > >> >> > >>that block > >> >> > >> traffic to the 10.0.0.0 network on Box2 (see below) > >> >> > >> > >> >> > >> Box1 (Cable) > >> >> > >> #ip route > >> >> > >> 62.234.0.1 dev ppp0 proto kernel scope link src > >> >>62.234.0.234 > >> >> > >> 192.168.1.4/30 dev eth1 proto kernel scope link src > >> >>192..168.1.6 > >> >> > >> 192.168.10.0/24 via 192.168.1.5 dev eth1 > >> >> > >> default via 62.234.0.1 dev ppp0 > >> >> > >> > >> >> > >> #ip addr sh > >> >> > >> 7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast > >> >>qlen > >> >> > >>100 > >> >> > >> link/ether 00:10:4b:bb:c8:25 brd ff:ff:ff:ff:ff:ff > >> >> > >> 8: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc > >> >> > >>pfifo_fast qlen 100 > >> >> > >> link/ether 00:c0:f0:12:f1:c8 brd ff:ff:ff:ff:ff:ff > >> >> > >> inet 192.168.1.6/30 brd 192.168.1.7 scope global eth1 > >> >> > >> > >> >> > >> Box2 (Adsl) > >> >> > >> #ip route > >> >> > >> 192.168.1.0/30 dev eth1 proto kernel scope link src > >> >>192..168.1.2 > >> >> > >> 10.0.0.0/24 dev eth0 proto kernel scope link src > >> >>10.0.0..100 > >> >> > >> 192.168.10.0/24 via 192.168.1.1 dev eth1 > >> >> > >> default via 10.0.0.138 dev eth0 > >> >> > >> > >> >> > >> #ip addr sh > >> >> > >> 7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast > >> >>qlen > >> >> > >>100 > >> >> > >> link/ether 08:00:00:22:20:34 brd ff:ff:ff:ff:ff:ff > >> >> > >> inet 10.0.0.100/24 brd 10.0.0.255 scope global eth0 > >> >> > >> 8: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc > >> >> > >>pfifo_fast qlen 100 > >> >> > >> link/ether 00:40:05:27:cb:9a brd ff:ff:ff:ff:ff:ff > >> >> > >> > >> >> > >> This is a little tricky one, cause my ADSL provider Network > >> >> > >>requires us to > >> >> > >> create a VPN connection between my router and the ADSL > >>MODEM, > >> >>so > >> >> > >>therefore the > >> >> > >> default route is the ADSL Modem 10.0.0.138 (before u > >>asked, i > >> >> > >>commented out the > >> >> > >> IPCHAINS rules in this router that block the RFC ip's of > >> >>10.0.0.0) > >> >> > >> > >> >> > >> >From this router i can ping the internet without any > >> >>problem, so > >> >> > >>therefore i > >> >> > >> have internet connectivity. > >> >> > >> > >> >> > >> Here is what i have on Box3 > >> >> > >> #ip addr sh > >> >> > >> 7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast > >> >>qlen > >> >> > >>100 > >> >> > >> link/ether 00:10:4b:bb:c8:25 brd ff:ff:ff:ff:ff:ff > >> >> > >> 8: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc > >> >> > >>pfifo_fast qlen 100 > >> >> > >> link/ether 00:c0:f0:12:f1:c8 brd ff:ff:ff:ff:ff:ff > >> >> > >> inet 192.168.1.6/30 brd 192.168.1.7 scope global eth1 > >> >> > >> > >> >> > >> > >> >> > >> # ip ru ls > >> >> > >> 0: from all lookup local > >> >> > >> 32764: from all fwmark 1 lookup adsl > >> >> > >> 32765: from all fwmark 2 lookup cable > >> >> > >> 32766: from all lookup main > >> >> > >> 32767: from all lookup default > >> >> > >> > >> >> > >> > >> >> > >> # ipchains > >> >> > >> Chain input (policy ACCEPT: 100740 packets, 8739050 bytes): > >> >> > >> prot opt tosa tosx ifname mark outsize source > >> >>destination > >> >> > >> ports > >> >> > >> tcp ------ 0xFF 0x00 * 0x2 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 80 > >> >> > >> udp ------ 0xFF 0x00 * 0x2 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 80 > >> >> > >> udp ------ 0xFF 0x00 * 0x2 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 443 > >> >> > >> tcp ------ 0xFF 0x00 * 0x2 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 443 > >> >> > >> tcp ------ 0xFF 0x00 * 0x2 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 110 > >> >> > >> tcp ------ 0xFF 0x00 * 0x2 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 25 > >> >> > >> tcp ------ 0xFF 0x00 * 0x1 192..168.10.0/24 > >> >>0.0.0.0/0 * > >> >> > >> -> 1214 > >> >> > >> Chain forward (policy ACCEPT: 75921 packets, 6589166 > >>bytes): > >> >> > >> Chain output (policy ACCEPT: 95403 packets, 8331173 bytes): > >> >> > >> > >> >> > >> # ip ro ls table cable > >> >> > >> default via 192.168.1.6 dev eth2 > >> >> > >> > >> >> > >> # ip rou ls table adsl > >> >> > >> default via 192.168.1.2 dev eth0 > >> >> > >> > >> >> > >> # ip route > >> >> > >> 192.168.1.0/30 dev eth0 proto kernel scope link src > >> >>192..168.1.1 > >> >> > >> 192.168.1.4/30 dev eth2 proto kernel scope link src > >> >>192..168.1.5 > >> >> > >> 192.168.10.0/24 dev eth1 proto kernel scope link src > >> >> > >>192.168.10.254 > >> >> > >> > >> >> > > > >> >> > >Looks alright from a cursory glance, tcpdump is the only way > >>to > >> >>tell > >> >> > >if > >> >> > >it's really working like you expect. > >> >> > > > >> >> > >> > >> >> > >> Jack, > >> >> > >> What did u mean with this comment, don't under what u mean > >> >>with > >> >> > >>"tc" > >> >> > >> "Make sure you have proper tc rules for _both_ directions" > >> >> > >> > >> >> > > > >> >> > >Sorry, I meant fwmark rules; tc is a tool from the same > >>iproute2 > >> >> > >suite > >> >> > >used for QoS. > >> >> > > > >> >> > >> Do hope i have provided enough information, so that i can > >>get > >> >> > >>these babies talk > >> >> > >> to me, and do what they should do. > >> >> > >> > >> >> > >> Can some one give me a tip, on what i can do to tell BOX3 > >> >>that if > >> >> > >>he routes > >> >> > >> HTTP traffic to BOX1, and there is no reply, then he should > >> >>send > >> >> > >>it to Box2 > >> >> > >> > >> >> > > > >> >> > >First concentrate on getting fwmark to work, then worry about > >> >> > >failover > >> >> > >:-) To do this you'll just find the ipcheck script from the > >> >>LEAF site > >> >> > >and modify it to your needs. > >> >> > > > >> >> > >> thnks alot > >> >> > >> > >> >> > >> On Sat, 26 Jan 2002 08:26:44 -0800 (PST), Jack Coates > >>wrote: > >> >> > >> >Been there done that :-) Make sure you have proper tc > >>rules > >> >>for > >> >> > >> >_both_ > >> >> > >> >directions, and try tcpdump on all three boxes. Not sure > >>if > >> >>you > >> >> > >> >already > >> >> > >> >knew this, but tcpdump has a ton of command line options > >>to > >> >>make > >> >> > >>it > >> >> > >> >just > >> >> > >> >show the packets you're looking for. Also double-check > >>your > >> >>NAT > >> >> > >>and > >> >> > >> >the > >> >> > >> >routing on box 1 and 2. I suspect something like this is > >> >> > >>happening to > >> >> > >> >you: > >> >> > >> > > >> >> > >> >z.z.z.z:1024 SYN -> box3 -> box1(NATSRC=x.x.x.x:4001) -> > >> >> > >>a.a.a.a:80 > >> >> > >> > > >> >> > >> >z.z.z.z:1024 box3 <ACK loops back to> box1 <- > >> >> > >>a.a.a.a:80 > >> >> > >> > > >> >> > >> >So on each box get two consoles (one for eth0 and one for > >> >>eth1), > >> >> > >> >then do > >> >> > >> >a: > >> >> > >> >tcpdump -i eth[0|1] -n port 80 and host 66.1.155.123 > >> >> > >> > > >> >> > >> >and then go to your client workstation and browse to > >> >> > >> >www.monkeynoodle.org. The tcpdump output should make it > >>very > >> >>clear > >> >> > >> >what > >> >> > >> >happened. > >> >> > >> > > >> >> > >> >Good luck! > >> >> > >> >Jack > >> >> > >> > > >> >> > >> >On Sat, 26 Jan 2002, Reginald R. Richardson wrote: > >> >> > >> > > >> >> > >> >> Me again.. > >> >> > >> >> > >> >> > >> >> We getting there, with this 3 router box... > >> >> > >> >> > >> >> > >> >> Question: > >> >> > >> >> I reach so far as having Router3 sending the HTTP > >>traffic > >> >>to the > >> >> > >> >>correct > >> >> > >> >> router, the SMTP traffic to the correct box also, as i > >>use > >> >>my > >> >> > >> >>TCPDUMP on my BOX > >> >> > >> >> connecected to the Internet, i can see the HTTP traffic > >> >>being > >> >> > >> >>transmitted to > >> >> > >> >> the internet, but my problem is it's not being return to > >> >>the > >> >> > >> >>requesting > >> >> > >> >> workstation. > >> >> > >> >> > >> >> > >> >> this is what my HTTP lookup table looks like > >> >> > >> >> ip rout ls table http > >> >> > >> >> default dev eth2 scope link > >> >> > >> >> > >> >> > >> >> I must say, that if i clear this table, and let BOX3, > >>with > >> >>a > >> >> > >> >>DEFAULT GW to the > >> >> > >> >> internet via BOX1 or BOX2, then the Workstation can > >> >>connect to > >> >> > >>the > >> >> > >> >>net without > >> >> > >> >> any problems. > >> >> > >> >> > >> >> > >> >> I don't have the slightest idea now where i should look > >> >> > >> >> > >> >> > >> >> thnks > >> >> > >> >> > >> >> > >> >> On Wed, 23 Jan 2002 14:14:37 -0600, Charles Steinkuehler > >> >>wrote: > >> >> > >> >> >Everything seems to be moving like a charm, not getting > >> >>the IP > >> >> > >> >>ROUTE > >> >> > >> >> >per TCP > >> >> > >> >> >Port talking to healthy, but still working on it.. > >> >> > >> >> > > >> >> > >> >> >question. > >> >> > >> >> >U mentioned why not use "equal-weight routing", i > >>checked > >> >>at > >> >> > >> >>googles > >> >> > >> >> >to get > >> >> > >> >> >more info about this, it seems a nice way to go...but > >>can > >> >>u > >> >> > >>guide > >> >> > >> >>me > >> >> > >> >> >to a > >> >> > >> >> >weblink where i can find more info on how to implement > >> >>this on > >> >> > >>my > >> >> > >> >> >Box3, > >> >> > >> >> > > >> >> > >> >> >CS> Start with the Advanced Routing HOWTO, from > >> >>linuxdoc..org or > >> >> > >> >> >similar...if > >> >> > >> >> >you get your port-based routing tables setup, you'll be > >> >>over > >> >> > >>most > >> >> > >> >>of > >> >> > >> >> >the > >> >> > >> >> >hurdles... > >> >> > >> >> > > >> >> > >> >> >CS> Keep us all posted on your progress...if you get > >>this > >> >> > >> >>working, > >> >> > >> >> >it's the > >> >> > >> >> >first step to doing the same thing cleanly with a > >>single > >> >>box. > >> >> > >> >> > > >> >> > >> >> >Charles Steinkuehler > >> >> > >> >> >http://lrp.steinkuehler.net > >> >> > >> >> >http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -------------------------------------------------------- > >>--- > >> >>-- > >> >> > >> >> Reginald R. Richardson > >> >> > >> >> [EMAIL PROTECTED] on 1/26/2002 > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> > >> >> Leaf-user mailing list > >> >> > >> >> [EMAIL PROTECTED] > >> >> > >> >> https://lists.sourceforge.net/lists/listinfo/leaf-user > >> >> > >> >> > >> >> > >> > > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> ----------------------------------------------------------- > >>-- > >> >> > >> Reginald R. Richardson > >> >> > >> [EMAIL PROTECTED] on 1/26/2002 > >> >> > >> > >> >> > >> > >> >> > > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > ------------------------------------------------------------- > >> >> > Reginald R. Richardson > >> >> > [EMAIL PROTECTED] on 1/28/2002 > >> >> > > >> >> > >> >> > >> > > >> > >> > >> > >> > >> ------------------------------------------------------------- > >> Reginald R. Richardson > >> [EMAIL PROTECTED] on 1/29/2002 > >> > > > > > > > ------------------------------------------------------------- > Reginald R. Richardson > [EMAIL PROTECTED] on 2/1/2002 > -- Jack Coates Monkeynoodle: A Scientific Venture... _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
