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