An IPsec compliant device is required to perform rudimentary firewalling functionality. This consists of checking a selector during IPSec input processing to see whether the packet should be permitted or denied, or whether it should have IPSec protection in the form of AH or ESP. This can be used to allow or prohibit access to individual hosts, entire networks, or even to specific forms of traffic. If this type of filtering is all that's needed a separate firewall would be extraneous.

In most cases, though, a firewall can be used to provide further protection such as stateful packet filtering, and protection against well-known attacks like fragmentation overflow attacks and TCP SYN denial of service attacks. For packets that would be passed by IPsec (via a permit selector) it would be nice to have some assurance on the benevolence of these packets before they reach the network. Because of this, firewalls and VPN gateways are often deployed together.

When a firewall and VPN gateway co-exist at a network egress point there are three different ways in which they can interact: in parallel, firewall in front, or VPN gateway in front (Figure 11.1). When a VPN gateway and firewall are co-resident on the same box the distinct functionality still lies in one of these combinations, usually “VPN gateway in front”.

Figure 11.1. VPN and Firewall Interaction.

When the two devices sit in parallel they both represent valid points of egress from the protected network and ingress to the protected network. In this configuration the network connection to the cloud must be configured to route IKE (UDP port 500) and IPsec traffic (protocols 50 and 51) to the VPN gateway and all other traffic to the firewall. Routing inside the protected network is more complicated though. In the protected network the VPN gateway must be a preferred route for traffic which requires IPsec protection and the firewall must be the preferred route for everything else. If both devices speak a routing protocol they can be easily configured to advertise their preferred routes and dynamically establish the necessary routing state in the protected network. If either one does not then routes must be configured manually. Since these routes have critical security implications great care must be used when configuring them. Whether the devices speak a routing protocol or not, there is additional and critically significant (from a security standpoint) configuration necessary. As the protected network grows or changes, extreme care must be taken to ensure that proper routing of traffic is maintained. For this reason a parallel configuration of VPN gateway and firewall is seldom used.

Another configuration is where the two devices are connected in serial with the firewall connected to the protected network and the VPN gateway connected to network cloud. The VPN gateway has policy to protect certain traffic and permit everything else. This obviates the need for specific routing configuration. It also is an easy way to deploy IPsec without having to reconfigure your firewall—something firewall administrators are loath to do. The firewall in this configuration inspects all traffic, even that traffic that was IPsec protected. Naively that may be viewed as a positive but what this means is that there is a point on the network—namely the network between the VPN gateway and the firewall—where critically important packets are left unprotected.

The final option is where the two devices sit in serial with the VPN gateway connected to the protected network and the firewall connected to the network cloud. In this case the firewall is configured to allow IKE (UDP port 500) and IPsec (protocols 50 and 51) to the VPN gateway and only the VPN gateway. The VPN gateway is configured to protect certain traffic and permit the firewall to handle everything else. The drawback of this configuration is that the firewall now cannot inspect the IPsec protected traffic if it has been encrypted and unless the firewall is intelligent enough to recognize AH it will not know how to inspect any IPsec protected traffic. This is not so serious though when one considers that IPSec is already providing a cryptographic form of protection to these packets which is stronger than anything a firewall can do.

There is no one single best way to have a VPN gateway and firewall interact. Each one has its benefits and drawbacks. Depending on the security policy—and paranoia—of the network administrator one may be better than the other. Each deployment scenario will discuss the trust relationship and recommend a relationship between a firewall and the VPN gateway. In no way is this a hard-and-fast rule. Your mileage may vary.

To avoid using IP addresses that have been assigned to a real company, all addresses used in this chapter will be from the private and globally non-routable address space set aside by IANA, the Internet Assigned Numbers Authority. When a gateway is connected to a cloud it is assumed that the IP address that connects it to the cloud is routable in the cloud. Addresses behind the gateway may be private and are not assumed to be routable in the cloud.

Whether addresses behind gateways are routable or not there is no network address translation (NAT) being performed in any of these deployment scenarios. Since tunnel mode encapsulates packets from one protected network to another, these protected networks can use addresses that are not routable in the cloud that connects them. The only requirement is that their own connection to the cloud is routable in the cloud.

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:

policy to protect traffic to office C:

and policy to protect all other traffic to the main office:

While it is not strictly necessary some may wish to have an explicit drop rule at the end:

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:

remote access policy to allow Road Warriors to access the each protected network:

and an explicit permit rule to allow other traffic to be protected by a firewall:

Road warriors would need policy to protect traffic to each of the four protected networks via the main office's gateway:

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:

policy to protect traffic to office B:

policy to protect traffic to office C:

policy for remote access users:

and an explicit permit rule at the end to allow other traffic to be protected by a firewall:

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:

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!

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:

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:

and the new office would require the following policy statement:

In addition, remote access Road Warriors would need to obtain updated policy to obtain access to this new protected network:

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!

In this situation the physical equipment that supports the collaborative work of the Extranet is hosted at a single site. This site could be a member of the collaborative group or it could be third party hosting. Let's assume it is the former because it makes the security implications more interesting.

The company hosting the Extranet is concerned about restricting the Extranet partners to the Extranet only. The actual machines a partner may use to access the Extranet (from where the partner is coming) are not necessarily important, as long as access (to where the partner is going) is restricted. This can be accomplished by opening up the Extranet to the partners' entire networks. Another way could be to establish a trusted Certification Authority to issue certificates only to trusted Extranet partners and then having remote access policy to restrict Extranet access. Either way accomplishes the same thing—from the point of view of the hosting company, it doesn't matter where they're coming from, it matters where they're going!

The security of the equipment that is not part of the multi-party Extranet must also be maintained since these parties are still mutually suspicious. The company hosting this Extranet does not want to give access to its other resources to its Extranet partners. This can be accomplished ensuring that traffic to and from the Extranet is not routed through the corporate network or by using IPsec policy and firewalls to enforce corporate security and ensure that no Extranet partners sneak off to other confidential parts of the company that is hosting the Extranet. Let's assume the latter, again because it makes the security implications more interesting. The Extranet equipment will be on a subnet—the 10.1.89.128/23 network—of hosting party's secure network.

There are also security implications among the other parties of the Extranet that are not hosting the equipment. They want to allow their company to access the equipment used for collaboration but not the other way around. That is, they don't want to give access to their resources to Extranet partners, all they want to do is ensure their own access to the Extranet. This is best accomplished with a stateful inspection firewall which will allow traffic in only if it is part of a stream that initiated the connection out. An especially paranoid partner may wish to be even more protective though, and allow Extranet access only from a few select machines in his network.

Note that these threats are not symmetric. The hosting company wants to allow anyone from a partner's network into the Extranet and only the Extranet. The non-hosting partners want access to the Extranet but still want to prohibit any access to their networks.

Similar to our previous example in which there was a central office and several remote branch offices, here there is a hosting company and several collaborative partners that comprise the Extranet, Figure 11.5. Note that the network being used for the collaborative Extranet is on the company's protected network. In addition, note that Company D (from the 10.4/16 network) wishes to restrict Extranet access from one small subnet on its network (the 10.4.24.113/28 network). This will provide it with added security assurance in addition to its IPSec and firewall policy at the cost of requiring workers who wish to take part in the collaborative work to physically move to the 10.4.24.113/28 subnet.

Figure 11.5. Single Site Extranet.

First let's consider the situation where there is no Extranet Certification Authority and no remote access policies. The hosting company wants to allow traffic that is only for machines used in the collaborative Extranet and exclude everything else. IPsec policy to express this is:

and an explicit permit rule to allow other traffic to be protected by a firewall:

The firewall would need to be able to restrict access to non-Extranet resources in the hosting company's network, in addition to whatever policy it already has. In addition, the network connecting the VPN gateway and the firewall is now unprotected and other techniques—physical security perhaps—will have to be employed to ensure there is no breach of security there.

Policy for the Extranet partners will be similar, each one protecting traffic from their network to the Extranet network inside the host's network going through the host's gateway. Policy for Company B to the Extranet:

policy for Company C to the Extranet:

policy for Company D's small subnet to the Extranet:

and each an explicit permit rule to allow other traffic to be protected by a firewall:

The firewall between each partner's VPN gateway and his protected network must then have stateful packet filtering rules to only allow connections between 10.1.89.128/23 and the local network if they have been initiated from the local network. This will prevent a partner from accessing the Extranet machines and then reversing course and going out of the Extranet and into another partner's protected network.

If there is a Certification Authority, IPsec configuration is easier (but that is more than exceeded by the work required to get a Certification Authority up and running). The CA could even be one already established and in use at the host company. All that is required is that it issue certificates to partners with some identifying information. Let's assume that is the user's email address @ extranet.foo.com.

Remote access policy to limit access only to Extranet partners could be added to the above configuration. This would allow road warriors of the various Extranet partners to acquire access to the Extranet while on the road.

The entire configuration above could even be scrapped in place of remote access rules. Site-to-site rules are not strictly necessary. In this case the VPN gateway of the company hosting the Extranet would then need the following IPSec policy:

and an explicit permit rule to allow other traffic to be protected by a firewall:

Remote access clients of the Extranet partners would then need:

This simplifies configuration quite a bit. The only caveat is that you must ensure that the Certification Authority will only issue certificates with the extranet.foo.com fully-qualified domain name to valid Extranet partners. Control over access to the Extranet is now in the hands of the Certification Authority.

When each site hosts some part of the Extranet—computers, printers, audio-visual equipment, etc.—the security needs of each partner now mirror that of Company A when it hosted the entire Extranet. Each partner now must allow access in to some part of its network and ensure that no one sneeks off.

First, let's consider the case where there is no certification authority. In this situation it is extremely difficult to set-up policies which are not strictly based on IP source and destination addresses. Partners used to have asymmetric policies which allowed access from anywhere in their network but prohibited access to their network. Now they have to allow their partners in. Each partner will have to establish which part of its network will be part of the Extranet and when employees wish to collaborate in the Extranet they will have to physically move onto the local subnetwork which houses the local part of the Extranet (Figure 11.6). This makes for a simple policy configuration—each site has policy to protect Extranet traffic to the other three sites. In fact, this will look very much like the fully-meshed example above. Company A protects Extranet traffic to Companies B, C, and D:

Figure 11.6. Multi-Site Extranet.

and an explicit permit rule to allow other traffic to be protected by a firewall:

Company B protects Extranet traffic to Companies, A, C, and D.

and an explicit permit rule to allow other traffic to be protected by a firewall:

The configuration for Company C and Company D would be straightforward then where policy protects traffic from the local portion of the Extranet to the other three partner's remote portions of the Extranet.

The presence of an Extranet Certification Authority makes things a bit different. Wildcard policy statements are realistic now and it is no longer necessary to force workers onto a certain subnet just to take part in the collaborative Extranet. But the benefit of allowing local employees to not have to physically move to work in the Extranet comes with a cost: it is necessary to treat local employees the same way that a partner's employees are treated. An employee of Company C who is not physically on the local portion of the Extranet will have to authenticate herself to Company C's VPN gateway in the same way an employee of Company D must.

From the point of view of each company's VPN gateway the configuration is now much simpler. There need only be a single wildcarded policy. Company A will have:

and an explicit permit rule to allow other traffic to be protected by a firewall:

Company B will have:

and an explicit permit rule to allow other traffic to be protected by a firewall:

Companies C and D will similarly have a single wildcarded statement protecting its portion of the Extranet and an explicit permit statement.

The configuration of each user who wishes to have access to the Extranet will be a bit more complicated though due to the fact that the Extranet is disparate. Each company's employee who wishes to do collaborative Extranet work will need the following:

Again, notice the similarity to the remote access case of the fully-meshed corporate VPN above. Since all employees are treated equally, an employee of Company D wishing to access the Company D Extranet resources would be treated in the same fashion as an employee of Company A wishing to access the Company D Extranet resources.

As mentioned in previous sections, there are two methods in which an ISP can design an outsourced secure network. The devices (firewalls and gateways) that implement security can be located either at the edge of the ISP's network (PE based) or at the customer edge (CE based). These deployment scenarios are shown in Figure 11.7.

Figure 11.7. CE- and PE-Based Deployment Scenarios.

Both these solutions pose different challenges. In the CE based solution, the ISP is probably carrying only the organization's traffic on the gateway that is sitting at the edge of the organization. Hence, they can give more control to the organization to manage this gateway. However, there is a price associated with this. It requires someone in the organization to be able to configure policies to build secure Intranets and Extranets. However, this undercuts one of the goals of going to an outsourced network in the first place. There may be issues with liabilities as the ISP may have to guarantee a certain level of security.

PE-based solutions has greater emphasis on trust as the ISP may be carrying traffic from multiple companies on the gateway. If the security on the gateway is compromised it has wide ranging implications as it may affect multiple organizations. This may force the ISP to limit the exposure it gives to organizations on setting or changing their policies. For example, the policy change capability may just be limited to changing the algorithms or restrict access to remote users but not allow creation of Intranets or Extranets.

There is no one rule that fits all for the issues discussed above. It is driven by contractual obligations, the requirements imposed by the organization, and the limitations of the ISP.

In this section, we will consider the three different scenarios

Extranets

Deploying an outsourced Extranet where the machines participating in the Extranets are located in the customer's network is simple if the following conditions are met:

• All the machines in each organization participating in the Extranet are in physically separate network.

• The organization has a direct connectivity to the ISP's network and there are no other connections to the Internet, e.g., via a dialup modem.

• Once on a machine that is part of an Extranet, employees cannot initiate connections to other machines in the organization that do not belong to the Extranet.

The Extranets can be implemented in both PE- and CE-based solutions. The main difference between the two solutions is the placement of firewall. In case of PE-based solution, the firewall is placed in the front on the gateway implementing security in the ISP network as shown in Figure 11.8. This solution also requires that all the traffic originating from within the Extranet network is always forwarded to the PE firewall for the firewall to perform stateful filtering. This enables denying access to the machines that do not belong to the Extranet from within the Extranet.

Figure 11.8. PE-Based Security Solution.

In case of a CE-based solution, the firewall is placed in front of the gateway in the customer's environment as shown in Figure 11.9. This firewall performs stateful filtering of packets to deny access to the machines not part of the Extranet.

Figure 11.9. CE-Based Security Solution.

Continuing with our four Extranet partner example, let us consider the case where each partner has put the machines participating in the Extranet in a separate network as shown in Figure 11.10.

Figure 11.10. Outsourced Multi-Site Extranet Solution.

The policy on the gateway IRA is:

protect 10.1.89.128/23 <-- --> 10.2.42.1/24via 172.24.16.2using ESP HMAC-MD5 3DES tunnelestablish AES SHA modp-1536 pre-sharedprotect 10.1.89.128/23 <-- --> 10.3.11.89/28via 172.24.16.3using ESP HMAC-MD5 3DES tunnelestablish AES SHA modp-1536 pre-sharedprotect 10.1.89.128/23 <-- --> 10.4.24.113/28via 172.24.16.4using ESP HMAC-MD5 3DES tunnelestablish AES SHA modp-1536 pre-shared

and an explicit permit rule to allow other traffic to be protected by a firewall:

permit 0.0.0.0 <-- --> 0.0.0.0

The policies for IRB, IRC, and IRD mirror that of IRA.

If CA-based policy is used, then it is possible to allow access from the Extranet into the corporate network as it is possible to identify the person trying to access the corporate network from the Extranet network. In this case, the policy to access the corporate network is based on certificates.

The policy on IRA is as follows:

protect 10.1.89.128/23 <-- --> 0.0.0.0via *@extranet.foo.comusing ESP HMAC-MD5 3DES tunnelestablish AES SHA modp-1536 rsa-sigprotect 10.1/16 <-- --> 0.0.0.0via *@.foo.comusing ESP HMAC-MD5 3DES tunnelestablish AES SHA modp-1536 rsa-sig

The first policy is to access the Extranet network and the second policy is to access the corporate network. However, the configuration for each Road Warrior gets more complicated as they have to have a policy to access the Extranet hosted in each company.

Third Party Extranet

Many of the complications seen in the previous section can be avoided by a third party Extranet solution. This is because the organizations do not have to worry about someone accessing the corporate network from the Extranet network as the Extranets will be in physically separate network. The policy configuration reduces considerably compared with multiple companies hosting the Extranets. The policy does not have to change every time a new company becomes an Extranet partner.

The main issue with this is that data storage and the security is outsourced. This again comes back to the trust issue. Many companies already offer outsourced data storage solutions. Third party Extranets can be considered as the next step. However, certain guidelines have to be followed in deploying the Extranets. The machines in the hosting company's network should participate in only one Extranet or else the data may be compromised.

Let us go back to the four company Extranet example except in this case, the Extranet is hosted by a third party. The deployment of this Extranet is shown in Figure 11.11.

Figure 11.11. Third-Party Extranet

The following rule still applies: The access to the Extranet is asymmetric, i.e., valid machines or users from the participating companies can access the Extranet. However, users cannot access any of the systems by originating traffic in the Extranet. Hence, the firewall that connects to the Extranet cloud should perform stateful filtering of packets.

The policy configuration on the gateway connected to the Extranet is as follows:

protect 10.1/16 <-- --> 10.2/16via 172.24.16.2using ESP HMAC-SHA AES tunnelestablish CAST SHA modp-1536 pre-sharedprotect 10.1/16 <-- --> 10.3/16via 172.24.16.3using ESP HMAC-SHA AES tunnelestablish CAST SHA modp-1536 pre-sharedprotect 10.1/16 <-- --> 10.4/16via 172.24.16.4using ESP HMAC-SHA AES tunnelestablish CAST SHA modp-1536 pre-shareprotect 10.1/16 <-- --> 10.5/16via 172.24.16.5using ESP HMAC-SHA AES tunnelestablish CAST SHA modp-1536 pre-share

and a policy for the remote access users wanting to access the Extranet:

protect 10.1/16 <-- --> 0.0.0.0via 0.0.0.0using ESP HMAC-SHA AES tunnelestablish CAST SHA modp-1536 rsa-sig

and an explicit rule to drop all other traffic:

drop 0.0.0.0 <-- --> 0.0.0.0

The policy configuration on Company A to access the Extranet is:

protect 10.2/16 <-- --> 10.1/16via 172.24.16.1using ESP HMAC-SHA AES tunnelestablish CAST SHA modp-1536 pre-shared

Companies B, C, and D will have similar policies, except that the source subnets will be their subnets.

The main advantages of the third party Extranets are:

• It is more scalable compared to each site hosting the Extranet. The policy of each user accessing the Extranet does not need any modifications when another company joins the Extranet partnership.

• In terms of scalability, this solution has the same advantages as that of a single company hosting the Extranet. However, the outsourced solution has the potential to provide better infrastructure than what a company can provide, particularly if the Extranet needs to be built for relatively short period of time. The time for deployment can be considerably reduced this case.

There are numerous issues that have to be addressed in outsourcing secure networks. Security is a very sensitive issue. The reason one would want to secure a network is to stop others from snooping or modifying the packets. The fact that there is a dependence on a third party to provide the security may make some people nervous. However, this should not be a deterring factor in outsourcing most of the secure networks. These issues can be resolved by proper contractual obligations between the ISPs and the organization outsourcing the networks and the ISPs taking proper measures to provide the level of security required by the organizations.