Network-Based VPN Deployment ScenariosThis section looks at some common deployment scenarios for the network-based VPN solution:
IPSec to MPLS VPN over GRE
IPSec to Layer 2 VPN
PE-PE encryption IPSec to MPLS VPN over GREThe most common application for the network-based VPN solution is to extend the MPLS VPN service provider footprint over the Internet. You learned the operation of this scenario in the previous section. You also learned from previous chapters that dynamic routing is desirable for site-to-site VPNs. Because an MPLS VPN provides dynamic routing capabilities, it would be very desirable to extend the dynamic routing capabilities to the extended sites over IPSec. The need for dynamic routing forces the use of IPSec over GRE. Figure 9-6 shows the topology that we use to describe this deployment model.
Figure 9-6. IPSec to MPLS VPN over GRE
SPOKE-VPN2-EAST is the spoke that will have a GRE tunnel protected by IPSec to VPN-GW1- EAST. EIGRP is the routing protocol between the hub and spoke. At the hub that is also the MPLS VPN PE, one could redistribute the spoke routes into MP-BGP and advertise it to remote PEs. Similarly, routes from remote PEs can be advertised to the spoke by redistributing into EIGRP from MP-BGP. Example 9-25 shows the configuration of the hub. Example 9-25. Configuration on VPN-GW1-EAST Terminating GRE Tunnels into a VRFvpn-gw1-east#show running-config ! hostname vpn-gw1-east ! ! ! ip vrf vpn1 rd 200:1 route-target export 200:1 route-target import 200:1 ! ip vrf vpn2 rd 201:1 route-target export 201:1 route-target import 201:1 ! ip cef mpls label protocol ldp tag-switching ip default-route ! crypto keyring vpn1 pre-shared-key address 9.1.1.146 key vpn1aes crypto keyring vpn2 pre-shared-key address 9.1.1.150 key vpn2ikev2 ! crypto isakmp policy 1 authentication pre-share group 2 crypto isakmp keepalive 10 10 crypto isakmp profile vpn2 keyring vpn2 match identity address 9.1.1.150 255.255.255.255 ! ! crypto ipsec transform-set vpn1 esp-3des esp-sha-hmac crypto ipsec transform-set vpn2 esp-3des esp-md5-hmac mode transport ! crypto ipsec profile tunnel set transform-set vpn2 ! ! interface Tunnel0 ip vrf forwarding vpn2 ip address 10.2.1.1 255.255.255.0 tunnel source 9.1.1.35 tunnel destination 9.1.1.150 tunnel protection ipsec profile tunnel ! interface Loopback0 ip address 9.2.1.100 255.255.255.255 ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 duplex full crypto map vpn ! interface FastEthernet2/0 ip address 100.1.1.147 255.255.255.0 duplex full ! interface FastEthernet4/0 ip address 9.2.1.1 255.255.255.252 duplex full tag-switching ip ! router eigrp 1 auto-summary ! address-family ipv4 vrf vpn2 redistribute bgp 1001 metric 10000 100 255 1 1500 network 10.2.1.0 0.0.0.255 auto-summary autonomous-system 1 exit-address-family ! router ospf 1 log-adjacency-changes redistribute static subnets network 9.2.1.0 0.0.0.3 area 0 network 9.2.1.100 0.0.0.0 area 0 ! router bgp 1001 no synchronization bgp log-neighbor-changes neighbor 153.1.1.1 remote-as 1001 neighbor 153.1.1.1 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 153.1.1.1 activate neighbor 153.1.1.1 send-community extended exit-address-family ! address-family ipv4 vrf vpn2 redistribute connected redistribute static redistribute eigrp 1 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf vpn1 redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! ip local pool vpn1pool 192.168.1.1 192.168.1.100 group vpn1group ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server no ip http secure-server ! end The key part of the configuration is that the GRE tunnel is configured to be in a VRF. Once the IPSec packet gets decrypted, it is handed over to the GRE tunnel and, as the GRE tunnel is in a VRF, the IP packet flows are mapped into the appropriate VRF. DMVPN and VRFThe IPSec GRE scenario can be extended to use DMVPN, an option that is explored in this section. In Chapter 7, "Auto-Configuration Architectures for Site-to-Site IPSec VPNs," you learned how Dynamic Multipoint VPN (DMVPN) drastically reduces configuration complexity at the hub for a hub-and-spoke VPN. DMVPN can be used to scale the configuration of the PE in the network-based solution. Each VPN in this solution requires a unique mGRE interface terminated in a VRF. Figure 9-7 shows this scenario and Example 9-26 represents a typical configuration on the PE.
Figure 9-7. DMVPN Tunnel into a VRF
Example 9-26. DMVPN Configuration on VPN-GW1-EAST Mapped to VRFsvpn-gw1-east#show running-config version 12.3 service timestamps debug datetime service timestamps log datetime msec no service password-encryption ! hostname vpn-gw1-east ! ip vrf vpn1 rd 200:1 ! ip vrf vpn2 rd 201:1 ! ip cef mpls label protocol ldp tag-switching ip default-route no ftp-server write-enable ! crypto keyring vpn1 pre-shared-key address 9.1.1.146 key vpn1aes crypto keyring vpn2 pre-shared-key address 9.1.1.150 key vpn2ikev2 ! crypto isakmp policy 1 authentication pre-share group 2 crypto isakmp keepalive 10 10 ! crypto ipsec transform-set dmvpn esp-3des esp-md5-hmac mode transport ! crypto ipsec profile tunnel set transform-set dmvpn ! ! interface Tunnel0 ip vrf forwarding vpn1 ip address 10.2.1.1 255.255.255.0 ip mtu 1400 ip nhrp authentication coke ip nhrp map multicast dynamic ip nhrp network-id 100 ip nhrp holdtime 600 no ip split-horizon eigrp 1 tunnel source Loopback0 tunnel key 100 tunnel protection ipsec profile tunnel shared ! interface Tunnel1 ip vrf forwarding vpn2 ip address 10.3.1.1 255.255.255.0 ip mtu 1430 ip nhrp authentication vpn2 ip nhrp map multicast multicast ip nhrp network-id 101 ip nhrp holdtime 600 no ip split-horizon eigrp 1 ip nhrp nhs 10.1.1.1 tunnel source Loopback0 tunnel key 101 tunnel protection ipsec profile tunnel shared interface Loopback0 ip address 9.2.1.100 255.255.255.255 ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 duplex full ! interface FastEthernet2/0 ip address 100.1.1.147 255.255.255.0 duplex full ! interface FastEthernet4/0 ip address 9.2.1.1 255.255.255.0 duplex full mpls-ip ! router eigrp 1 auto-summary ! address-family ipv4 vrf vpn2 redistribute static redistribute connected network 10.3.1.0 0.0.0.255 auto-summary autonomous-system 1 exit-address-family ! address-family ipv4 vrf vpn1 redistribute static redistribute connected network 10.2.1.0 0.0.0.255 auto-summary autonomous-system 1 exit-address-family ! ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server no ip http secure-server ! In the configuration example shown in Example 9-26, the tunnel addresses used by the tunnels are on unique subnets for the sake of clarity. The subnets used on the mGRE tunnels for each VRF can be overlapping if so desired. One last statement with respect to the configuration is that if both tunnels are sharing the same IPSec profiles, they can be unique per tunnel if desired. Note If the spokes in the DMVPN solution are assigned IP addresses dynamically, this becomes an issue on the hub as the only possible option today is to have wild card keys for all VPNs if you want to use pre-shared Keys. A better option would be to use RSA-SIG [CERTS] authentication. IPSec to L2 VPNsThis scenario is similar to mapping a site into an MPLS VPN over IPSec, except that in this case, the traffic after decryption at the PE is mapped into an outbound interface that is also in a VRF. This scenario is useful for a Layer 2 provider (such as an ATM or Frame-Relay provider) to extend their footprint. The provider could terminate CPEs and remote access clients via IPSec to a PE at the edge of their cloud and map them to appropriate customer VRFs. Each of these VRFs is also mapped to the corresponding VPN customer's L2 Virtual Circuit (Ethernet VLAN, ATM, or Frame Relay VC). The IPSec packets coming in through the Internet are decrypted and mapped to the right VRF; once they are in the VRF, a route lookup is done before they are sent out through the right L2 Virtual Circuit. Figure 9-8 shows this scenario and Example 9-27 shows the configuration for this scenario.
Figure 9-8. Mapping IPSec into L2VPN
Example 9-27. Configuration on VPN-GW1-EAST Showing Termination of an IPSec Session and Mapping Them to Routed ATM Interfacesvpn-gw1-east#show running-config version 12.3 service timestamps debug datetime service timestamps log datetime msec no service password-encryption ! hostname vpn-gw1-east aaa new-model ! aaa authentication login vpn group radius aaa authorization network vpn group radius aaa accounting update periodic 5 aaa accounting network vpn start-stop group radius aaa session-id common ip subnet-zero ! ! ip vrf vpn1 rd 200:1 ! ip vrf vpn2 rd 201:1 ! ip cef mpls label protocol ldp tag-switching ip default-route no ftp-server write-enable ! crypto keyring vpn1 pre-shared-key address 9.1.1.146 key vpn1aes crypto keyring vpn2 pre-shared-key address 9.1.1.150 key vpn2ikev2 ! crypto isakmp policy 1 authentication pre-share group 2 crypto isakmp keepalive 10 10 crypto isakmp profile vpn1 vrf vpn1 keyring vpn1 match identity address 9.1.1.146 255.255.255.255 crypto isakmp profile vpn1-ra vrf vpn1 match identity group vpn1group client authentication list vpn isakmp authorization list vpn client configuration address respond accounting vpn crypto isakmp profile vpn2 vrf vpn2 keyring vpn2 match identity address 9.1.1.150 255.255.255.255 ! ! crypto ipsec transform-set vpn1 esp-3des esp-sha-hmac crypto ipsec transform-set vpn2 esp-3des esp-md5-hmac mode transport ! ! ! crypto dynamic-map dynamic 1 set transform-set vpn1 set isakmp-profile vpn1-ra reverse-route remote-peer 9.1.1.33 ! ! crypto map vpn 1 ipsec-isakmp set peer 9.1.1.146 set transform-set vpn1 set isakmp-profile vpn1 reverse-route remote-peer address 9.1.1.33 match address 101 crypto map vpn 2 ipsec-isakmp set peer 9.1.1.150 set transform-set vpn2 set isakmp-profile vpn2 reverse-route remote-peer address 9.1.1.33 match address 102 crypto map vpn 3 ipsec-isakmp dynamic dynamic ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 duplex full crypto map vpn ! interface FastEthernet2/0 ip address 100.1.1.147 255.255.255.0 duplex full ! interface ATM 4/0 no ip address interface ATM4/0.1 ip address 9.2.1.1 255.255.255.252 ip vrf forwarding vpn1 pvc 0/101 encapsulation aal5snap broadcast interface ATM4/0.2 ip address 9.2.1.1 255.255.255.252 ip vrf forwarding vpn2 pvc 0/102 encapsulation aal5snap broadcast ! router eigrp 1 auto-summary ! address-family ipv4 vrf vpn2 redistribute static network 9.2.1.0 0.0.0.255 auto-summary autonomous-system 1 exit-address-family ! address-family ipv4 vrf vpn1 redistribute static network 9.2.1.0 0.0.0.255 auto-summary autonomous-system 1 exit-address-family ip local pool vpn1pool 192.168.1.1 192.168.1.100 group vpn1group ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server no ip http secure-server ! radius-server host 100.1.1.4 auth-port 1645 acct-port 1646 radius-server key cisco radius-server vsa send accounting ! end In this example, all traffic from the remote CE is decrypted and mapped into the ATM sub-interface of the appropriate VPN. PE-PE EncryptionOne of the primary requirements for a VPN service is security. Traditional CE-based IPSec VPNs offer data security by encrypting data from CE-CE. For an MPLS VPN, the security comes from the separation of routing contexts (VRFs) at the PE. Of course, one could have an IPSec overlay of CEs over an MPLS VPN to provide data encryption, which means that every CE on that VPN has to build a full mesh of encrypted tunnels to every other CPE on that VPN over the provider's backbone. The overlay model defeats the scalability and any-to-any optimal routing of MPLS VPNs. The primary driver for providers to encrypt PE-PE traffic is to extend MPLS VPN (RFC 2547bis) service across IP backbones that they have no control over (for example, the Internet). Also, this solution provides end-to-end encryption CE to PE, PE to PE, and PE to CE. Figure 9-9 shows the PE-PE encryption scenario.
Figure 9-9. PE-PE Encryption
One of the requirements used for PE-PE encryption is to build an MPLS-in-GRE packet between the PEs and encrypt the GRE-encapsulated packet using IPSec. Note The IETF MPLS VPN service using GRE is very well documented in the IETF draft [draft-ietf-l3vpn-gre-ip-2547-03.txt]. The deployment technique shown here for PE-PE encryption is to run LDP and MP-BGP over the GRE tunnel. One could also run MP-BGP outside the GRE tunnel and set the next_hop for the vpn prefixes via the GRE tunnel. Note that the use of GRE point-to-point tunnels for any-to-any PE-PE encryption requires a full mesh of GRE tunnels between the PEs. Example 9-28 shows the configuration for PE-PE encrypted GRE tunnel running MPLS VPNs. Example 9-28. Configuration on VPN-GW1-EAST Showing PE-PE Encryption
vpn-gw1-east#show running-config
hostname vpn-gw1-east
!
ip vrf vpn1
rd 200:1
route-target export 200:1
route-target import 200:1
!
ip vrf vpn2
rd 201:1
route-target export 201:1
route-target import 201:1
!
mpls label protocol ldp
tag-switching tdp router-id Loopback0
tag-switching ip default-route
!
crypto keyring vpn1
pre-shared-key address 9.1.1.145 key vpn1aes
crypto keyring vpn2
pre-shared-key address 9.1.1.149 key vpn2ikev2
!
crypto isakmp policy 1
authentication pre-share
group 2
!
crypto isakmp keepalive 10 10
!
crypto isakmp profile vpn1
vrf vpn1 description IVRF
keyring vpn1
match identity address 9.1.1.145 255.255.255.255
accounting vpn
!
crypto isakmp profile vpn1-ra
vrf vpn1
match identity group vpn1group
client authentication list vpn
isakmp authorization list vpn
client configuration address respond
accounting vpn
!
crypto isakmp profile vpn2
vrf vpn2
keyring vpn2
match identity address 9.1.1.149 255.255.255.255
accounting vpn
!
crypto ipsec transform-set vpn1 esp-3des esp-sha-hmac
crypto ipsec transform-set vpn2 esp-3des esp-md5-hmac
!
crypto dynamic-map dynamic 1
set transform-set vpn1
set isakmp-profile vpn1-ra
reverse-route remote-peer 9.1.1.33
!
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.146
set transform-set vpn1
set isakmp-profile vpn1
reverse-route remote-peer address 9.1.1.33
match address 101
crypto map vpn 2 ipsec-isakmp
set peer 9.1.1.150
set transform-set vpn2
set isakmp-profile vpn2
reverse-route remote-peer address 9.1.1.33
match address 102
crypto map vpn 3 ipsec-isakmp dynamic dynamic
!
interface Tunnel0
ip address 100.1.1.1 255.255.255.252
tunnel source 9.2.1.100
tunnel destination 9.2.1.101
mpls-ip
tunnel protection ipsec profile tunnel
!
interface Loopback0
ip address 9.2.1.100 255.255.255.255
!
interface FastEthernet0/0
description FVRF
ip address 9.1.1.35 255.255.255.248
duplex full
random-detect
crypto map vpn
!
interface FastEthernet2/0
ip address 100.1.1.147 255.255.255.0
duplex full
!
interface FastEthernet4/0
ip address 9.2.1.1 255.255.255.252
duplex full
!
router ospf 1
log-adjacency-changes
network 9.2.1.0 0.0.0.3 area 0
!
router bgp 1001
no synchronization
bgp log-neighbor-changes
neighbor 100.100.1.2 remote-as 1001
neighbor 100.100.1.2 update-source tunnel0
no auto-summary
!
address-family vpnv4
neighbor 100.100.100.2 activate
neighbor 100.100.100.2 send-community extended
exit-address-family
!
address-family ipv4 vrf vpn2
redistribute connected
redistribute static
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
redistribute static
no auto-summary
no synchronization
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 9.1.1.33 (default route to the Internet)
ip route 153.1.1.1 255.255.255.255 Tunnel0
!
access-list 100 permit ip 10.0.1.0 0.0.0.255 any
access-list 101 permit ip 10.0.1.0 0.0.0.255 any
vpn-gw1-east#show ip route vrf vpn1
Routing Table: vpn1
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 S- static
route
Gateway of last resort is not set
9.0.0.0/32 is subnetted, 1 subnets
S 9.1.1.146 [1/0] via 9.1.1.33
10.0.0.0/24 is subnetted, 2 subnets
B 10.1.1.0 [200/0] via 100.100.100.2, 00:23:17
S 10.0.68.0 [1/0] via 9.1.1.146
vpn-gw1-east#show mpls ldp nei
Peer LDP Ident: 153.1.1.1:0; Local LDP Ident 9.2.1.100:0
TCP connection: 153.1.1.1.11056 - 9.2.1.100.646
State: Oper; Msgs sent/rcvd: 785/783; Downstream
Up time: 00:25:33
LDP discovery sources:
Tunnel1, Src IP addr: 100.100.100.2
Addresses bound to peer LDP Ident:
153.1.1.1 163.1.1.1 100.100.100.2
vpn-gw1-east#show ip bgp vpn vrf vpn1
BGP table version is 51, local router ID is 9.2.1.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 200:1 (default for vrf vpn1)
* 9.1.1.146/32 9.1.1.33 0 32768 ?
*> 10.0.68.0/24 9.1.1.146 0 32768 ?
*>i10.1.1.0/24 100.100.100.2 0 100 0 ?
* i 153.1.1.1 0 100 0 ?
vpn-gw1-east#show ip cef vrf vpn1
10.1.1.0/24, version 20, epoch 0
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Tu1, point2point, tags imposed: {498}
via 100.100.100.2, 0 dependencies, recursive
next hop 100.100.100.2, Tunnel1 via 100.100.100.0/24
valid adjacency
tag rewrite with Tu1, point2point, tags imposed: {498}
From the different outputs, you can see that the next hop for the BGP learned routes in the routing table for each of the VRFs and the LDP neighbor on VPN-GW1-EAST is learned via the tunnel. The forwarding information for the VRF VPN1 learned routes point toward the far-end PE tunnel IP address (100.100.100.2) with the appropriate VPN label (498). The downside to PE-PE encryption is that PE-CE data is still in the clear. Of course, one could also encrypt data on the PE-CE link in addition to PE-PE encryption. But, then the PE has to do much more work. It has to decrypt data from the CE-PE and re-encrypt the data for the PE-PE.
|