I
Sent from my BlackBerry device on the Rogers Wireless Network
-----Original Message-----
From: shorewall-users-request@lists.sourceforge.net
Date: Thu, 21 Apr 2011 15:16:19
To: <shorewall-users@lists.sourceforge.net>
Reply-To: shorewall-users@lists.sourceforge.net
Subject: Shorewall-users Digest, Vol 59, Issue 21
Send Shorewall-users mailing list submissions to
shorewall-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/shorewall-users
or, via email, send a message with subject or body ''help'' to
shorewall-users-request@lists.sourceforge.net
You can reach the person managing the list at
shorewall-users-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Shorewall-users digest..."
Today''s Topics:
1. Re: Turning providers on/off (Tom Eastep)
2. Re: Cannot connect to the internet] (Tom Eastep)
3. Re: Turning providers on/off (Lee Brown)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Apr 2011 15:33:31 -0700
From: Tom Eastep <teastep@shorewall.net>
Subject: Re: [Shorewall-users] Turning providers on/off
To: Shorewall Users <shorewall-users@lists.sourceforge.net>
Message-ID: <28D03A3E-9A1E-4ECE-98D2-795D05D1640B@shorewall.net>
Content-Type: text/plain; charset="us-ascii"
On Apr 20, 2011, at 11:25 AM, Lee Brown wrote:
> Hi,
>
> I have a multi-ISP situation (working well) whereby I need to turn off one
of my ISP''s once a cap has been reached.
> I can turn it off quite easily by replacing the default route in the main
table:
> default
> nexthop via 10.1.5.3 dev eth1.5 weight 1
> nexthop via XX.XXX.XX.33 dev eth1.9 weight 1
>
> with
> default via 10.1.5.3 dev eth1.5
>
> But if I try to reverse the process and replace the default route with the
1st one, packets routed via the eth1.9 provider goes into a black hole (not
investigated where packets end up)
It''s not the outgoing packets that are the issue, I''m betting,
but rather that incoming packets suddenly become martians (you can confirm that
by looking at your kernel log). Turn off routefilter on both of your interfaces
and it should work better. Note, however, that if the ISP through which eth1.5
connects is doing egress filtering, then that ISP will drop traffic whose source
is XX.XXX.XX.33.
>
> Doing a shorewall restart takes several minutes, so I''d like to
avoid that if possible, but it always puts things the way they should be.
You must be using an ancient version of Shorewall with the shell-based rules
compiler. If you upgrade to the current version, I''m betting that
restart will be fast (and it will be seamless).
>
> I''m thinking the direction I should be going in is either:
> 1. To insert/delete an iptables rule to mark the packets for the always-on
ISP when the variable ISP has expired (per the FAQ)
> 2. Generate 2 sets of rules for iptables using shorewall (one with
multi-path default route, one with single path) and swap one for the other.
I would try the routefilter thing first.
-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 \________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: This is a digitally signed message part
------------------------------
Message: 2
Date: Wed, 20 Apr 2011 16:49:03 -0700
From: Tom Eastep <teastep@shorewall.net>
Subject: Re: [Shorewall-users] Cannot connect to the internet]
To: horacef@usnetizen.com
Cc: shorewall-users@lists.sourceforge.net
Message-ID: <4DAF70EF.70202@shorewall.net>
Content-Type: text/plain; charset="utf-8"
On 4/20/11 2:05 PM, Horace Franklin Jr wrote:
> I think these are the protocols I want to allow access to and from my
> computer:
> a. http
> b. https
> c. ftp
> d. smtp
> e. pop3
> f etc.
>
Surely, you aren''t running servers are you? If not, don''t do
anything.
You are fine the way you are and someone with your limited understanding
shouldn''t try to restrict traffic any more than it already is.
-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 \________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
------------------------------
Message: 3
Date: Thu, 21 Apr 2011 08:16:12 -0700
From: Lee Brown <leeb@ratnaling.org>
Subject: Re: [Shorewall-users] Turning providers on/off
To: Shorewall Users <shorewall-users@lists.sourceforge.net>
Message-ID: <BANLkTi=wq5VjpFTRSW+ovROm1GSCp8OmLw@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I have a multi-ISP situation (working well) whereby I need to turn off one
> of my ISP''s once a cap has been reached.
> I can turn it off quite easily by replacing the default route in the main
> table:
>
> default
> nexthop via 10.1.5.3 dev eth1.5 weight 1
> nexthop via XX.XXX.XX.33 dev eth1.9 weight 1
>
>
> with
>
> default via 10.1.5.3 dev eth1.5
>
> But if I try to reverse the process and replace the default route with the
> 1st one, packets routed via the eth1.9 provider goes into a black hole (not
> investigated where packets end up)
>
>
> It''s not the outgoing packets that are the issue, I''m
betting, but rather
> that incoming packets suddenly become martians (you can confirm that by
> looking at your kernel log). Turn off routefilter on both of your
interfaces
> and it should work better. Note, however, that if the ISP through which
> eth1.5 connects is doing egress filtering, then that ISP will drop traffic
> whose source is XX.XXX.XX.33.
>
Yes you are right about the martians, I was looking in the wrong logfile for
them, but right when I made that switched to multipath I see about half a
dozen.
I believe I have route filtering turned off, however *one entry* seems odd:
ROUTE_FILTER=No in shorewall.conf;
nothing in the shorewall interfaces file
/proc/sys/net/ipv4/conf/eth*/rp_filter are all zero
/proc/sys/net/ipv4/conf/default/rp_filter is zero
* /proc/sys/net/ipv4/conf/all/rp_filter is 1*
*
*
I don''t how, yet, to check that the kernel anti-spoofing mechanism is
turned
off (I seem to remember that in the docs somewhere.)
Doing a shorewall restart takes several minutes, so I''d like to avoid
that> if possible, but it always puts things the way they should be.
>
>
> You must be using an ancient version of Shorewall with the shell-based
> rules compiler. If you upgrade to the current version, I''m betting
that
> restart will be fast (and it will be seamless).
>
Sorry, yes it used to take minutes, now it only takes 26 seconds to perform
a restart (I bounce a few services at the end, such as named, dhcpd and ntpd
as they only attach to interfaces that exist when they startup, that
probably adds about 8 seconds)
>
>
> I''m thinking the direction I should be going in is either:
> 1. To insert/delete an iptables rule to mark the packets for the always-on
> ISP when the variable ISP has expired (per the FAQ)
> 2. Generate 2 sets of rules for iptables using shorewall (one with
> multi-path default route, one with single path) and swap one for the other.
>
>
> I would try the routefilter thing first.
>
Well my boss changed the requirements such that I no longer need to balance
anything. Pity, it was getting fun too with 3 ISPs, balancing 2 of those
(one NAT''d the other not) with about 12 specific subnets, with 2 other
subnets requiring the unbalanced ISP.
Thanks BTW for such a great tool. I don''t think I would have ever
tackled
iptables and ip without having the insulation of Shorewall first. Not only
did it enable me to take over from our IT firm very quickly a few years
back, but by careful examination of the rules it does generate, it''s
easier
to see the relationships between the various tables and chains and how that
compares to the lartc.org/netfilter documentation.
Lee
> -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 \________________________________________________
>
>
>
>
>
------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
------------------------------
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
End of Shorewall-users Digest, Vol 59, Issue 21
***********************************************
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev