[c-nsp] 2 locations, 2 ISPs, 2 ASAs, configuration confusion

Shakeel Ahmad shakeelahmad at gmail.com
Thu Jan 18 14:54:59 EST 2007 

This is but complex...but i would suggest removing ASA/PIX sort of devices
from core routing like i would go for this design:

ISP1 --- RTR1            --------------   RTR2
(ASA1 --- CORE1)                       (ASA2 --- CORE2)

Gig should go between RTR's and ASA should sit in between RTR and CORE on
both sides

a simple iBGP session over Gig and a backup connection via GRE Tunnel (or
using loopbacks via OSPF) would work great and would keep the routing away
from the killer devices like ASA/PIX - atleast i am in no favour of using
PIX in between or routing (may be my bad experience or so) -

regards,
Shakeel


On 1/18/07, Winders, Timothy A <twinders at southplainscollege.edu> wrote:
>
> Thanks, Lee.
>
> I forwarded my initial message to this list to my SE.  I'm waiting for a
> respnose from him.  I also have a meeting scheduled with him next week,
> so we might be able to discuss and address it then.
>
> Usually TAC is very good, but on this case, I don't think they really
> "got it".  I never understood why it couldn't be made to work.  It could
> be that I never explained the situation correctly and made it more
> complicated than need to be at first.
>
> I was hoping to get this finished up this weekend, but, if there are no
> further replies from the list, I'll wait for my SE.
>
> Tim Winders | Associate Dean of Information Technology | South Plains
> College
>
>
>
> > -----Original Message-----
> > From: lee.e.rian at census.gov [mailto:lee.e.rian at census.gov]
> > Sent: Thursday, January 18, 2007 8:17 AM
> > To: Winders, Timothy A
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] 2 locations, 2 ISPs, 2 ASAs,
> > configuration confusion
> >
> >
> > "Winders, Timothy A" <twinders at southplainscollege.edu> wrote
> > on 01/18/2007
> > 08:25:43 AM:
> >
> > > Correct.  No NAT.
> > >
> > > But I don't understand how NAT would make the situation
> > work and give me
> > > surviveability if one of the Internet connections went down.
> >
> > NAT won't fix that problem - you'd have to have to do
> > something like BGP
> > between your internal and external routers to handle an ISP
> > link (or ASA,
> > router, etc.) going down.
> >
> > NAT just ensures that replies to all the traffic that goes
> > out a firewall
> > comes back to the same firewall.  If you're not using NAT,
> > traffic could go
> > out ASA1 and the reply could come back to ASA2.  Where it,
> > hopefully, would
> > be dropped.
> >
> > > If asymmetric routing and stateful firewalls won't work
> > toegether, what
> > > is the purpose of the "asr-group" command?
> >
> > Got me.  I don't know ASAs - but if TAC says it won't work
> > then it most
> > probably won't.
> >
> > If you had a case open for this problem, why not re-open it
> > and ask them to
> > explain exactly why it won't work?  if TAC can't get
> > something working for
> > you they should at least be able to explain _why_ it won't
> > work.  Or try
> > asking your SE... ours are a lot better than TAC.
> >
> > Regards,
> > Lee
> >
> >
> > > > -----Original Message-----
> > > > From: lee.e.rian at census.gov [mailto:lee.e.rian at census.gov]
> > > > Sent: Thursday, January 18, 2007 6:29 AM
> > > > To: Winders, Timothy A
> > > > Cc: cisco-nsp at puck.nether.net
> > > > Subject: Re: [c-nsp] 2 locations, 2 ISPs, 2 ASAs,
> > > > configuration confusion
> > > >
> > > > Since you didn't mention NAT I'm guessing that you're not
> > > > NATing outbound
> > > > traffic.  If so, TAC is right and it won't work.
> > > >
> > > > Asymmetric routing and stateful firewalls won't work
> > together.  If the
> > > > firewalls do NAT it seems like you should be able to make it work.
> > > >
> > > >
> > > > > My next configuration attempt will be as follows.
> > > >
> > > > I can't help you there :-(
> > > >
> > > > Regards,
> > > > Lee
> > > >
> > > >
> > > > "Winders, Timothy A" <twinders at southplainscollege.edu> wrote
> > > > on 01/18/2007
> > > > 02:25:54 AM:
> > > >
> > > > > Hello -
> > > > >
> > > > > I have a multi-city network with two exit points to the
> > > > internet.  For
> > > > > simplicity, this is what the physical network looks like:
> > > > >
> > > > > ISP1 --- RTR1 --- ASA1 --- CORE1 --- CORE2 --- ASA2 ---
> > > > RTR2 --- ISP2
> > > > >
> > > > > CORE1 and CORE2 are in different cities.  They are
> > > > connected via GigE
> > > > > with full VLAN trunking.  I've been chasing my tail for
> > > > months trying to
> > > > > get a stable configuration working.  Everytime I think I
> > > > have something
> > > > > working, it breaks in some other way.
> > > > >
> > > > > Here are the goals:
> > > > >
> > > > > 2 entry and exit points to the network
> > > > > Full firewall at both entry points to the network
> > > > > dynamic routing internal
> > > > > bgp to ISPs
> > > > > if the connection between CORE1 and CORE2 goes down, each
> > > > site maintains
> > > > > internet connectivity independantly and announces
> > routes to it's bgp
> > > > > peer for only the networks which remain local to it.
> > > > > optionally, if CORE1 and CORE2 lose their connection, a
> > > > secure tunnel
> > > > > connection will be established over the internet to connect
> > > > the sites
> > > > > again, transparent to users.
> > > > > All routers (edge and core) are SUP720 based.
> > > > > Firewalls are ASA5520s with ASA-SSM-20 IPS module
> > > > > asymetric routing must be taken into consideration
> > > > >
> > > > >
> > > > > After many failed attempts and several different cases with
> > > > Cisco TAC, I
> > > > > am seeking guidance from the list.  TAC tells me this can't
> > > > be done, but
> > > > > I don't believe it.  Many organizations have global
> > networks with
> > > > > multiple ISP connections which must be secured and also maintain
> > > > > internal network links.  So, my rather simple network
> > > > should be doable.
> > > > >
> > > > > My next configuration attempt will be as follows.  Please
> > > > let me know
> > > > > what problems you see or suggestions/changes you have.
> > > > >
> > > > > RTR1 and ISP1 run eBGP
> > > > > RTR2 and ISP2 run eBGP
> > > > > RTR1 and RTR2 run iBGP
> > > > > internal network routing is OSPF.  Inject OSPF into BGP and
> > > > announce to
> > > > > BGP peers.
> > > > > ASAs run in ACTIVE/ACTIVE multiple context failover.  (Must be
> > > > > ACTIVE/ACTIVE because each firewall must pass traffic
> > > > simultaneously,
> > > > > right?)  ACTIVE/ACTIVE only supports multiple contexts.
> > > > > Firewall transparent mode.  (In routed mode, multiple
> > contexts don't
> > > > > support dynamic routing protocols, but must be transparent
> > > > so RTRx and
> > > > > COREx can speak OSPF.)
> > > > > Single admin context with inside/outside interface
> > configurations
> > > > > asr-group on the outside interface
> > > > > failover link configured on 3rd ASA interface on
> > dedicated VLAN for
> > > > > failover and stateful failover
> > > > >
> > > > > I think this will work.  But, there are some things still
> > > > bothering me.
> > > > >
> > > > > In ACTIVE/ACTIVE mode, are all contexts passing traffic, or
> > > > does it work
> > > > > like ACTIVE/STANDBY where one context is active on one
> > ASA and in
> > > > > standby on the other?
> > > > >
> > > > > In failover configuration, is the complete configuration of
> > > > the context
> > > > > shared between the two ASAs?  What about the system
> > configuration?
> > > > >
> > > > > In Transparent mode, there is a note in the configuration
> > > > guide which
> > > > > says "The transparent firewall requires a managment IP
> > > > address... ...The
> > > > > management IP address must be on the same subnet as the
> > connected
> > > > > network."  OK, that's fine, except, in multiple context
> > mode, the IP
> > > > > address for management goes in the context
> > configuration.  If the
> > > > > context configuration is shared, how can I have an IP
> > address in the
> > > > > same subnet as the connected network when the two
> > connected networks
> > > > > between ASA1 and ASA2 will be different?  One
> > > > possibility...  if RTR1 is
> > > > > directly connected to ASA1 which is directly connected
> > to CORE1 (and
> > > > > same for side 2), then, put the inside RTRx and ouside
> > > > COREx interfaces
> > > > > in a single VLAN.  In that case, the logical network might
> > > > look like the
> > > > > asr-group example in the configuration guide:
> > > > >
> > > > http://www.cisco.com/en/US/products/ps6120/products_configurat
> > > > ion_guide_
> > > > > chapter09186a008045247e.html#wp1102712
> > > > >
> > > > > The problem here is this example has context A and B and I
> > > > can't tell if
> > > > > it's routed or transparent.  This is also where I get my
> > > > confusion about
> > > > > contexts being active and standby in an active/active
> > > > configuration (my
> > > > > first question above).  From that section of the guide:
> > > > "The traffic is
> > > > > forwarded though the outside interface of context A on the
> > > > unit where
> > > > > context A is in the standby state and returns through
> > the outside
> > > > > interface of context A on the unit where context A is
> > in the active
> > > > > state."  So, you see, this talks about an ACTIVE/ACTIVE
> > > > configuration
> > > > > where one context is standby.  Hmmmm.
> > > > >
> > > > > Finally, in an active/active transparent configuration,
> > > > should the ASA
> > > > > have DIRECT connections to the routers on it's inside
> > and outside
> > > > > interfaces?  Or, could the router and asa connect to a
> > switch in the
> > > > > middle and the packets just "know where to go"?  I'm
> > > > thinking here...
> > > > > the ASAx outside interface and RTRx inside interface
> > could be on the
> > > > > same non-routed VLAN.  Then, the ASAx inside interface and
> > > > COREx outside
> > > > > interface could be on a different non-routed VLAN.  I'm not
> > > > sure if this
> > > > > would work.  Then, if I did have the configuration where
> > > > all that was on
> > > > > a single IP subnet, it's possible packets could end up
> > > > coming in ISP1 to
> > > > > RTR1 to ASA2 back to CORE1 destined for servers hanging off
> > > > of CORE1.
> > > > > If the routing were setup right, this *SHOULDN'T* happen,
> > > > but, it could
> > > > > easily be the case if I weren't careful.
> > > > >
> > > > > So, you see how my head goes spinning round-and-round.
> > > > After working on
> > > > > this for months, I'm ready to get it working right and move on.
> > > > >
> > > > > Thanks for your help.
> > > > >
> > > > >
> > > > >
> > > > > Tim Winders | Associate Dean of Information Technology |
> > > > South Plains
> > > > > College
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> > > >
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

More information about the cisco-nsp mailing list