Internet Access
This section provides various scenarios for Internet access and points out security considerations for each example. These simple shared Internet access scenarios include the following:
Network address translation [NAT] via multiple common gateways
PE to multiple Internet gateways
NAT via a single common gateway
Registered NAT by CE
Internet access via customer-controlled NAT
Internet access using global routing table
BGP Internet routing table from service provider of an ISP
Tier 3 ISP connecting to an upstream tier via a service provider
NAT Via Common Gateways
The network administrator can set up a shared Internet access structure for customers who require a simple method of connecting without having to provide their own cache engines or firewalls. The target customer is someone who does not have an IT infrastructure. NAT is performed at a common gateway point or points managed by a service provider (see Figure 9-1). Although rare, it may be that the entire customer network uses a registered address space, where no NAT function is required and traffic will pass directly through the NAT phase untouched.
Figure 9-1. Shared Internet Access Multiple NAT Gateways
Performing NAT at a central point has the primary advantage of conserving registered address space because all customers share the same common pool. A default Internet route is imported into every subscribing customer VRF; therefore, any traffic from a customer whose destination is not explicitly known will be routed to the Internet gateway router. Corresponding customer routes are imported into the Internet VRF and the provider edge. The Internet gateway will translate the customer traffic to a registered address from an available pool, and then pass the traffic through the cache engine and firewall to the Internet. (Note that address translation can also occur at the firewall.)
The caveat about this design and any central gateway design is that a single gateway can only translate addresses for customers who do not have overlapping addresses. If there is an instance where customers are using the same address space, then there may be a separate gateway performing the translation for each customer that shares a common address space. Multiple gateways, however, can share access to a common firewall.
In practice, connection to the Internet would either connect back to the PE using the global routing space (not a VRF) to access the service provider egress router, or a direct connection would be made to the service provider egress router. In this example, there is a single VRF shared by all customers who do not have overlapping addresses. Customers who do have overlapping addresses will use separate Internet gateways and a VRF. Portions of the registered address pool could also be used on a per-customer basis using access lists or static translations to permit explicit identification of customer hosts from the Internet, such as mail servers or web hosts.
NOTE
This configuration process would require conduits or holes to be made through the firewall for customer hosts.
PE to Multiple Internet Gateways
The connection between the PE and the Internet gateway could be via Ethernet (Gigabit Ethernet, for example) so hat VLANs can be used. This would allow the support for multiple NAT gateways (to support customers sharing the same address space) via a Cisco Catalyst switch, as shown in Figure 9-2. For example, each would have its own VLAN.
Figure 9-2. Catalyst Switch for Multiple NAT Gateways
NOTE
A third party in the same VLAN (for example, an Internet exchange point [IXP]) can insert spoofed packets into VPNs and perform man-in-the-middle attacks; therefore, we recommend using Inter-AS and CsC connections only in private peering mode. Even though the Internet gateway is part of the service provider's infrastructure in this context, we emphasize the security concern.
VLANs can be assumed to be separate if:
The switch is not a low-end model
Virtual Trunking Protocol (VTP) is disabled on all ports (default)
Router ports are not trunk ports
No Inter-Switch Link (ISL) or 802.1q signaling is configured on the router ports.
An Internet service can be created on an Internet gateway router (see Figure 9-3). Dynamic routing can be used to pick up customer routes as they are imported to the Internet VRF. A default route can be configured to point to the cache engine.
Figure 9-3. Shared Internet Access: Single NAT Gateway
Example 9-1 shows an example of such a configuration.
Example 9-1. Internet Router Gateway Configuration
! !Define the registered address pool to use for all customers using the Internet ip nat pool NAT_Pool1 171.69.233.201 171.69.233.254 netmask 255.255.255.0 ip nat inside source list 1 pool NAT__Pool1 ! !Sub-interface to Internet VRF for customers in the MPLS cloud !Connects to the PE in the Service Provide x network interface fastethernet 1/0.18 ip unnumbered loopback0 ip nat inside ! !LAN subnet to firewall and cache engine interface fastethernet 1/1 ip address 167.26.17.1 255.255.255.0 ip nat outside ! access-list 1 permit any ! !address of cache engine/proxy server ip route 0.0.0.0 0.0.0.0 167.26.17.10 !
Example 9-2 shows an example of a PE connecting to the Internet gateway. (For clarity, the VRF connections for Customer 1 and Customer 2 have been included, but these could most likely be on another PE.) The VPN_Internet VRF contains the default route pointing to the gateway. This was picked up by using dynamic routing between the gateway and the PE and redistributing the static route ip route 0.0.0.0 0.0.0.0 167.26.17.10 in Example 9-1. Each customer VRF will import the Internet route-target 9255:2 and export the route-target 9255:20. Note that the default-information originate command must be added to the BGP VRF definition to force BGP to distribute the default route.
The VPN_Internet VPN will import the route-targets for all subscribing customers using the route-target 9255:20. In this way, the configuration at the PE remains static and all configuration is done at the customer VRF. (Route-maps could also be used to limit the customer routes imported in the VPN_Internet VRF.)
Example 9-2. Internet PE Configuration
! !Define Customer1 VRF ip vrf VPN_Internet rd 9255:2 route-target export 9255:2 route-target import 9255:20 ! !Define Customer1 VRF ip vrf VPN_customer1 rd 9255:10760 route-target export 9255:10650 route-target import 9255:10650 route-target import 9255:2 route-target export 9255:20 ! !Define Customer2 VRF ip vrf VPN_customer2 rd 9255:10750 route-target export 9255:10750 route-target import 9255:10750 route-target import 9255:2 route-target export 9255:20 ! !Link to the Internet Gateway for Internet VRF interface fastethernet 1/1/0.18 ip vrf forwarding VPN_Internet ip unnumbered loopback0 router bgp 9255 address-family ipv4 vrf VPN_Internet default-information originate !
NOTE
It would be possible to access another customer's network via the gateway because of the default routes. To avoid this problem, policy-based routing should be on all customer traffic to the Internet gateway. All ingress traffic should have its next hop interface forced to be that of the interface connecting directly to the other through the gateway. In other words, all traffic passing through the gateway is always sent to the Internet segment.
Example 9-3 shows the configuration on the Internet gateway to force traffic to the Internet.
Example 9-3. Forcing Traffic to the Internet
! !Sub-interface to Internet VRF in the MPLS cloud ! interface fastethernet 1/0.18 ip unnumbered loopback0 ip nat inside ip policy route-map TO_Internet ! interface fastethernet 1/1 Description Cache and Firewall LAN (to Internet) ip address 167.26.17.1 255.255.255.0 route-map TO_Internet permit 20 set interface fastethernet 1/1
NOTE
Given the scenario shown in Figure 9-4, if the target interface goes down, the CE defaults to normal routing that will result in traffic passing into the VPN part of the site and consequently bypassing the security measures. This implementation, therefore, is not recommended for the security risk.
Figure 9-4. Shared Access Line, Policy-Based Routing
NAT via a Single Common Gateway
When deploying a single Internet gateway where all NAT is performed by one device, and there are customers who have overlapping addresses sharing this device, two stages of translation occur. This process is referred to as double NAT.
The first translation occurs at the CE using nonregistered addresses so as not to waste the registered address pool. This translation uniquely identifies customers with overlapping addresses to the gateway, which would then perform the second translation to a registered address for transmission out to the Internet. The motivation behind this scenario is to conserve registered address space.
Registered NAT by CE
The scenario shown in Figure 9-5 is similar to accessing the Internet via a single common gateway, except that the registered NAT is performed at the CE. The firewall and caching functions are still done at a common point. Also, because the customer has its own address range, the common NAT gateway could be completely ignored and the connection could be made directly to the common cache/firewall segment. For example, you could have three customers who have VRFs that only require Internet service. Each customer either already uses registered addresses or performs NAT to registered addresses at the CE. Furthermore, each of these customers may have a customer-owned and maintained WAN behind each of these CE routers where the CE router is viewed as the Internet gateway from the customer's WAN perspective. That is, the default route would point to the CE. The advantage of this scenario is that the customer does not need to manage and maintain firewalls and cache engines.
Figure 9-5. Shared Internet Access: CE-Registered NAT
Internet Access via Customer-Controlled NAT
Larger and more security-sensitive customers may wish to provide their own firewall, NAT, and caching services, but want to use the Internet connection provided by a particular service provider. An example of this scenario, which is shown in Figure 9-6, is the case in a hub and spoke environment, where Internet access from all sites of a company pass through a central point such as a corporate data center for security and monitoring purposes.
Figure 9-6. Internet Access via Customer Hub
Customers may also desire to provide their own Internet services, such as web hosting, e-mail servers, telnet access, and so on, without requiring intervention from a service provider. Specifically a customer?say Customer 1 Hub Site?could provide caching and firewall services to all Customer 1 sites.
The CE router at the hub site, say Site A (customer or service provider managed) will have two interfaces (Ethernet, ATM, PVCs, and so on):
One that connects the customer's hosts in the normal manner
One that connects a cache/firewall segment
The customer site could have two connections from the CE for Internet and intranet traffic, each with its own VRF terminated at the PE.
The default route is injected into the customer Internet VRF at Site A. This default route is then distributed to all VRFs for Customer 1. Note that for this to occur, Multi-Protocol Border Gateway Protocol (MP-BGP) must be configured with the line default-information-originate in the address family section pertaining to that VRF. Intranet routes in the customer network are distributed in the normal manner between VRFs. The result is that all customer sites have full mesh/peer connectivity with one another, and Internet access will always be via Site A using the default route.
The Internet VRF in Site A will contain the address of the service provider Internet gateway imported from the Gateway VRF. The registered addresses used by Customer 1 will be exported to the gateway VRF. The registered addresses could be owned by the customer or provided by the service provider where address translation in this case occurs at Site A's firewall. The CE router will direct all routes for the default to the cache engine/proxy server. The firewall will direct traffic back through the CE router to the customer Internet VRF and eventually to the Internet. Policy-based routing is required for this to occur, but again, be aware of the security implications as identified previously in the section, "PE to Multiple Internet Gateways."
NOTE
This example is made more complex due to the fact that there is a single CE router performing both the hub and Internet gateway functions. A simpler method is to directly connect the firewall to the PE, but this requires two physical connections to the service provider network.
The configuration shown in Example 9-4 shows the PE configuration at the customer Hub Site A. The route to the service provider Internet gateway is imported into PUB_Customer1 using route-target import 9255:2 (assuming that there is a corresponding export elsewhere). Similarly, the customer's registered subnet is exported to the Internet gateway VRF to provide a return path for customer traffic using route-target export 9255:20. The Internet gateway VRF will have a corresponding route-target import 9255:20. The default-route is injected into VPN_ Customer1 to inform all VRFs how to get to the Internet (via the cache engine). The default-information-originate command must be added to the BGP portion of the VRF for the default-route to be redistributed.
Example 9-4. Customer Internet Hub PE Configuration Example
! !Define Customer Intranet VRF ip vrf VPN_Customer1 rd 9255:10650 route-target export 9255:10650 route-target import 9255:10650 ! !Define Customer Internet VRF ip vrf PUB_Customer1 rd 9255:106500 route-target export 9255:20 ! !Import routes for Service Provider Internet service route-target import 9255:2 interface Ethernet 3/0 ip vrf forwarding VPN_Customer1 ip address 202.160.223.1 255.255.252 interface Ethernet 3/1 ip vrf forwarding PUB_Customer1 ip address 202.160.223.5 255.255.252 ! !Static route for registered NAT address ip address vrf PUB_Customer1 171.69.223.208 255.255.255.240 ethernet 3/1 202.160.223.6 ! !Install default route into Intranet ip route vrf VPN_Customer1 0.0.0.0 0.0.0.0 ethernet 3/0 202.160.221.2 router bgp 9255 address-family ipv4 vrf VPN_Customer1 default-information-originate
In Example 9-5, for the CE, any traffic from Ethernet 0 (VPN_Customer1) that does not have an explicit entry into the CE's routing table will be forwarded to the LAN interface of the cache engine, which is reachable via Ethernet 1 (the customer's LAN). This behavior is achieved via the policy-based routing command set default next-hop Cache IP Address.
Traffic entering Ethernet interface 3 from the firewall will be directed to the PUB_Customer1 VRF via Ethernet 1. The firewall will be responsible for address translation. Traffic returning from the Internet will be directed back via the interface Ethernet 3. No special routing commands are necessary on return traffic because the destination address is always within the 171.69.233.208 255.255.255.240 space, which is only reachable via Ethernet 3.
In Example 9-5, there are a few 10BASE-X interfaces required. If a Fast Ethernet con-nection or an ATM/Frame Relay connection was used, then subinterfaces in the form of ISL or PVCs would reduce the physical requirement considerably. Otherwise, intranet traffic will be forwarded to Ethernet 2.
Example 9-5. Customer Internet Hub CE Configuration
! !Interface to Intranet VRF interface Ethernet 0 ip address 202.160.223.2 255.255.255.252 ip policy route-map TO_CacheEngine ! !Interface to Internet VRF (Public VRF) interface Ethernet 1 ip address 202.160.223.6 255.255.255.252 ! !Normal Customer LAN interface Ethernet 2 ip address 192.168.1.94 255.255.255.0 ! !Firewall and Cache subnet interface Ethernet 3 ip address 171.69.233.209 255.255.255.0 ip policy route-map TO_Internet route-map TO_Internet permit 10 set default interface Ethernet 1 route-map TO_CacheEngine set default next-hop Cache IP Address
Internet Access Using Global Routing Table
The previous scenarios focused on providing Internet access via a VRF that contains the default route to the Internet gateway. Another method is to use the global routing table to access the Internet gateway (see Figure 9-7):
A router with connectivity to the Internet is attached the MPLS network. It may or may not inject BGP routes into the global routing table. Note that only the PEs speak BGP; P routers do not run BGP at all.
Customers requiring access to the Internet will have a default route injected into their VRF pointing to the loopback address of the Internet gateway router. This address resides in the global routing table; therefore, the tag "global" is appended to end of the static route command. This forces the static route to look into the global routing table.
A static route to the customer network must also be injected into the global routing table pointing back to the CE. This static route could then be distributed into BGP for advertising to the Internet.
Figure 9-7. CE Access to Full Internet BGP Routing Table
The premise here is that the customer uses a registered address range that can exist in the service provider's global routing table. If the CE must perform NAT, then a separate subinterface would be required (to translate to), which is essentially the scenario described in the previous section.
NOTE
This method is not recommended where customers only have private addresses. Consider the following scenario: Customer A and Customer B both use the private address space 192.168.0.0. Customer A subscribes to Internet access via the global routing table (NAT must occur at the Internet gateway). Customer B wants access, but cannot get it because there is a duplication of addresses in the global routing table. To avoid this problem, address translation must be performed at the CE.
BGP Internet Routing Table from the Service Provider of an ISP
There may be customers who need to receive and announce routes from the Internet. (For example, an ISP's service provider may be wholesaling to use the service provider's VPN network or customers may require dual-homed Internet connectivity.)
NOTE
Importing the full BGP Internet routing table into a VRF is not a scalable solution and must be avoided.
The PE global routing table?that is, the routing table associated with IGP routes for the core, not any VRF?should be used to propagate Internet BGP routes. To provide Internet routes, a separate connection must be provisioned between the CE and the local PE for a BGP session. At the PE end, the circuit will not terminate in a VRF but will use the global routing table of the PE, which will contain the Internet routes. Therefore, the CE requires two physical/logical connections to the PE if the CE also participates in an MPLS-VPN intranet.
The PE is configured to redistribute Internet BGP routes to the customer CE via a BGP session. Conversely, any BGP routes from the CE that are injected into the global routing table are distributed into the Internet. The Internet routing table does not have to be redistributed to every PE in the MPLS network; only the PEs that are connected to the CEs require this redistribution.
To summarize, a CE that received BGP Internet routes and participates in MPLS VPNs requires two connections to the PE. These may be physical, or logical over a physical connection. Internet routes will appear in the global routing table of PEs as external BGP routes and will not have labels assigned to them. The labels associated with the Internet routes will be that of the BGP next hop. Therefore, all Internet routes will share the same label of the next hop BGP router.
NOTE
The BGP table does not need to be carried in the service provider core; it is carried only at the edges where customers require BGP routes.
NOTE
Since the CE has a direct connection to the PE outside a VRF, all global addresses in the service provider's MPLS network could be visible to the CE. Therefore, an access list is necessary on the inbound interface at the PE to deny access to any destination on the MPLS network.
Example 9-6 shows a simple BGP configuration. The CE has two interfaces, atm1/0.100 and atm1/0.200, connected to the PE. The interface atm1/0.100 carries the MPLS VPN traffic, while atm1.0.200 is connected to the MPLS global routing table where the Internet BGP routes reside. An eBGP session is configured over atm1/0.100, as the AS numbers between CE and PE are different.
Example 9-6. CE BGP Configuration Example for Internet Routes
interface loopback0 ip address 165.21.240.137 255.255.255.255 ! interface atm 1/0.100 description Interface to PE router (for Intranet and Services) ip address 202.160.223.10 255.255.255.252 ! interface atm1/0.200 description connection to the global table of the PE router ip address 170.10.0.1 255.255.255.240 ! interface Ethernet 0 description Connection to Customer LAN/WAN ip address 170.10.0.1 255.255.255.240 ! router bgp 100 neighbor 202.160.223.9 remote-as 9255 neighbor 202.160.223.9 update-source loopback0 network 170.10.0.0 !
NOTE
In this example, for an eBGP neighbor (which is the neighbor peering address), when update-source loopback0 is used, use the lookback IP address of the peering router over a multihop path, which is not a directly connected address, so the neighbor statements may not be required accordingly.
In Example 9-7, there are two BGP sessions defined: an external session to the CE and an internal session to the PE connecting the ISP. An inbound access list is associated with the eBGP session interface to restrict packets from the CE directly accessing the MPLS network. The first line in access-list 102 allows the two BGP peers (CE and PE) to communicate. The second line denies the CE network access to any destination address in the MPLS network. The third line permits Internet traffic to pass through to the ISP.
Example 9-7. PE BGP Configuration for Internet Routes
! interface loopback0 ip address 165.21.240.137 255.255.255.255 ! ! Define Customer Intranet VRF ip vrf VPN_Customer1 rd 9255:10650 route-target both 9255:10650 ! interface atm8/0/0.200 Description Connection for eBGP session and Internet Traffic ip address 202.160.223.9 255.255.255.252 ip access-group in 102 ! access-list 102 permit ip host 202.160.223.9 host 202.160.223.10 access-list 102 deny ip 202.160.223.0 255.255.0.0 any access-list permit any any ! router bgp 9255 neighbor 202.160.223.10 remote-as 100 (remote BGP session to CE) neighbor 202.160.223.10 update-source loopback0 neighbor 165.21.240.134 remote-as 200 (BGP session to PE connecting to ISP) neighbor 165.21.240.134 update-source loopback0
NOTE
In this example for an eBGP neighbor (which is the neighbor peering address), when the update-source loopback0 is used, use the lookback IP address of the peering router over a multihop path, which is not a directly connected address, so the neighbor statements may not be required accordingly.
Because the CE would have a direct connection to the PE outside a VRF, all global addresses in the service provider X MPLS network could be visible to the CE. Therefore, an access list would be necessary on the inbound interface at the PE to deny access to any destination in the MPLS global network.
Tier 3 ISP Connecting to an Upstream Tier via a Service Provider
In this scenario, shown in Figure 9-8, a smaller ISP gains access to the Internet via a larger upstream ISP that is wholesaling Internet access. The tier 3 ISP requires Internet routes. The connectivity between the two ISPs is via the service provider's MPLS network. In this scenario, both ISP connections can be terminated inside a VRF, even though they are exchanging BGP routes. The VRFs do not actually hold the BGP routes; they only hold the routes originating from the tier 3 ISP.
Figure 9-8. ISP-to-ISP Connection
The routing tables in the ISP routers will also contain the loopback address L1,L2 (entered statically). An eBGP session then can be established between the two CEs (ISP routers). Note that the tier3 ISP VRF does not need to explicitly contain the route to L1, as the default route will provide the connection. The tier 3 ISP will receive the BGP routing table with the next hop of L1, while the wholesale router will receive the tier 3 routes with the next hop of L3.
NOTE
For this solution to be scalable, the tier 3 ISP must not be a transit network for the other ISPs; otherwise, there will be too many routes in the VRF. This ensures that the VRF will only hold originating routes from the tier 3 ISP and not transit routes.
For example, assume that a tier 3 ISP has three address blocks allocated that the tier 3 ISP wishes to distribute to the Internet. Also, assume that the tier 3 ISP has a second connection to another ISP, hence the requirement for a BGP routing table. These three tier 3 ISP address routes are distributed to the tier 3 VRF. The PE connected to the tier 3 ISP imports a default route, which has been exported from the upstream wholesale ISP VRF. Similarly, the wholesale ISP VRF imports the tier 3 address routes.
Hybrid Model
There are organizations that currently deploy the hybrid service model as depicted in Figure 9-9 and implement a variety of the Internet access scenarios we have discussed. One of the main reasons for implementing the hybrid model is capital expenditure restrictions that preclude full service separation at the physical level, such as the Internet service PE, intranet service PE, and so on.
Figure 9-9. Key Issue: DoS Through a Shared PE Might Affect the VPN Customer
There are tier 1 service providers internationally deploying this model; there are other tier 1 customers that do implement a service separation at the physical level. The important factor is to be cognizant of the design choices and risks, as pointed out in Chapter 4. Additionally, the use of infrastructure ACLS and the development and deployment of high-availability hardware facilitate the implementation of a hybrid service model.
