Home page logo
/

basics logo Security Basics mailing list archives

Re: [OT] IP Address scheme for branch office
From: Jared Curtis <jared () w00ttech com>
Date: Thu, 12 Nov 2009 13:24:29 -0800

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
------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault