Four Office Company Example
Let us now consider a small company, NetWidgit, with four offices, a main office and three remote branch offices (Figure 11.2). Communication between these offices is confidential and needs to be protected. Wisely, NetWidgit has decided to employ IPsec to protect this communication but that brings up some deployment options and issues.
Figure 11.2. Simple Four Office Configuration.
Each remote office has a connection to the Internet through which IPsec-protected packets are routed but access to the Internet need not be granted at the remote branch offices. Each of our deployment scenarios for NetWidgit will deal with cases where the remote offices are and are not permitted to have Internet access. When a device has Internet access it must deal with co-existance with a firewall (see above).
In this example of the Four Office Company, each office (remote and main) represents part of the same company. The trust relationship between all nodes in the VPN is assumed to be extensive (employees have physical access to confidential information) and not suspicious (one node does not trust another any more or less than the rest). Because of this trust relationship, the firewall and VPN gateway will be in a serial configuration with the firewall connected to the Internet and the VPN gateway connected to the protected network. This maximizes the security at the cost of minimal firewall configuration without opening up the protected network to an attack that does not already exist (namely a disgruntled employee on the protected network wrecking havoc).
Fully-Meshed Configuration
In a fully-meshed configuration there are peer-wise relationships between each office and the other three offices. For the small NetWidgit network there would be six separate peer-wise connections for the four offices. As the number of peers grows the number of peer-wise connections grows faster. For instance, if NetWidget had five offices there would be ten peer-wise connections. If there were ten offices there would be forty-five peer-wise connections (see Figure 11.3)! Once we step through the (relatively) simple fully-meshed configuration for NetWidgit it should be straightforward to imagine how to implement fully-meshed configurations for much larger networks.
Figure 11.3. Fully Meshed Configuration.
First, let's consider a simple case where access to the global Internet access is permitted only from the main office of NetWidgit, and that all peer-wise connections will use the same IPsec and IKE policy suites to protect the traffic and that all traffic between the sites will be protected no need to restrict it to a specific upper-layer protocol.
Each remote site will be configured in a similar manner: policy to protect traffic from its own protected network to each of the other three protected networks will be via the gateway for that protected network and policy for everything else will be via the gateway at the main office. Office A will have policy to protect traffic to office B:
protect 10.2/16 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy to protect traffic to office C:
protect 10.2/16 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
and policy to protect all other traffic to the main office:
protect 10.2/16 <-- --> 0.0.0.0
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
While it is not strictly necessary some may wish to have an explicit drop rule at the end:
drop 0.0.0.0 <-- --> 0.0.0.0
The other remote offices will have similar configurations with office B having policy to office A, office C and the main office; and office C having policy to office A, office B and the main office. The main office, though, will be different. It has policy to protect traffic to each of the three remote offices:
protect 0.0.0.0 <-- --> 10.2/16
via 172.24.16.2
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
protect 0.0.0.0 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
protect 0.0.0.0 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
remote access policy to allow Road Warriors to access the each protected network:
protect 10.1/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 10.2/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 10.3/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 10.4/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
and an explicit permit rule to allow other traffic to be protected by a firewall:
permit 0.0.0.0 <-- --> 0.0.0.0
Road warriors would need policy to protect traffic to each of the four protected networks via the main office's gateway:
protect 0.0.0.0 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.2/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.3/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.4/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
Now let's consider the case where each of the remote branch offices, in addition to the main office, are permitted to have access to the global Internet. This will also allow the remote access policies for each protected network to go directly to that protected network.
There is now no difference between the remote branch office policy and the main office policy. Each gateway defines protection from its protected network to the three other protected networks and defines remote access policy for its protected network. Office A will have policy to protect traffic to the main office:
protect 10.2/16 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy to protect traffic to office B:
protect 10.2/16 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy to protect traffic to office C:
protect 10.2/16 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
policy for remote access users:
protect 10.2/16 <-- --> 0.0.0.0
via 0.0.0.0
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
and an explicit permit rule at the end to allow other traffic to be protected by a firewall:
permit 0.0.0.0 <-- --> 0.0.0.0
The other remote offices and the main office would all have similar policy protecting traffic from their local protected network to each other's protected network and an explicit permit rule at the end.
Since each protected network is permitted to access the Internet directly, Road Warriors would have gateway-specific policy and no longer need to go through the main office to access remote office networks:
protect 0.0.0.0 <-- --> 10.1/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.2/16
via 172.24.16.2
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.3/16
via 172.24.16.3
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
protect 0.0.0.0 <-- --> 10.4/16
via 172.24.16.4
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
Fully meshed deployments are nice because there are no extra hops for a packet to go through to get from one protected network to another. Each protected network has a peering relationship with each other protected network. On the downside they are complicated to set-up and they don't scale well. To add a new node to an N-node fully meshed VPN requires N separate policy statements on the new node and one new policy statement on the N other nodes. When N grows large, that's a lot of configuration!
Hub-And-Spoke Configuration
A way to minimize configuration of large VPNs is to utilize a hub-and-spoke configuration. In this configuration each "spoke" has a peer-wise configuration with the "hub" but not with all other "spokes". This makes growth of the VPN more manageable as the size of the VPN grows because adding a new node to an N-node hub-and-spoke VPN requires a policy statement on the new "spoke" (to connect it to the "hub") and a policy statement on the hub (to connect it to the new "spoke"). The downside is that traffic between "spokes" must be routed through the "hub". That means double the encapsulation and double the cryptographic operations to protect the traffic. Network throughput will, most likely, be affected.
A hub-and-spoke deployment at NetWidgit will entail a simple and essentially identical configuration on the three remote branch offices (the "spokes") and a more complicated configuration on the main office (the "hub"), see Figure 11.4.
Figure 11.4. Hub-and-Spoke Network.
This topology lends itself nicely to the simple configuration namely, that the only Internet access is via the main office. This way all the remote offices merely specify that all traffic is sent to the main office. For example, office A specifies traffic from its protected network is sent to the main office:
protect 10.2/16 <-- --> 0.0.0.0
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
Each remote office would be similarly configured. Office B would specify traffic from its protected network, 10.3/16, etc.
The main office would then have policy statements to protect traffic to all the remote office's networks and remote access policies to allow Road Warriors to access those networks via the main office. In fact, the hub-and-spoke configuration on the main office's gateway (and the Road Warrior's remote access policy) is identical to that of the fully-meshed configuration when the only Internet access was via the main office (see above). The difference between the two is with protected traffic between remote offices, in the fully-meshed case it was sent directly, in the hub-and-spoke case it must go through the hub.
Now, to add a new remote office all that needs to happen is to update the main office gateway's policy to include a statement to the new office. Retaining our convention, let's assume the new network is 10.5/16 and the gateway is 172.24.16.5. The new policy added to the main office gateway would therefore be:
protect 0.0.0.0 <-- --> 10.5/16
via 172.24.16.5
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
and the new office would require the following policy statement:
protect 10.5/16 <-- --> 0.0.0.0
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 pre-shared
In addition, remote access Road Warriors would need to obtain updated policy to obtain access to this new protected network:
protect 0.0.0.0 <-- -->10.5/16
via 172.24.16.1
using ESP HMAC-SHA AES tunnel
establish CAST SHA modp-1536 rsa-sig
But no configuration of the other remote offices offices A-C is needed. When the number of remote offices is large it is easy to see the benefit to using a hub-and-spoke set-up instead of a fully-meshed set-up.
If we wish to allow each remote office to access the Internet directly but retain our hub-and-spoke configuration for ease of growth each remote office would need policy for each protected network, including the new one, via the main office gateway and an explicit permit policy statement to pass non-VPN traffic to a firewall. It should not be hard to see what is happening. We have just lost the benefit of the hub-and-spoke configuration addition of a new office now requires all other offices to be reconfigured!
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |