James Gray wrote: > On Wed, 15 Aug 2007 09:55:06 am Tom Eastep wrote: >> James Gray wrote: >>> Tom Eastep wrote: >>>> James Gray wrote: >>>>> I thought I followed all the docs but I feel like I've missed something >>>>> really basic. >>>> Like maybe Shorewall FAQ 57? >>>> >>>> -Tom >>> Thanks Tom. I really appreciate the fast response :) I've been doing >>> most of the config offline using the 3.x PDF documentation, and it >>> doesn't lay it out as plainly as FAQ 57. My bad. >>> >>> I replaced "loose" with "balance" in the providers options. However, >>> after restarting shorewall (sudo service shorewall restart) the routing >>> totally wigged out. Traffic was going out on the two interfaces >>> (ISP1/2) but if data was coming back, it wasn't reaching the clients. I >>> reverted to the old config and all was good (all traffic on one >>> interface). >> Your tcrules are so completely broken (see my other post) that this >> isn't surprising. >> >> I suggest that you totally forget traffic shaping for the time being and >> get multi-ISP working the way that you want it. Then *and only then* >> should you add traffic shaping. > > Ok. I got the multi-ISP stuff going without any traffic shaping but that's > not particularly useful for us. We must have certain traffic going out over > specific links, otherwise the service will fail (tcpwrappers "paranoid" and > certain services that must originate from one link or the other). But > there's traffic that should be going over specific links over both, and other > traffic bound to an interface that should be on the other :( > > For instance, ALL ssh (tcp/22) traffic should be going out over NET_IF1 > (eth3, > via 172.16.3.1) with mark of 10 or 20. But here's a tcp trace from the LAN: >
That is only for traffic control, that is in the forward chain. The mark of 10 or 20 relates to routing and a provider how?? > $tcptraceroute XX.XX.XX.XX 22 > Selected device eth0, address 10.10.10.74, port 37321 for outgoing packets > Tracing the path to XX.XX.XX.XX on TCP port 22 (ssh), 30 hops max > 1 10.10.10.1 0.727 ms 0.142 ms 0.128 ms > 2 172.16.4.1 0.859 ms 0.656 ms 0.643 ms <--- *** NO! *** > 3 203.38.103.1 11.029 ms 10.983 ms 9.575 ms > 4 TenGigabitEthernet8-1.ken17.Sydney.telstra.net (203.50.20.27) 10.486 ms > 10.770 ms 11.849 ms > 5 ge-2-1-0-25.bdr5.hay.connect.com.au (203.63.130.250) 11.091 ms 10.497 > ms > 12.283 ms > 6 gigabitethernet0-1.cor10.hay.connect.com.au (203.63.217.3) 11.623 ms > 11.821 ms 10.474 ms > 7 * * * > > Hop #2 should be going out via 172.16.3.1. The router it's going through is > actually NET_IF2 (eth4). Consequently, the traffic is dropped because the > destination will only accept connections from the first ISP (NET_IF1). I > thought the config below would achieve the desired result...but apparently > not. > > I've changed the providers OPTIONS for the two ISP's to "track,balance". > Which got things working...apart from this weird traffic/routing behaviour. > Attached is another shorewall dump whilst running with the config below. > > tcrules: > #MARK SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS > # PORT(S) PORT(S) <snip> > 20 $LAN_NETWORK $ANY_IP tcp ssh - - - 513: > 10 $LAN_NETWORK $ANY_IP tcp ssh - - - 0:512 > the routing rules: 0: from all lookup local 10001: from all fwmark 0x1 lookup IINET 10002: from all fwmark 0x2 lookup TELSTRA 10202: from all fwmark 0xca lookup squid 20256: from 172.16.3.2 lookup IINET 20512: from 172.16.4.2 lookup TELSTRA 32766: from all lookup main 32767: from all lookup default When using the tcrules file to override balancing to use only one isp, you should be using the providers' mark here (in the tcpre chain, that is part of the prerouting chain) to direct traffic into the providers' routing table to pick your preferred isp. You'll need to use something like: 1:P $LAN_NETWORK $ANY_IP tcp ssh 1 = mark of your "preferred" provider P = use mark in prerouting chain > > What is left to make this work....it feels close :-/ > > Cheers, > > James > Hope that is your fix.. Jerry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
