Re: Routing between spokes - recent best practices?
On Dec 4, 2007, at 12:14 AM, visc wrote: So, my question is this - what are the current best practices for setting up a hub and spoke topology using OpenBSD, allowing for traffic to securely flow from Branch to Branch on occasion without using a full mesh topology. If it's at all possible... (network description below) At this point IMHO branch-to-branch is avoided not for security reasons but for administrative reasons. It is a pain in the ass to configure each branch to establish a VPN to any other branch. It's easy to tell each branch router if you want to talk to BRANCHX, talk to CENTRALOFFICE first. If you have more than a handful of branches it is very annoying to tell each router if you want to talk to BRACHA, talk to A; if you want to talk to BRANCHB, talk to B; etc. The primary advantage of the star or branch-to-central topology was the difficulty of someone putting a man-in-the-middle of a leased line. But now leased lines are expensive. VPNs and direct Internet connections are cheap so it makes much more sense to put in the pain- in-the-ass effort to connect everyone in your Intranet via VPNs/IPSEC and get rid of your leased lines. If you only have enough budget to move a few this year you analyze which few cross-talk the most and configure them for mesh and leave the rest as star. This is not true if you asked an auditor, however. It is much easier to put a network sensor down in a star topology and get most of the network traffic than it is for a mesh network. If you want to be able to buy one device and know for sure that everyone is going through it you probably need a star topology and a heavy hand on the branch routers. -- Freedom, truth, love, beauty. John Rodenbiker
Re: Routing between spokes - recent best practices?
On 12/4/07, John Rodenbiker [EMAIL PROTECTED] wrote: On Dec 4, 2007, at 12:14 AM, visc wrote: So, my question is this - what are the current best practices for setting up a hub and spoke topology using OpenBSD, allowing for traffic to securely flow from Branch to Branch on occasion without using a full mesh topology. If it's at all possible... (network description below) At this point IMHO branch-to-branch is avoided not for security reasons but for administrative reasons. It is a pain in the ass to configure each branch to establish a VPN to any other branch. It's easy to tell each branch router if you want to talk to BRANCHX, talk to CENTRALOFFICE first. GRE/IPIP inside IPsec and dynamic routing. /Tony If you have more than a handful of branches it is very annoying to tell each router if you want to talk to BRACHA, talk to A; if you want to talk to BRANCHB, talk to B; etc. The primary advantage of the star or branch-to-central topology was the difficulty of someone putting a man-in-the-middle of a leased line. But now leased lines are expensive. VPNs and direct Internet connections are cheap so it makes much more sense to put in the pain- in-the-ass effort to connect everyone in your Intranet via VPNs/IPSEC and get rid of your leased lines. If you only have enough budget to move a few this year you analyze which few cross-talk the most and configure them for mesh and leave the rest as star. This is not true if you asked an auditor, however. It is much easier to put a network sensor down in a star topology and get most of the network traffic than it is for a mesh network. If you want to be able to buy one device and know for sure that everyone is going through it you probably need a star topology and a heavy hand on the branch routers. -- Freedom, truth, love, beauty. John Rodenbiker
Re: Routing between spokes - recent best practices?
On 12/4/07, Tony Sarendal [EMAIL PROTECTED] wrote: On 12/4/07, John Rodenbiker [EMAIL PROTECTED] wrote: On Dec 4, 2007, at 12:14 AM, visc wrote: So, my question is this - what are the current best practices for setting up a hub and spoke topology using OpenBSD, allowing for traffic to securely flow from Branch to Branch on occasion without using a full mesh topology. If it's at all possible... (network description below) At this point IMHO branch-to-branch is avoided not for security reasons but for administrative reasons. It is a pain in the ass to configure each branch to establish a VPN to any other branch. It's easy to tell each branch router if you want to talk to BRANCHX, talk to CENTRALOFFICE first. GRE/IPIP inside IPsec and dynamic routing. Or just a management tool to create configs and push it out. /Tony /Again
Routing between spokes - recent best practices?
Hi, apologies if it's been talked about until blue, but I'm all manpage/google/list-searched out on this. Using the old adage of Central Office and Branch Offices looking for secure connectivity: - My old and outdated understanding (last time I was involved in planning a VPN was quite a while back) the only proper way to achieve Branch to Branch communication was using a star or full mesh solution. - It's my understanding that this is no longer the case, with certain strategies like Cisco's DMVPN etc allowing Branch to Branch communication in a Hub and Spoke style VPN. Branch to Branch traffic will be rare for me, but it is necessary. So, my question is this - what are the current best practices for setting up a hub and spoke topology using OpenBSD, allowing for traffic to securely flow from Branch to Branch on occasion without using a full mesh topology. If it's at all possible... (network description below) What am I missing to route from Branch to Branch? Do I need to set aliases on the Central site? Do I need to add gre to the mix? gif? The network will consist (for the sake of discussion anyway) of - OpenBSD 4.2-current devices for all gateways - isakmp automatic keying (so no manual flows, right?) using publickey authentication. A bit of additional security via pf only allowing related traffic from a static list of IPs. Please feel free to tell me know if I should really head down the certificate path. ipsec.conf files are simple, and already functional from Branch - Central, ie: ike esp from a.b.c.d to e.f.g.h ike esp from s.t.u.v/24 to w.x.y.z/24 peer e.f.g.h (This will obviously need changing to reflect the greater class A that all branches share, but that's my next worry...) If I add additional lines to ipsec.conf reflecting the class C subnet of another branch, ipsecctl -sa does show flows, I just can't actually get packets through. pf will set skip on enc0 Thanks for your time. I can send actual pf.conf and ipsec.conf if you like, but I've been changing them around to mess with this so who knows what's current. Cheers, an apologies for the long winded newbie question. visc
