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