On Wed, Nov 30, 2011 at 5:00 PM, Tom Eastep <[email protected]> wrote:
> On Wed, 2011-11-30 at 12:23 -0800, Lee Brown wrote:
> > On Wed, Nov 30, 2011 at 10:47 AM, Tom Eastep <[email protected]>
> > 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
> [email protected]
> 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
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
