Have a firewall with 2 isps, openvpn, ipsec and ospf in use. The ospf is primarily for the openvpn tunnels. I''m phasing out ipsec because of traffic shaping issues. Been rereading http://www.shorewall.net/MultiISP.html and realize I probably have a couple things not right. in Table 200 are a few hacks to fix a couple problems. ip route list table 200 192.168.1.0/24 via 172.17.2.2 dev tun1 # iax routing mentioned next. 192.168.11.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets via ipsec use local net ip instead of isp1 192.168.10.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets via ipsec use local net ip instead of isp1 The primary thing that is getting my attention is iax traffic will not pass from 192.168.3.1 to 192.168.1.15 All icmp ssh etc works OK. Really strange. The rule "192.168.1.0/24 via 172.17.2.2 dev tun1" makes it work but besides not being correct I want to add redundant openvpn tunnels and the static route must go. This is shorewall version 4.2.1. I recently changed from 4.0 to fix some traffic shaping issues and it did not have this problem. Is there any way to test if packets are marked? My guess is that some how these packets are being marked and going to table ISP2. Any suggestions? My guess is I should change shorewall.conf to USE_DEFAULT_RT=Yes and providers ISP1 1 256 - eth1 $gw1 track,balance=1 ISP2 2 512 - eth2 $gw2 track,balance=2 Should I put in optional? John -- John McMonagle IT Manager Advocap Inc. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
On Fri, 2009-01-09 at 10:32 -0600, John McMonagle wrote:> Have a firewall with 2 isps, openvpn, ipsec and ospf in use. > The ospf is primarily for the openvpn tunnels. > I''m phasing out ipsec because of traffic shaping issues. > > Been rereading http://www.shorewall.net/MultiISP.html and realize I > probably have a couple things not right. > > in Table 200 are a few hacks to fix a couple problems. > ip route list table 200 > # iax routing mentioned next. > 192.168.11.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets > via ipsec use local net ip instead of isp1 > 192.168.10.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets > via ipsec use local net ip instead of isp1 >Example 2 on the MultiIsp page shows that the routes would be in the main table and "rouing rules" are used to force the lookup to use the main table. You have a route to both 192.168.10.x 192.168.11.x using eth1 in the main table but no via gateway and no ipaddress assigned to eth1 in those ranges. Those routes are then being copied to that provider''s table. Shouldn''t those routes be in the main table or is there something with zebra that I''m missing?> The primary thing that is getting my attention is iax traffic will not > pass from 192.168.3.1 to 192.168.1.15Yea, the traffic from 192.168.3.1 would have a route in the main table while the route to 192.168.1.0/24 via 172.17.2.2 is in table 200> All icmp ssh etc works OK. Really strange. > The rule "192.168.1.0/24 via 172.17.2.2 dev tun1" makes it work but > besides not being correct I want to add redundant openvpn tunnels and > the static route must go. >That is not a routing rule, it a static route, try "ip rule ls" is see a routing rule.> This is shorewall version 4.2.1. I recently changed from 4.0 to fix some > traffic shaping issues and it did not have this problem. > > Is there any way to test if packets are marked?"shorewall show mangle" but I don''t see you using the tcrules file, so I''m unsure of what you mean by "marked"> My guess is that some how these packets are being marked and going to > table ISP2. >I''ll guess that the packets are being dropped as there is no route for the traffic.> Any suggestions? >Move the static routes to the main table from table 200 replacing these: 192.168.11.0/24 dev eth1 scope link 192.168.10.0/24 dev eth1 scope link Use the route_rules to have the lookup point to the main table - 192.168.1.0/24 main 1000 - 192.168.1.0/24 main 1000 - 192.168.1.0/24 main 1000> My guess is I should change shorewall.conf to USE_DEFAULT_RT=Yes > > and providers > ISP1 1 256 - eth1 $gw1 > track,balance=1 > ISP2 2 512 - eth2 $gw2 > track,balance=2 >Shouldn''t have too, you have both ISPs on different nics. Jerry ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
Jerry Vonau wrote:> On Fri, 2009-01-09 at 10:32 -0600, John McMonagle wrote:>> My guess is I should change shorewall.conf to USE_DEFAULT_RT=Yes >> >> and providers >> ISP1 1 256 - eth1 $gw1 >> track,balance=1 >> ISP2 2 512 - eth2 $gw2 >> track,balance=2 >> > Shouldn''t have too, you have both ISPs on different nics.USE_DEFAULT_RT=Yes is independent of whether the ISPs are on one NIC or two. And it solves the problems with VPN routes not being copied into the provider tables. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
Jerry Vonau wrote:> On Fri, 2009-01-09 at 10:32 -0600, John McMonagle wrote: > >> Have a firewall with 2 isps, openvpn, ipsec and ospf in use. >> The ospf is primarily for the openvpn tunnels. >> I''m phasing out ipsec because of traffic shaping issues. >> >> Been rereading http://www.shorewall.net/MultiISP.html and realize I >> probably have a couple things not right. >> >> in Table 200 are a few hacks to fix a couple problems. >> ip route list table 200 >> # iax routing mentioned next. >> 192.168.11.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets >> via ipsec use local net ip instead of isp1 >> 192.168.10.0/24 via 192.168.2.254 dev eth0 # Makes outgoing packets >> via ipsec use local net ip instead of isp1 >> >> > Example 2 on the MultiIsp page shows that the routes would be in the > main table and "rouing rules" are used to force the lookup to use the > main table. > > You have a route to both 192.168.10.x 192.168.11.x using eth1 in the > main table but no via gateway and no ipaddress assigned to eth1 in those > ranges. Those routes are then being copied to that provider''s table. > > Shouldn''t those routes be in the main table or is there something with > zebra that I''m missing? > >I only mentioned what was in table 200 because it is a bit odd. Was trying to explain them so we could get to the problem. Guess I messed that up :-) My question are not about net 192.168.11.0/24 and 192.168.10.0/24 routing. These are both via ipsec without ospf ( static ) and being phased out. It fixes an odd ipsec routing problem that is supposedly "impossible" to fix :-) Without this rule: Traffic from 192.168.2.0/23 routes fine. Traffic from firewall will have source ip of 69.129.223.178 not 192.168.2.254 and traffic can not return via the same ipsec tunnel. So the real point is to force the source ip for locally originating traffic. I suppose it could be in the main table.>> The primary thing that is getting my attention is iax traffic will not >> pass from 192.168.3.1 to 192.168.1.15 >> > > Yea, the traffic from 192.168.3.1 would have a route in the main table > while the route to 192.168.1.0/24 via 172.17.2.2 is in table 200 >Table 200 gets checked first # ip rule 0: from all lookup local 200: from all lookup 200 10000: from all fwmark 0x100 lookup ISP1 10001: from all fwmark 0x200 lookup ISP2 20000: from 69.129.223.178 lookup ISP1 20001: from 69.129.223.179 lookup ISP1 20002: from 69.129.223.180 lookup ISP1 20003: from 69.129.223.181 lookup ISP1 20256: from 24.196.120.30 lookup ISP2 32766: from all lookup main 32767: from all lookup default Wanted to give dump but people need to make calls so I needed to include it. Without that static route phone calls stop, people are angry. Removing that route is my primary immediate goal.> >> All icmp ssh etc works OK. Really strange. >> The rule "192.168.1.0/24 via 172.17.2.2 dev tun1" makes it work but >> besides not being correct I want to add redundant openvpn tunnels and >> the static route must go. >> >> > That is not a routing rule, it a static route, try "ip rule ls" is see a > routing rule. >Sorry meant route :-(> >> This is shorewall version 4.2.1. I recently changed from 4.0 to fix some >> traffic shaping issues and it did not have this problem. >> >> Is there any way to test if packets are marked? >> > > "shorewall show mangle" but I don''t see you using the tcrules file, so > I''m unsure of what you mean by "marked" > >That gives the rules. I would like to see what packets are marked. apparently tcp dump can not test marks. About all I can think of it to put in a log entry in rules. Hope I''m getting this right.. If I understand correctly how the packets get routed back to the correct isp is as they come back from the local network the connection tracking tables are checked for what isp they belong to. They are marked uniquely for each isp. ip rules are set up for each mark and sent to the appropriate routing rules. As I recall really only need for dnat. Or do the 2000x routing rule do that directly? I remember setting this up myself a long time ago. I sort of recall having to mark packets for dnat to work. A lot easier to have Tom keep track of the fine points :-) Did a little looking in connection tracking: show connections | grep 192.168.1.15 udp 17 33 src=192.168.2.12 dst=192.168.1.15 sport=47824 dport=161 packets=12 bytes=2520 src=192.168.1.15 dst=192.168.2.12 sport=161 dport=47824 packets=12 bytes=3747 [ASSURED] mark=0 secmark=0 use=1 udp 17 179 src=192.168.1.15 dst=192.168.3.1 sport=4569 dport=4569 packets=88918 bytes=17416041 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=1063 packets=71166 bytes=15442677 [ASSURED] mark=0 secmark=0 use=1 udp 17 138 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=4569 packets=468312 bytes=81679406 src=192.168.1.15 dst=24.196.120.30 sport=4569 dport=4569 packets=428620 bytes=76092029 [ASSURED] mark=512 secmark=0 use=1 On the last line the second dst dst=24.196.120.30 should be dst=192.168.1.15 That is what keeps the routing messed up. The question is what caused it to nat out isp2 in the first place. Or just go to USE_DEFAULT_RT=Yes? If I''m reading correcly ospf and USE_DEFAULT_RT=No is going to break at some point??>> My guess is that some how these packets are being marked and going to >> table ISP2. >> >> > I''ll guess that the packets are being dropped as there is no route for > the traffic. >They try to nat via isp2 most of the time. Most interoffice traffic is going via isp1 the odds are real high it will go via isp2> Jerry > > >Any how thanks for the try. Sorry if I my descriptions are poor. I''m not best writer :-( John -- John McMonagle IT Manager Advocap Inc. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
On Fri, 2009-01-09 at 14:37 -0600, John McMonagle wrote:> Jerry Vonau wrote: > > On Fri, 2009-01-09 at 10:32 -0600, John McMonagle wrote: > >> > Example 2 on the MultiIsp page shows that the routes would be in the > > main table and "rouing rules" are used to force the lookup to use the > > main table. > > > > You have a route to both 192.168.10.x 192.168.11.x using eth1 in the > > main table but no via gateway and no ipaddress assigned to eth1 in those > > ranges. Those routes are then being copied to that provider''s table. > >Sorry, just didn''t quite look right to me, and that is not the source of your issue.> > Shouldn''t those routes be in the main table or is there something with > > zebra that I''m missing? > > > > > I only mentioned what was in table 200 because it is a bit odd. > Was trying to explain them so we could get to the problem. > Guess I messed that up :-)Not really, I would of asked what was up with table 200 anyway, 192.168.1.0/24 via 172.17.2.2 dev tun1 is your main issue.> My question are not about net 192.168.11.0/24 and 192.168.10.0/24 routing. > These are both via ipsec without ospf ( static ) and being phased out. > It fixes an odd ipsec routing problem that is supposedly "impossible" > to fix :-) > Without this rule: > Traffic from 192.168.2.0/23 routes fine. > Traffic from firewall will have source ip of 69.129.223.178 not > 192.168.2.254 and traffic can not return via the same ipsec tunnel.That is the above route in table 200, right?> So the real point is to force the source ip for locally originating > traffic. > I suppose it could be in the main table. >I try to use the KISS (Keep It Simple Stupid) method, I''d leave it in the main table.> >> The primary thing that is getting my attention is iax traffic will not > >> pass from 192.168.3.1 to 192.168.1.15 > >> > > > > Yea, the traffic from 192.168.3.1 would have a route in the main table > > while the route to 192.168.1.0/24 via 172.17.2.2 is in table 200 > > > Table 200 gets checked first > > # ip rule > 0: from all lookup local > 200: from all lookup 200 > 10000: from all fwmark 0x100 lookup ISP1 > 10001: from all fwmark 0x200 lookup ISP2 > 20000: from 69.129.223.178 lookup ISP1 > 20001: from 69.129.223.179 lookup ISP1 > 20002: from 69.129.223.180 lookup ISP1 > 20003: from 69.129.223.181 lookup ISP1 > 20256: from 24.196.120.30 lookup ISP2 > 32766: from all lookup main > 32767: from all lookup default >Yes, it does, but table 200 doesn''t have a route to handle 192.168.3.1, so the traffic doesn''t get to use the gateway, as there is no route in that table.> Wanted to give dump but people need to make calls so I needed to include it. > Without that static route phone calls stop, people are angry. > Removing that route is my primary immediate goal. > > > >> All icmp ssh etc works OK. Really strange. > >> The rule "192.168.1.0/24 via 172.17.2.2 dev tun1" makes it work but > >> besides not being correct I want to add redundant openvpn tunnels and > >> the static route must go. > >> > >> > > That is not a routing rule, it a static route, try "ip rule ls" is see a > > routing rule. > > > > Sorry meant route :-(No problem,> > > >> This is shorewall version 4.2.1. I recently changed from 4.0 to fix some > >> traffic shaping issues and it did not have this problem. > >> > >> Is there any way to test if packets are marked? > >> > > > > "shorewall show mangle" but I don''t see you using the tcrules file, so > > I''m unsure of what you mean by "marked" > > > > > That gives the rules. > I would like to see what packets are marked. > apparently tcp dump can not test marks. > About all I can think of it to put in a log entry in rules. >That might be helpful.> Hope I''m getting this right.. > If I understand correctly how the packets get routed back to the > correct isp is as they come back from the local network the connection > tracking tables are checked for what isp they belong to. They are > marked uniquely for each isp. > ip rules are set up for each mark and sent to the appropriate routing rules.s/b ip rules are set up for each mark and sent to the appropriate routing table> As I recall really only need for dnat. > Or do the 2000x routing rule do that directly?> I remember setting this up myself a long time ago. > I sort of recall having to mark packets for dnat to work. > A lot easier to have Tom keep track of the fine points :-) >1000x ip rules handle the inbound for dnat, and entries in tcrules. 2000x ip rules handle the outbound from the firewall> Did a little looking in connection tracking: > show connections | grep 192.168.1.15 > udp 17 33 src=192.168.2.12 dst=192.168.1.15 sport=47824 dport=161 > packets=12 bytes=2520 src=192.168.1.15 dst=192.168.2.12 sport=161 > dport=47824 packets=12 bytes=3747 [ASSURED] mark=0 secmark=0 use=1 > udp 17 179 src=192.168.1.15 dst=192.168.3.1 sport=4569 dport=4569 > packets=88918 bytes=17416041 src=192.168.3.1 dst=192.168.1.15 sport=4569 > dport=1063 packets=71166 bytes=15442677 [ASSURED] mark=0 secmark=0 use=1 > udp 17 138 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=4569 > packets=468312 bytes=81679406 src=192.168.1.15 dst=24.196.120.30 > sport=4569 dport=4569 packets=428620 bytes=76092029 [ASSURED] mark=512 > secmark=0 use=1 > > On the last line the second dst dst=24.196.120.30 should be > dst=192.168.1.15 > > That is what keeps the routing messed up. The question is what caused it > to nat out isp2 in the first place. >Yea, traffic from 192.168.3.1 got marked, because there is no route to the remote subnet. OK there is, but traffic can''t use it, there is no route in table 200 for 192.168.2.0/23> Or just go to USE_DEFAULT_RT=Yes? > If I''m reading correcly ospf and USE_DEFAULT_RT=No is going to break at > some point?? >If ospf plays with the default gateways, yes things break, even if you use USE_DEFAULT_RT=Yes> > >> My guess is that some how these packets are being marked and going to > >> table ISP2. > >> > >> > > I''ll guess that the packets are being dropped as there is no route for > > the traffic. > > > They try to nat via isp2 most of the time. > Most interoffice traffic is going via isp1 the odds are real high it > will go via isp2 > > > > Jerry > > > > > > > Any how thanks for the try. > Sorry if I my descriptions are poor. > I''m not best writer :-(Me either, I wasn''t clear on what to do with the static route for tun1. I''d try to add a route to table 200 for the 192.168.2.0/23 subnet, or move that static route to the main table and add a route_rule for the traffic as in my prior email. Hope it helps, Jerry ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
Jerry Vonau wrote:> >> My question are not about net 192.168.11.0/24 and 192.168.10.0/24 routing. >> These are both via ipsec without ospf ( static ) and being phased out. >> It fixes an odd ipsec routing problem that is supposedly "impossible" >> to fix :-) >> Without this rule: >> Traffic from 192.168.2.0/23 routes fine. >> Traffic from firewall will have source ip of 69.129.223.178 not >> 192.168.2.254 and traffic can not return via the same ipsec tunnel. >> > > That is the above route in table 200, right? > >ipsec stuff is 2 of the 3 routes in table 200> >>>> The primary thing that is getting my attention is iax traffic will not >>>> pass from 192.168.3.1 to 192.168.1.15 >>>> >>>> >>> Yea, the traffic from 192.168.3.1 would have a route in the main table >>> while the route to 192.168.1.0/24 via 172.17.2.2 is in table 200 >>> >>> >> Table 200 gets checked first >> >> # ip rule >> 0: from all lookup local >> 200: from all lookup 200 >> 10000: from all fwmark 0x100 lookup ISP1 >> 10001: from all fwmark 0x200 lookup ISP2 >> 20000: from 69.129.223.178 lookup ISP1 >> 20001: from 69.129.223.179 lookup ISP1 >> 20002: from 69.129.223.180 lookup ISP1 >> 20003: from 69.129.223.181 lookup ISP1 >> 20256: from 24.196.120.30 lookup ISP2 >> 32766: from all lookup main >> 32767: from all lookup default >> >> > > Yes, it does, but table 200 doesn''t have a route to handle 192.168.3.1, > so the traffic doesn''t get to use the gateway, as there is no route in > that table. >Another odd one. you may not have noticed the the local network is 192.168.2.0/23 that includes 192.168.3.1. I needed more room and expanded the subnet. I would really like to break down the subnet sizes wanted to avoid putting a lot of static routes everywhere. After I get ospf working everywhere I''ll probably start splitting up that network.> >> Did a little looking in connection tracking: >> show connections | grep 192.168.1.15 >> udp 17 33 src=192.168.2.12 dst=192.168.1.15 sport=47824 dport=161 >> packets=12 bytes=2520 src=192.168.1.15 dst=192.168.2.12 sport=161 >> dport=47824 packets=12 bytes=3747 [ASSURED] mark=0 secmark=0 use=1 >> udp 17 179 src=192.168.1.15 dst=192.168.3.1 sport=4569 dport=4569 >> packets=88918 bytes=17416041 src=192.168.3.1 dst=192.168.1.15 sport=4569 >> dport=1063 packets=71166 bytes=15442677 [ASSURED] mark=0 secmark=0 use=1 >> udp 17 138 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=4569 >> packets=468312 bytes=81679406 src=192.168.1.15 dst=24.196.120.30 >> sport=4569 dport=4569 packets=428620 bytes=76092029 [ASSURED] mark=512 >> secmark=0 use=1 >> >> On the last line the second dst dst=24.196.120.30 should be >> dst=192.168.1.15 >> >> That is what keeps the routing messed up. The question is what caused it >> to nat out isp2 in the first place. >> >> > Yea, traffic from 192.168.3.1 got marked, because there is no route to > the remote subnet. OK there is, but traffic can''t use it, there is no > route in table 200 for 192.168.2.0/23 > >Again isn''t 192.168.3.1 in 192.168.2.0/23 And back to the real point 192.168.1.0/24 via 172.17.2.2 dev tun1 proto zebra metric 70 in table main should have done it. Did aging with ssh running from 192.168.3.1 > 192.168.1.15 root@fonroute:/etc/shorewall# shorewall show connections | grep 192.168.1.15 tcp 6 431961 ESTABLISHED src=192.168.3.1 dst=192.168.1.15 sport=52177 dport=22 packets=21 bytes=2928 src=192.168.1.15 dst=192.168.3.1 sport=22 dport=52177 packets=20 bytes=3508 [ASSURED] mark=0 secmark=0 use=1 udp 17 172 src=192.168.3.1 dst=192.168.1.15 sport=4569 dport=4569 packets=469256 bytes=81717166 src=192.168.1.15 dst=24.196.120.30 sport=4569 dport=4569 packets=429092 bytes=76110909 [ASSURED] mark=512 secmark=0 use=1 I took some lines out. ssh wants to go the correct way.>> Or just go to USE_DEFAULT_RT=Yes? >> If I''m reading correcly ospf and USE_DEFAULT_RT=No is going to break at >> some point?? >> >> > If ospf plays with the default gateways, yes things break, even if you > use USE_DEFAULT_RT=Yes > >ospf doesn''t touch the default route or local interface 192.168.2.0/23 I''ll try USE_DEFAULT_RT=Yes this weekend and see what happens. Thanks for the input. John -- John McMonagle IT Manager Advocap Inc. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
The USE_DEFAULT_RT=Yes seems to fix my problems it :-) A few less serious issues to deal with. When I restarted shorewall still had a default route left in main. something like default via 69.129.223.177 dev eth1 I removed it. I think it is because I have both default routes defined in /etc/network/interfaces. It was always there before but caused no harm as it was after the correct default route. I have not rebooted yet but suspect it will come back. Should I remove one of the gateways out of interfaces? Really should have asked this first but in http://www.shorewall.net/MultiISP.html has For most routing applications, Quagga <http://www.quagga.net/> is a better solution. I''m already running quagga and if it can be done I''m interested. I have a t1 (TDS) and a cable modem ( Charter ) , Particularly with the cable modem wouldn''t think I would have sufficient a access to a routing protocol with the isp. Is it possible to be able to use quagga for this? When a isp is down need to temporarily disable it. I have done a could different methods. I have commented out providers and made scripts to change the default route. Is there a shorewall way to do it? John Thanks John John McMonagle wrote:> ospf doesn''t touch the default route or local interface 192.168.2.0/23 > I''ll try USE_DEFAULT_RT=Yes this weekend and see what happens. > > > Thanks for the input. > > > John > >-- John McMonagle IT Manager Advocap Inc. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
John McMonagle wrote:> The USE_DEFAULT_RT=Yes seems to fix my problems it :-) > > A few less serious issues to deal with. > > When I restarted shorewall still had a default route left in main. > something like > default via 69.129.223.177 dev eth1 > I removed it. > > I think it is because I have both default routes defined in > /etc/network/interfaces. > It was always there before but caused no harm as it was after the > correct default route. > > I have not rebooted yet but suspect it will come back. > Should I remove one of the gateways out of interfaces?>From http://www.shorewall.net/MultiISP.html#USE_DEFAULT_RT:6. You should disable all default route management outside of Shorewall. If a default route is inadvertently added to the main table while Shorewall is started, then all policy routing will stop working except for those routing rules in the priority range 1-998.> > Really should have asked this first but in > http://www.shorewall.net/MultiISP.html has > For most routing applications, Quagga <http://www.quagga.net/> is a > better solution. > > I''m already running quagga and if it can be done I''m interested. > I have a t1 (TDS) and a cable modem ( Charter ) , Particularly with > the cable modem wouldn''t think I would have sufficient a access to a > routing protocol with the isp. > Is it possible to be able to use quagga for this?That statement in the manual is simply reiterating the principle that you get what you pay for. Using Quagga with two commercial-grade uplinks with routing protocols available is clearly superior to the hack that Shorewall provides.> > When a isp is down need to temporarily disable it. > I have done a could different methods. > I have commented out providers and made scripts to change the default route. > Is there a shorewall way to do it?Make both interfaces ''optional'' and simply ''shorewall restart''. In later versions of Shorewall, you use the ''optional'' option in /etc/shorewall/interfaces and you can do ''shorewall -f restart'' which doesn''t even run the compiler. If the link appears up even though it is unusable, you may need to provide an ''isuable'' script to suppliment Shorewall''s ''interface_is_usable'' test. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword