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