Re: [OT] IP Address scheme for branch office

[Jared Curtis <jared () w00ttech com>]

How many remote offices are we talking about?  If burning IP address
is not a problem then assign each office a /16 subnet.  A simple
method that will allow each site to have a common ip scheme is to
follow 10.<site code>.<vlan_id>.0/24.  For example:

Office 1
site code: 15
subnet:  10.15.0.0/16
Mangement Network (vlan 100): 10.15.100.0/24
PC Network (vlan 5): 10.15.5.0/24
Server Network (vlan 64): 10.15.64.0/24

Office 2
site code: 29
subnet:  10.29.0.0/16
Mangement Network (vlan 100): 10.29.100.0/24
PC Network (vlan 5): 10.29.5.0/24
Server Network (vlan 64): 10.29.64.0/24

An advantage of this is you've effectively given each office more IP's
then they will ever need, and standardized your scheme for help desk
personnel.  A single route for each office is all that is needed and
offices are easily identified by a site code.  It will also be trivial
to template your switch configs to work with this setup, as each site
will be identical with the exception of site code.  Turning up a new
site would be as simple as a find replace operation.  Having plenty of
IP addresses is nice, as an example you could segment PCs into
different VLANs depending on the access that PC should have and then
create ACL rules on your switch to permit traffic based on source IP
to specific devices.  If your environment is more fluid and users
share PCs an 802.1x solution could also be implemented to dynamically
assign VLANs based on credentials.

The disadvantage to this is the number of remote offices is limited to
255, which may or may not fit your current or future needs.

If you're using a routing protocol internally then it maybe worth the
effort to talk to your MPLS carrier about enabling dynamic routing.

On Wed, Nov 11, 2009 at 4:12 AM, martin <martiniscool () gmail com> wrote:
> Hi All
>
> this isn't really a security quesiton, more of a network question, but
> I hope somebody can help.  I'm working in an environment where the
> network designe was inherited from people who were here a long long
> time before I started !!  Obviously the network design is dated and
> neets a bit of a re-think
>
> Currently, we have WAN links to all of our branch office.  The WAN
> links are MPLS links which are managed by a 3rd party.  Currently we
> have 10 24-bit subnets assigned to each office.  eg,
> 192.168.0.0/24-192.168.9.0/24 is assigned to office 1,
> 192.168.10.0-192.168.19.0/24 is assigned to office 2 etc.  Each one of
> the 10 subnets is for a specific purpose, eg subnet 5 is for desktops
> (in the second example it would be subnet 15 etc), 9 is for guests etc
> etc.
>
> Additionally, now we'd like to segment the network further in each
> branch and create a separate segment for servers etc.  The problem
> with the design above, is that there's no easy way to route all the
> subnets for a particular office using just one route.  Additionally,
> each time we need to setup a new subnet at a branch office, we have to
> get the MPLS provider to add a new route for that subnet.  I know we
> could set up the routes for all 10 offices in advance, but for reasons
> too difficult to explain here, we don't want to go down that route !!
>
> The easiest way (that I can see) of re-designing the network to
> minimize the routes is to give each office 8 24-bit subnets instead of
> 10.  Then we can cover each office with one route using a /21 route on
> the MPLS routers.  The problem with this, is that each office will no
> longer have a "5" subnet - the first office will have 192.168.0.0/24 -
> 192.168.7.0/24, the second office will have
> 192.168.8.0/24-192.168.15.0/24 but the 3rd will have 192.168.16.0-23
> ... so there's no 5 subnet !!
>
> The reason we like to keep certain subnets for different usage is to
> make it easier for our helpdesk staff to remember.
>
> I'd appreciate any suggestions anybody has on how to make this eaiser,
> or how you do this in your own environment
>
> Thanks in advance
> M
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, 
> how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, 
> purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for 
> set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital 
> certificates.
>
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------