Supporting Internet Access in IP VPNs

Earlier in this chapter, the subject of providing access from the Internet to the corporate VPN was discussed. Similar issues occur when you look at providing access to Internet resources to VPN users, whether they're located at a central or remote site. An additional issue to consider that affects network design is which part of the WAN you want traffic destined for the Internet to traverse. This is best shown in Figure 9-10.

Figure 9-10. Enterprise with a Backbone Linking Spoke Sites in San Francisco, Chicago, and New York

This enterprise has numerous sites located around hub locations in New York, Chicago, and San Francisco. Before being converted to an MPLS VPN WAN, the enterprise had an Internet access point in each of the hubs. By route control mechanisms (that is, manually configuring default routes and not propagating a default route throughout the network), the sites near New York had a 0.0.0.0 route pointing toward the New York hub, the sites near Chicago had a 0.0.0.0 pointing toward the Chicago hub, and the sites near San Francisco had a 0.0.0.0 pointing toward that hub site.

The enterprise chose this option instead of having a single Internet access point in, say, Chicago and backhauling all Internet traffic across its WAN. The enterprise has therefore decided to manage three different Internet access points and keep Internet traffic off the backbone connecting the hubs. When the enterprise now migrates toward an MPLS VPN, some new decisions about this arrangement have to be made. The issues to consider are as follows:

• Does the enterprise maintain its three Internet access points separate from the MPLS VPN service in contracts from its provider?

• With an MPLS VPN, no WAN backbone connects hubs that the enterprise owns and manages. Should the enterprise decommission its own Internet access points and have Internet access provided as part of the MPLS VPN service?

• If the enterprise chooses to use Internet access via the provider-provisioned MPLS VPN, will it also outsource the NAT, firewall, and potentially web cache functions to the provider?

The first decision is whether to keep the existing three Internet access points. Typically, the primary reasons for enterprises electing to use this type of setup are to preserve interhub WAN backbone bandwidth and to provide some resiliency, in that if one access point goes offline, not all users are affected. Both of these reasons are fairly well negated by migration to an MPLS VPN. First, as has been stated, because there are no dedicated interhub backbone links when all sites are connected to an MPLS VPN, there is no reason to try to conserve it! Second, presenting a single default route to the enterprise does not mean that a single Internet access point within the service provider network is used to deliver service. Providers typically have mechanisms to load-balance connections across multiple Internet access gateways. Generally, they can provide better service continuity characteristics to the enterprise user base by providing a single default for Internet access than an enterprise can by statically directing groups of sites to different hub sites.

If the enterprise wants to maintain its own three distinct Internet access points while implementing the MPLS VPN, there is a new problem to consider. As each site of the enterprise exchanges routes with the provider PE VRF for that VPN, and then those routes are propagated to that VPN's VRF for all other PEs that have sites in that VPN, the ability to have sites in the San Francisco region use the San Francisco hub and the Chicago sites use the Chicago hub is lost for a plain-vanilla MPLS VPN implementation. The reason is that the enterprise edge router just sees the provider PE as a single next-hop router. As soon as a packet routed out the enterprise edge router via a default route entry reaches the PE VRF, a single 0.0.0.0 is in the PE VRF for that VPN, and that 0.0.0.0 is the same in the enterprise VRF in all PEs.

A workaround is possible if the CE router at a site connects to the PE via an encapsulation that supports subinterfaces, such as Frame Relay. In this case, the CE router can have one subinterface for the regular MPLS VPN define a 0.0.0.0 route pointing toward a second subinterface that goes to a separate VRF on the PE router. There can be a second VRF that is present only for sites in the San Francisco area, a different VRF that is used on PEs that connect sites in the Chicago area, and a third VRF that exists only on PEs connecting sites in the New York area. Each of these three additional (and regional) VRFs will have routes from the enterprise within it, but each will have a separate destination for the 0.0.0.0 default route in it.

From the enterprise perspective, it appears to be just one VPN, with the exception that the default route for the sites surrounding each regional hub leads to that hub.

As soon as the routing design to get access to the Internet is defined, the question of providing firewall, NAT, and cache services comes into play. Clearly, this is related to the decision of how Internet access is provided as part of the new MPLS VPN-supported WAN. If the option is selected to maintain one or more Internet access points within the corporation, clearly these services will continue to be managed by the enterprise.

However, there are options for the provider to manage and bill for these services. Now, there is the question of security ownership. If an enterprise is concerned enough about its security to demand a firewall, NAT, or something else to conceal and protect its internal infrastructure, does the enterprise get the security desired by handing over management of those services to a third party? The answer generally comes down to the resources available within the enterprise. Typically, larger enterprises have the resources to manage their own security, and they get added peace of mind knowing that no third party has control over it. However, smaller and medium businesses do not have the expertise to keep up to date with security issues. Also, outsourcing security to a provider may be suboptimal, in that complete trust must be placed in the provider. The real level of security delivered is likely to be better.

The issues that the enterprise must understand about the purchase of these security services relate to where NAT is performed. If the provider has a single NAT gateway on its network to access the global Internet, either enterprise customers must have unique address schemes or the PE or CE has to perform NAT to ensure uniqueness by the time packets reach the Internet gateway.

Some providers have chosen to provide a separate Internet gateway for each customer to get around this restriction. The separate gateway per customer can be logical or physical, depending on preference. With multiple logical or physical NAT Internet gateways, all the provider's customers can use the same address space without restriction.

When the provider offers the single shared implementation, it is important for the enterprise to check that no access from one customer's network to another is possible via the default routes existing in the multiple NAT/Internet gateways on the provider network. This can occur by using the single Internet gateway as an interconnect between customer VPNs. To avoid this problem, policy-based routing needs to be implemented on all customer traffic to the gateway. The effect is that all traffic from the VPN toward the Internet gateway can only be forwarded to the Internet, not back toward any VPN on the provider network (something like a split-horizon rule for traffic).

So far, the options discussed for Internet access delivered by the provider have been on the basis of a default route in the VRF pointing toward a central gateway within the provider cloud. Another option is to use the global routing table within the PE router to access an Internet gateway. The PE has multiple customer-specific VRF routing tables. It also has one global routing table that generally contains the provider-specific infrastructure addresses and potentially Internet routes, too. The approach here is to have the default route within the customer-specific VRF point to the public address of the Internet gateway. This static route must be configured by the provider with the global keyword to direct the VRF routing process to inspect the global routing table to find the route information. Likewise, the global routing table needs a route to point back to the enterprise edge router for return traffic. Clearly, the restriction with this method is that the enterprise uses a globally unique address space that can exist in the provider's global routing table.