Hi there, I currently have a multi-ISP config and it''s working great. Host is a CentOS5.4 machine. Shorewall 4.4.19.1 I''ve been asked to add a new ISP which has a 1GB download limit during certain hours. When the cap is hit my users want to switch traffic to another, shared ISP. I was planning on just issuing some iptables commands to tag the traffic for ISP#1 during the on time and ISP#2 during the off time, the same way an entry in tcrules would. The question is really how does connection tracking enter this mix and how can it be avoided? Can I turn off connection tracking where the source is 192.168.0.0/24 and the destination is !RFC1918 but still have tracking where the source is 192.168.0.0/24 and the destination is RFC1918? Presumably I''d have to add an entry in the notrack file for each ISP interface like. Assuming ISP1 on eth1.9 and ISP2 on eth1.5: eth1.7:192.168.0.0/24 eth1.9:!(10.0.0.0/8,192.168 ... etc...) eth1.7:192.168.0.0/24 eth1.5:!(10.0.0.0/8,192.168 ... etc...) Any suggestions are most welcome, Lee Brown ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
On Nov 29, 2011, at 7:32 PM, Lee Brown wrote:> I currently have a multi-ISP config and it''s working great. Host is a CentOS5.4 machine. Shorewall 4.4.19.1 > > I''ve been asked to add a new ISP which has a 1GB download limit during certain hours. When the cap is hit my users want to switch traffic to another, shared ISP. > > I was planning on just issuing some iptables commands to tag the traffic for ISP#1 during the on time and ISP#2 during the off time, the same way an entry in tcrules would. > > The question is really how does connection tracking enter this mix and how can it be avoided?What exactly is your concern with connection tracking? Can''t you simply disable the interface to ISP#1 when the limit is reached? -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
On Wed, Nov 30, 2011 at 10:47 AM, Tom Eastep <teastep@shorewall.net> wrote:> > On Nov 29, 2011, at 7:32 PM, Lee Brown wrote: > > I currently have a multi-ISP config and it''s working great. Host is a > CentOS5.4 machine. Shorewall 4.4.19.1 > > I''ve been asked to add a new ISP which has a 1GB download limit during > certain hours. When the cap is hit my users want to switch traffic to > another, shared ISP. > > I was planning on just issuing some iptables commands to tag the traffic > for ISP#1 during the on time and ISP#2 during the off time, the same way an > entry in tcrules would. > > The question is really how does connection tracking enter this mix and how > can it be avoided? > > > What exactly is your concern with connection tracking? Can''t you simply > disable the interface to ISP#1 when the limit is reached? >The problem I find with that is once I bring the interface back up, traffic continues to ISP#2 when it should switch back to ISP#1. I don''t really know, but I suspect connection tracking is causing that to happen. One thing I am unclear on is if a packet that arrives as part of a connection still goes through the same routing as the original packet, or if that is short-circuited having been already established by the first packet. Or, does a connection simply skip all the rules (unless in the ESTABLISHED section) There are 3 subnets on the same VLAN interface, if that''s relevant. Bringing eth1.9:0 down leaves it in the UP state, but removes the IP address from it. 19: eth1.9@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb link/ether 00:12:3f:25:39:e9 brd ff:ff:ff:ff:ff:ff inet 10.3.11.64/24 brd 10.3.11.255 scope global eth1.9 inet 10.3.10.254/24 brd 10.3.10.255 scope global eth1.9:1 inet 24.52.191.244/29 brd 24.52.191.247 scope global eth1.9:0> > -Tom > > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
On Wed, 2011-11-30 at 12:23 -0800, Lee Brown wrote:> On Wed, Nov 30, 2011 at 10:47 AM, Tom Eastep <teastep@shorewall.net> > wrote:> What exactly is your concern with connection tracking? Can''t you > simply disable the interface to ISP#1 when the limit is reached? > > > The problem I find with that is once I bring the interface back up, > traffic continues to ISP#2 when it should switch back to ISP#1. I > don''t really know, but I suspect connection tracking is causing that > to happen.You do realize that active connections cannot be migrated from one ISP to another, right? When you bring up ISP#1, connections through ISP#2 will continue to use that ISP. The only way to stop them is to disable ISP#2. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
On Wed, Nov 30, 2011 at 5:00 PM, Tom Eastep <teastep@shorewall.net> wrote:> On Wed, 2011-11-30 at 12:23 -0800, Lee Brown wrote: > > On Wed, Nov 30, 2011 at 10:47 AM, Tom Eastep <teastep@shorewall.net> > > wrote: > > > What exactly is your concern with connection tracking? Can''t you > > simply disable the interface to ISP#1 when the limit is reached? > > > > > > The problem I find with that is once I bring the interface back up, > > traffic continues to ISP#2 when it should switch back to ISP#1. I > > don''t really know, but I suspect connection tracking is causing that > > to happen. > > You do realize that active connections cannot be migrated from one ISP > to another, right? >Yes, I break layer 4 on the clients I believe. The outside site has no idea I''m the same entity suddenly coming from a different IP address. It''s an acceptable "issue" vs. the cost of going over our quota.> When you bring up ISP#1, connections through ISP#2 will continue to use > that ISP. The only way to stop them is to disable ISP#2. >I have discovered how to get around that problem and have a script to manipulate iptables to switch from ISP#1 to ISP#2 1) Turn off route caching on startup (echo -1 > /proc/sys/net/ipv4/route/rt_cache_rebuild_count) 2) For TCP, inserting a rule that sends a tcp-reset to either end of the connection brings it down (both LAN and WAN sides). For UDP, icmp unreachable appears to work nicely. ISP#1 is local, masqueraded and 1 of 3 IP address on a NIC (3 different accounts). Hence I can''t just bring the NIC down. ISP#2 is forwarded to another router 100mi away within my network so no masquerading takes place that way. Switching from ISP#1 to #2 works perfectly and of course streaming breaks, but otherwise it''s surprisingly transparent (if you can ignore the halving of speed) Switching from ISP#2 to #1 occasionally skips the masquerade step somehow and ends up creating a connection that sends traffic out to ISP#1 with a non-routable address. I need to find where I can put the rules in place to reject any traffic that is not valid (ie outbound traffic on eth1.9 should have the source address matching one of 3 addresses, otherwise reject it.) Hopefully I can figure that out quite soon.> -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d