It appears Roger's network has fully redundant, multiple paths from and to each sites - one path via private WAN, another by VPN over the public internet (the company must be well-budgeted and management IT/technology-friendly :)).
Whereas, Robert's network selectively uses (probably based on circuit availability) private WAN to interconnect some sites and VPN over the public internet to interconnect other sites (actually a very common setup/topology). Alternate method of providing backup/redundant circuit for those critical sites would be to augment your (Robert's) circuit between hub site and remote site(s) (frame? or, T1?) with ISDN and use a command like "backup int bri0" for automatic failover. This way, the ISDN kicks in only if the main circuit goes down and, therefore, you'd normally pay only the monthly service charge. Randall -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Gonzaga (306) Sent: Thursday, December 19, 2002 08:22 AM To: NT 2000 Discussions Subject: RE: Minimum VPN req's Nice. I really only need to do this with only one of our more critical locations. It's a hub and spoke type a setup with the hub router having the PIX as it's default gateway (unfortunately we're not doing vpn there). I haven't done vpn from router-to-router. Should be interesting. Thanks for the info. I think it's something to keep in mind when we become a corporate giant. :) -----Original Message----- From: Roger Seielstad [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 8:09 AM To: NT 2000 Discussions Subject: RE: Minimum VPN req's We're a little different here.. ;) We run BGP for our internal WAN infrastructure, and the core routers in each office have default routes to their respective firewalls. The firewalls have meshed tunnels which are always up, and corresponding static routes for all necessary networks. In a nutshell, what happens is each core router gets distributed routes from its BGP neighbors, and when any of those links die, the learned route drops (usually takes a few minutes maximum), and traffic which was destined for that network then gets routed via the default route for the core router - in other words, the firewall. That firewall has a static route, over the existing tunnel, to the other sites. >From what I've seen in the past, this kind of setup only works when you have a dynamic routing protocol in use - something that's link state aware. We used to do the same with EIGRP, and OSPF would handle it well as well. I guess weighted static routes would work, but man that's a lot of work for more than a few sites. ------------------------------------------------------ Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA > -----Original Message----- > From: Robert Gonzaga (306) [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 10:19 AM > To: NT 2000 Discussions > Subject: RE: Minimum VPN req's > > > > That's interesting. I'm going to try to setup a backup VPN > to our WAN links > as well. The routers have the 3DES feature pack on them as > well as access > to DSL. I also want to use floating static routes on the routers to > determine which link is down. How does it work with yours? > > -----Original Message----- > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 4:28 AM > To: NT 2000 Discussions > Subject: RE: Minimum VPN req's > > They make plenty of sense, depending on your needs. > > We have a similar set up - a VPN concentrator and a separate firewall. > > We have a large number of VPN users (Let's just say we have the 1000 > concurrent user license on the concentrator here) and that > level of user > load on a firewall which also handles enterprise traffic > would be insane. > > We also do failover routing via PIX to PIX VPN to back up our > WAN links, and > there are some different routing requirements to make that > work which would > break the client connects through the VPN. > > Not only that, we're already budgeted for a few more firewalls to > restructure our production DMZ. > > Its also more secure to keep the firewall and the VPN connect point > separate. Keep in mind that you have to authenticate to the > VPN box else no > traffic will pass through it. > > ------------------------------------------------------ > Roger D. Seielstad - MCSE > Sr. Systems Administrator > Inovis - Formerly Harbinger and Extricity > Atlanta, GA > > > > -----Original Message----- > > From: Aaron Brasslett [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 18, 2002 5:12 PM > > To: NT 2000 Discussions > > Subject: RE: Minimum VPN req's > > > > > > Why would you put your VPN box in parallel with the PIX? Why > > wouldn't you > > support the VPN on one of the existing PIXs? Parallel > > firewalls don't make > > a lot of sense. > > > > Aaron > > > > -----Original Message----- > > From: Robert Gonzaga (306) [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 18, 2002 5:03 PM > > To: NT 2000 Discussions > > Subject: RE: Minimum VPN req's > > > > > > I setup our VPN box in parallel with our 2 PIXs. You need a > > public IP for > > the outside and a private IP on the inside. Pop in you PDC > > info, WINS and > > pool of address for that clients and that's basically it. > > It's fast. You > > can use your existing windows client but I'd recommend the > > Cisco software > > that comes with the concentrator. The client is a free > > downloadable from > > cisco if you have a CCO login. > > > > -----Original Message----- > > From: Lum, David [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, December 18, 2002 2:00 PM > > To: NT 2000 Discussions > > Subject: Minimum VPN req's > > > > All this talk of VPN...what's the absolute minimum equipment > > to VPN if both > > sides already have fast internet? Software/hardware. I > > currently dial in via > > PCAnywhere to one site, but I'd love to utilize my DSL and > > their broadband > > connection to connect. > > > > Dave Lum - [EMAIL PROTECTED] > > Sr. Network Specialist - Textron Financial > > 503-675-5510 > > > > > > > > ------ You are subscribed as [EMAIL PROTECTED] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to %%email.unsub%% ------ You are subscribed as [email protected] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED]
