Pinging from Box1 to WS 192.168.10.3 is no problem, and versa versa. As long as i have the default gateway on on BOX3, then i can ping from WS 192.168.10.3 to the internet.
I think what u mentioned previously is perciasly the problem, box3 gets into a LOOP, for some reason, and just sends all http packets back to box 1 maybe, but what i find strange, is that if on BOX3 i have a default gateway on, then the WS can browse the internet without any problem. thks for the help 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 _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
