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
