Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Joe Thompson <jt@techforless.com>
To: netfilter@lists.netfilter.org
Subject: Re: Fairly complex multi-ISP firewall/router problem
Date: 02 Apr 2004 15:07:59 -0700	[thread overview]
Message-ID: <1080943679.3421.4.camel@4100.internal.techforless.com> (raw)
In-Reply-To: <200404022250.54788.Antony@Soft-Solutions.co.uk>

What is the architecture between the rest of the world and your
firewall?  Is it possible to use BGP and only one of the public
subnets?  This would in effect move the redundancy of the public side to
the router(s) allowing you to use standard method's at the firewall.

We run a similar situation with one of our subnets, we have two circuits
from separate provider's who were both gracious enough to add the routes
in they're tables, if we lose one connection the rest of the world just
uses the other route in and we of course use the other route out.  The
downside is getting both upstream providers to cooperate in routing, the
upside is that you can utilize both links and keep things simple from an
addressing perspective.

Joe

On Fri, 2004-04-02 at 14:50, Antony Stone wrote:
> On Friday 02 April 2004 10:36 pm, John A. Sullivan III wrote:
> 
> > On Fri, 2004-04-02 at 15:57, Bill Davidsen wrote:
> > >
> > > All I want to do is send packets out the interface which matches the
> > > source IP, and I don't think there's any reasonable way to get there
> > > without patches or BSD.
> >
> > Hmmm . . . I admit to not having tried this and only giving it five
> > minute's thought but I'm not sure I see the problem.  Well, I see why
> > one can't be guaranteed to send the packet out the same interface but
> > I'm not sure why that is a problem.
> 
> Some ISPs block packets with source addresses not matching their own network 
> range, as a contribution to blocking spoofed packets.
> 
> > In the case of an interface or ISP failure, I assume you would disable
> > the interface which would eliminate the route.
> 
> That's not necessarily a difficult task (bringing it back up again afterwards 
> is not entirely trivial, however), but if the problem can be solved without 
> sending all outbound traffic across a single connection, and leaving the 
> other one largely idle, it would be a better solution.
> 
> Regards,
> 
> Antony.



  reply	other threads:[~2004-04-02 22:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-02 20:57 Fairly complex multi-ISP firewall/router problem Bill Davidsen
2004-04-02 21:06 ` Antony Stone
2004-04-03  3:24   ` Bill Davidsen
2004-04-02 21:32 ` Cedric Blancher
2004-04-02 21:36 ` John A. Sullivan III
2004-04-02 21:50   ` Antony Stone
2004-04-02 22:07     ` Joe Thompson [this message]
2004-04-03  3:17       ` Bill Davidsen
2004-04-13  9:29 ` Tarek W.
  -- strict thread matches above, loose matches on Subject: below --
2004-04-02 23:45 Daniel Chemko
2004-04-03  3:31 ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1080943679.3421.4.camel@4100.internal.techforless.com \
    --to=jt@techforless.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox