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 _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
