Operation of Network-Based IPSec VPNs
Now that you have an understanding of the key features in IOS for network-based IPSec VPNs, you are ready to examine the operation of this solution. One of the primary motivations for a network-based IPSec VPN is to extend the service provider's footprint over the public Internet. There are several options a service provider has to provide this extension. One could make each PE router IPSec capable; another would be to have a set of dedicated IPSec PEs that is primarily used for this service. The latter is generally the more common approach given the financial considerations and the fact that not all PEs are IPSec capable.
There are two deployment scenarios to offer this solutionone of them uses a single IP address on the PE reachable from the Internet for terminating IPSec tunnels of multiple VPNs and the second one uses a unique IP address per VPN on the terminating PE.
A Single IP Address on the PE
In an MPLS VPN, separation of a CE belonging to a particular VPN is made by explicitly configuring the PE-CE link on the PE to the appropriate VRF. Forwarding decisions for all traffic that is received from the CE are made by referencing the VRF that the PE-CE interface is configured with.
With an understanding of how MPLS VPNs operate, an obvious solution to extend reachability of the CEs across the Internet is to have a dedicated interface facing the Internet explicitly configured in a VRF and terminating IPSec tunnels from the corresponding CEs across the Internet into its VRF interface. Although this solution works, it requires a unique IP address or sub-interface per VRF that is reachable from the Internet.
A more elegant solution would be to use a single IP address for terminating the off-net IPSec tunnels, but this presents some interesting challenges. One issue is that a mechanism is needed to somehow separate the CEs belonging to different VPNs and map the traffic to the appropriate VRF.
The operation of mapping the IPSec tunnels into the appropriate VRFs involves several concepts mentioned earlier in this chapter and explained in the following section. One of these concepts is the concept of a front-door VRF (FVRF) and an inside VRF (IVRF).
Front-Door and Inside VRF
Each IPSec tunnel is associated with two VRF domains. The outer IP header of the tunnel-mode IPSec encapsulated packet belongs to the FVRF, whereas the inner IP header is associated with the VPNs private IVRF. Figure 9-3 illustrates the concept of a FVRF and an IVRF. The FVRF pertains to the VRF that the encrypted packet itself is in. The FVRF is commonly on a global VRF. In this example, in which all the IPSec tunnels terminate on a single IP address on the PE facing the Internet, the global interface facing the Internet is considered to be in the FVRF. The IVRF is used for post-decryption forwarding lookups for IPSec traffic terminating on the aggregation PE.
[View full size image]
In this example, where all the IPSec tunnels terminate on a single IP address on the PE, the FVRF is the same and is set to the VRF configured on the Internet-facing interface. Traffic arriving from remote CEs that is associated with the IVRF is done during IKE negotiation using ISAKMP profiles.
Configuration and Packet Flow
Now that you have a conceptual understanding of FVRF and IVRF, this section will explore the configuration details and packet flow for the deployment scenario of a single IP address on the PE. The single IP address is used for terminating IPSec tunnels from remote sites and telecommuters that belong to multiple VPNs. Figure 9-4 illustrates this scenario.
[View full size image]
The complete configuration of the PE router terminating the IPSec tunnels from remote CE sites belonging to multiple VPNs and telecommuters (also known as remote access clients) is shown in Example 9-6.
Example 9-6. Configuration of the PE (VPN-GW1-EAST)
vpn-gw1-east# show running-configuration
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 vpn1 group radius
aaa authorization network vpn1 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
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
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
!
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 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 ospf 1
log-adjacency-changes
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
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 10.254.245.1 10.254.254.254 group vpn1group
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.33
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
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
vpn-gw1-east#
We'll parse the configuration on the PE/IPSec aggregator shown in Example 9-6 to illustrate how the association of the inner IP header of the IPSec packet to the IVRF takes place. In this example, the MPLS-PE at the edge of the service provider network is also the IPSec aggregator. We will divide the PE configuration in Example 9-6 into three parts:
The first part is the generic MPLS-VPN configuration. The second part of the configuration is relevant to the termination of the IPSec tunnel from a remote-site CE. The third part is relevant to the IPSec tunnel termination from a remote access client or a telecommuter.
Generic MPLS VPN Configuration on the PE
Example 9-7 shows the parts of the configuration that are relevant to the generic MPLS VPN configuration of the PE router.
Example 9-7. MPLS VPN Relevant Configuration on the PE
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
!
interface FastEthernet0/0
ip address 9.1.1.35 255.255.255.248
duplex full
crypto map vpn
!
interface FastEthernet4/0
ip address 9.2.1.1 255.255.255.252
duplex full
tag-switching ip
!
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
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
!
In this example, note that there are no PE-CE interfaces explicitly configured in a VRF. The IP address that is reachable from the Internet is 9.1.1.35, configured on the physical interface FastEthernet 0/0. This interface is logically in the front-door VRF on which a crypto map is also configured. In other words, the FVRF is the global routing table. There are two IVRFs configured: VPN1 and VPN2. The rest of the MPLS VPN configuration is basic MPLS VPN configuration (configuration of MP-BGP, RD, and RT), which is outside of the scope of this discussion.
Mapping an IPSec Tunnel from a Site into IVRF at the PE
This section will present the configuration relevant to map the IPSec tunnel from the remote site into an IVRF and explain the packet flow for this mapping.
Before looking at the PE config for the IPSec termination, review Example 9-8, which shows the relevant portions of configuration of the CE router at the branch site.
Example 9-8. Configuration of the CE (SPOKE-VPN1-EAST)
spoke-vpn1-east#show running-config
hostname spoke-vpn1-east
!
crypto isakmp policy 1
authentication pre-share
group 2
crypto isakmp key vpn1aes address 9.1.1.35
crypto isakmp keepalive 10 10
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
!
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.35
set transform-set test
match address 100
!
interface Serial0/0
ip address 9.1.1.146 255.255.255.252
crypto map vpn
!
interface Ethernet0/1
ip address 10.0.68.1 255.255.255.0
half-duplex
no keepalive
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145
!
access-list 100 permit ip 10.0.68.0 0.0.0.255 any
!
Notice that the configuration of the CE router in Example 9-8 is no different than a typical IPSec site router. The IPSec peer address is set to the IP address of the PE (9.1.1.35). The crypto configuration on the serial0/0 interface will trigger IKE and IPSec for packets that match the policy defined in access list 100.
Next, you'll take a step-by-step look at how the IPSec tunnel initiated by the CE router is mapped into the IVRF VPN1 that the CE belongs to. Refer to Figure 9-4 for this discussion, in which it is assumed that the traffic originates from the SPOKE-VPN1-EAST's subnet 10.0.68.0 destined to the remote subnet 10.1.1.0 on PE2. Note that in this discussion, the terms CE and SPOKE-VPN1-EAST are used interchangeably, as well as the terms PE and VPN-GW1-EAST.
Step 1. | Inserting traffic that matches IPSec policy on the CE (SPOKE-VPN1-EAST) will trigger IKE negotiation to start establishing an IPSec tunnel with its IPSec peer 9.1.1.35 (VPN-GW1-EAST).
| Step 2. | The IKE packet from the CE is received on VPN-GW1-EAST's FastEthernet0/0 interface.
| Step 2.1. | After the IKE packet from the CE is received at the PE via FastEthernet0/0 interface, the crypto configuration on the interface triggers IKE Phase 1 processing. Example 9-9 shows the relevant portions of the configuration from VPN-GW1-EAST and the debug output for this step. Example 9-9. Configuration Snippet and Debug from VPN-GW1-EAST for IKE Processing
interface FastEthernet0/0
description FVRF
ip address 9.1.1.35 255.255.255.248
duplex full
random-detect
crypto map vpn
vpn-gw1-east# debug crypto isakmp sa
*Jan 5 19:27:48: ISAKMP (0:0): received packet from 9.1.1.146 dport 500 sport 500
*Jan 5 19:27:48: ISAKMP: local port 500, remote port 500
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_READY New State = IKE_R_MM1
| Step 2.2. | As you saw in Chapter 2, "IPSec Overview," IKE Main Mode processing consists of six messages between the initiator and the responder. In this scenario, we won't go through all six messages; the debug output clearly shows the sequence of the messages and the IKE state changes.
|
One of the first checks in IKE Phase 1 is to see if there is a key associated with the source address of the IKE packet (9.1.1.146). If there is a key for the IKE peer, Main Mode negotiation will continue. The configuration portion for this check and the debug output is shown in Example 9-10.
Example 9-10. Configuration Snippet and Debug Output from VPN-GW1-EAST for Step 2.2
crypto keyring vpn1
pre-shared-key address 9.1.1.146 key vpn1aes
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in default
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in vpn1 : success
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):found peer pre-shared key matching 9.1.1.146
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): local preshared key found
Step 2.3. | IKE Main Mode processing of messages three and four is no different than typical IKE Main Mode processing, so we'll skip the explanation for these messages.
| Step 3. | In the fifth message exchange of IKE Main Mode, the identification payload is checked for the IKE Phase 1 identity and the associated keyring. When this check is passed, the ISAKMP profile in turn associates the CE to an IVRF. In this example, the match is for the CE's IP address (9.1.1.146) that will associate all encrypted packets from this source IP address to the IVRF VPN1, as shown in Example 9-11. Example 9-11. Configuration and Debug Output for Step 3
crypto isakmp profile vpn1
vrf vpn1
keyring vpn1
match identity address 9.1.1.146 255.255.255.255
vpn-gw1-east# debug crypto isakmp sa *Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State =
IKE_R_MM4 New State = IKE_R_MM5
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing ID payload. message ID = 0
*Jan 5 19:27:48: ISAKMP (0:134217731): ID payload
next-payload : 8
type : 1
address : 9.1.1.146
protocol : 17
port : 0
length : 12
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):: peer matches vpn1 profile
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in default
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in vpn1 : suc
cess
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Found ADDRESS key in keyring vpn1
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing HASH payload. message ID = 01
spi 0, message ID = 0, sa = 6509F278
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):SA authentication status:
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): authenticated
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):SA has been authenticated with 9.1.1.146
*Jan 5 19:27:48: ISAKMP: Trying to insert a peer 9.1.1.35/9.1.1.146/500/, and inserted
successfully.
|
The entire debug output with all six messages of the IKE Main Mode processing between the CE and the PE is shown in Example 9-12.
Example 9-12. Debug Output for Main Mode IKE Between CE and PE
vpn-gw1-east# debug crypto isakmp sa
*Jan 5 19:27:48: ISAKMP (0:0): received packet from 9.1.1.146 dport 500 sport 500
*Jan 5 19:27:48: ISAKMP: local port 500, remote port 500
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_READY New State = IKE_R_MM1
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing SA payload. message ID = 0
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing vendor id payload
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): vendor ID seems Unity/DPD but major 157 mis
match
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): vendor ID is NAT-T v3
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing vendor id payload
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): vendor ID seems Unity/DPD but major 123 mis
match
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): vendor ID is NAT-T v2
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in default
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in vpn1 : success
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):found peer pre-shared key matching 9.1.1.146
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): local preshared key found
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Checking ISAKMP transform 1 against priority 1
policy
*Jan 5 19:27:48: ISAKMP: encryption DES-CBC
*Jan 5 19:27:48: ISAKMP: hash SHA
*Jan 5 19:27:48: ISAKMP: default group 2
*Jan 5 19:27:48: ISAKMP: auth pre-share
*Jan 5 19:27:48: ISAKMP: life type in seconds
*Jan 5 19:27:48: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):atts are acceptable. Next payload is 3
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): constructed NAT-T vendor-03 ID
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): sending packet to 9.1.1.146 my_port 500 peer_port
500 (R) MM_SA_SETUP
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_R_MM1 New State = IKE_R_MM2
*Jan 5 19:27:48: ISAKMP(0:134217731): received packet from 9.1.1.146 dport 500sport
500 Global (R) MM_SA_SETUP
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_R_MM2 New State = IKE_R_MM3
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing KE payload. message ID = 0
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing NONCE payload. message ID = 0
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in default
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):SKEYID state generated
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing vendor id payload
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): vendor ID is Unity
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing vendor id payload
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): vendor ID is DPD
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing vendor id payload
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): speaking to another IOS box!
*Jan 5 19:27:48: ISAKMP:received payload type 17
*Jan 5 19:27:48: ISAKMP:received payload type 17
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM3
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): sending packet to 9.1.1.146 my_port 500 peer_port
500 (R) MM_KEY_EXCH
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_R_MM3 New State = IKE_R_MM4
*Jan 5 19:27:48: ISAKMP (0:134217731): received packet from 9.1.1.146 dport 500sport
500 Global (R) MM_KEY_EXCH
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Old State = IKE_R_MM4 New State = IKE_R_MM5
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing ID payload. message ID = 0
*Jan 5 19:27:48: ISAKMP (0:134217731): ID payload
next-payload : 8
type : 1
address : 9.1.1.146
protocol : 17
port : 0
length : 12
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):: peer matches vpn1 profile
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in default
*Jan 5 19:27:48: ISAKMP: Looking for a matching key for 9.1.1.146 in vpn1 : suc
cess
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):Found ADDRESS key in keyring vpn1
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): processing HASH payload. message ID = 01
spi 0, message ID = 0, sa = 6509F278
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):SA authentication status:
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1): authenticated
*Jan 5 19:27:48: ISAKMP:(0:3:SW:1):SA has been authenticated with 9.1.1.146
*Jan 5 19:27:48: ISAKMP: Trying to insert a peer 9.1.1.35/9.1.1.146/500/, and inserted
successfully.
Output from Example 9-13 shows that IKE SAs are successfully established and mapped to the IVRF.
Example 9-13. IKE SAs Established at the PE
vpn-gw1-east#show cry isa sa det
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
C-id Local Remote I-VRF Encr Hash Auth DH Lifetime Cap
3 9.1.1.35 9.1.1.146 vpn1 des sha psk 2 23:53:32 D
Step 4. | After Step 3 is complete and the VRF association is completed for the CE, Quick Modealso known as IKE Phase 2 negotiationestablishes the IPSec SAs in the IVRF. Example 9-14 shows the debug and show output for the establishment of the IPSec SAs. Example 9-14. Debugs of Quick Mode Exchange Between VPN-GW1-EAST and SPOKE-VPN1-EAST
vpn-gw1-east# debug crypto ipsec sa
*Jan 5 19:27:49: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 9.1.1.35, remote= 9.1.1.146,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 10.0.68.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-sha-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2
*Jan 5 19:27:49: IPSEC(kei_proxy): head = vpn, map->ivrf = vpn1, kei->ivrf = vpn1
*Jan 5 19:27:49: ISAKMP:(0:3:SW:1): Creating IPSec SAs
*Jan 5 19:27:49: inbound SA from 9.1.1.146 to 9.1.1.35 (f/i) 0/ 1(proxy
10.0.68.0 to 0.0.0.0)
*Jan 5 19:27:49: has spi 0x26C9B2C9 and conn_id 2000 and flags
*Jan 5 19:27:49: lifetime of 3600 seconds
*Jan 5 19:27:49: lifetime of 4608000 kilobytes
*Jan 5 19:27:49: has client flags 0x0
*Jan 5 19:27:49: outbound SA from 9.1.1.35 to 9.1.1.146 (f/i) 0/1(proxy 0.0.0.0
to 10.0.68.0)
*Jan 5 19:27:49: has spi 0xD6B17A4B and conn_id 2001 and flags
*Jan 5 19:27:49: lifetime of 3600 seconds
*Jan 5 19:27:49: lifetime of 4608000 kilobytes
*Jan 5 19:27:49: has client flags 0x0
*Jan 5 19:27:49.105: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer
9.1.1.146:500 Id: 9.1.1.146
vpn-gw1-east#show cry ipsec sa
interface: FastEthernet0/0
Crypto map tag: vpn, local addr. 9.1.1.35
protected vrf: vpn1
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0)
current_peer: 9.1.1.146:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 18, #pkts encrypt: 18, #pkts digest: 18
#pkts decaps: 18, #pkts decrypt: 18, #pkts verify: 18
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 9.1.1.35, remote crypto endpt.: 9.1.1.146
path mtu 1500, media mtu 1500
current outbound spi: D6B17A4B
inbound esp sas:
spi: 0x26C9B2C9(650752713)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
crypto engine type: Software, engine_id: 1
sa timing: remaining key lifetime (k/sec): (4474313/3483)
ike_cookies: EDBF1C2F EDAF2452 038F7139 17D8D460
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xD6B17A4B(3601955403)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
crypto engine type: Software, engine_id: 1
sa timing: remaining key lifetime (k/sec): (4474313/3483)
ike_cookies: EDBF1C2F EDAF2452 038F7139 17D8D460
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
| Step 5. | Reverse Route Injections (RRI) configured on the static crypto map injects a static route for the CE's protected subnet (10.0.68.0) in VRF VPN1's routing table. Example 9-15 shows the configuration and the route injected by reverse route. Example 9-15. Route Injected by Reverse Route within the VRF on VPN-GW1-EAST
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
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
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded 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 153.1.1.1, 3d02h
S 10.0.68.0 [1/0] via 9.1.1.146
|
Notice, the routing table entry for the CE's private subnet is reachable via 9.1.1.146, which is the CE's IP address reachable from the Internet. But how do packets that are destined from the PE in the IVRF on the PE get forwarded? Notice the static route installed in the VRF VPN1 for 9.1.1.146 that is reachable via 9.1.1.33. The 9.1.1.33 address is the IP address of the Internet gateway connected to this PE in the FVRF, which is fa0/0 in this example. CEF will precompute this recursion for the CE subnet's reachability, as shown in Example 9-16.
Example 9-16. Output of CEF for Route Injected by Reverse Route
vpn-gw1-east#show ip cef vrf vpn1 10.0.68.0
10.0.68.0/24, version 6, epoch 0, cached adjacency 9.1.1.33
0 packets, 0 bytes
tag information set
local tag: 528
via 9.1.1.146, 0 dependencies, recursive
next hop 9.1.1.33, FastEthernet0/0 via 0.0.0.0/0
valid cached adjacency
tag rewrite with Fa0/0, 9.1.1.33, tags imposed: {}
Step 6. | The SPOKE-VPN1-EAST's subnet 10.0.68.0 is advertised to all other PEs by redistributing this route into MP-BGP. Redistribution of the static routes into BGP from VRF VPN1 advertises the CE subnet 10.0.68.0 to all other PE's via MP-BGP (normal MPLS-VPN operation). Similarly, the route to the 10.1.1.0 subnet behind PE2 is also learned by the VPN-GW1-EAST. Example 9-17 shows this. Example 9-17. Routes Learned via MP-BGP from Remote-PE on VPN-GW1-EAST
vpn-gw1-east#show ip bgp v v vpn1
BGP table version is 10, 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 153.1.1.1 0 100 0 ?
vpn-gw1-east#show ip cef vrf vpn1 10.1.1.0
10.1.1.0/24, version 21, epoch 0, cached adjacency 9.2.1.2
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Fa4/0, 9.2.1.2, tags imposed: {702 498}
via 153.1.1.1, 0 dependencies, recursive
next hop 9.2.1.2, FastEthernet4/0 via 153.1.1.1/32
valid cached adjacency
tag rewrite with Fa4/0, 9.2.1.2, tags imposed: {702 498}
| Step 7. | After ISAKMP SAs and IPSec SAs are established, traffic arriving from the CE can be decrypted and, in the return path, encrypted from the PE to the CE. For packets' ingress into the PE, the IPSec packet will be destined to the PE's FVRF IP address where the crypto map is applied.
A lookup in the IPSec security association database (SADB) table based on the 3-tuple of outer destination address, protocol, and SPI value, and the right security association (SA) is found in order to decrypt the packet. Once the packet is decrypted, it is mapped to the inside VRF-ID associated with the IPSec SA, as this association was made during IPSec SA establishment (show crypto ipsec sa). This means that once the packet is decrypted, the inside IP address destination lookup is done in the context of the IVRF. In this example, if traffic is destined to 10.1.1.0 subnet, the forwarding lookup for this subnet is done in the VRF VPN1.
| Step 8. | The forwarding lookup for 10.1.1.0 in VRF VPN1 is a success and, as per CEF entry for this subnet, MPLS labels are prepended to the IP packet and switched along the MPLS Label Switch Path (LSP) to the far-end PE2.
| Step 9. | At the far-end PE, the MPLS VPNv4 label is popped and the IP packet is forwarded to the subnet 10.1.1.0.
| Step 10. | On the return path, MPLS label imposition at the far-end PE gets the packet back to the IPSec aggregator PE (VPN-GW1-EAST). The VPN label (528, in this example) inserted by the far-end PE associates the packet with an outgoing interface of FastEthernet0/0 on VPN-GW1-EAST. Example 9-18 shows this. Example 9-18. CEF and LFIB Information for the Route Injected by Reverse Route
vpn-gw1-east#show ip cef vrf vpn1 10.0.68.0
10.0.68.0/24, version 6, epoch 0, cached adjacency 9.1.1.33
0 packets, 0 bytes
tag information set
local tag: 528
via 9.1.1.146, 0 dependencies, recursive
next hop 9.1.1.33, FastEthernet0/0 via 0.0.0.0/0
valid cached adjacency
tag rewrite with Fa0/0, 9.1.1.33, tags imposed: {}
vpn-gw1-east#show mpls forwarding-table vrf vpn1
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
528 Untagged 10.0.68.0/24[V] 0 Fa0/0 9.1.1.33
| Step 11. | Once the MPLS label is popped, the packet is switched out the outgoing interface (fa0/0)except in this case there is a crypto map on the outgoing interface. The encryption context for the outbound packet is determined by the combination of the IVRF and the 5-tuple value, which is source address, destination address, source port, destination port, and protocol. After the packet is encrypted and the appropriate tunnel header is added, the encrypted packet is routed once more. This time the route lookup table that is used is that of the FVRF-ID of the encrypting SA.
|
This concludes the packet processing for a branch site connecting to a PE over IPSec and mapping the site into an MPLS VPN.
Mapping an IPSec Tunnel from a Telecommuter into an IVRF at the PE
The general operation of mapping a remote telecommuter into an MPLS VPN is essentially the same as that of a branch site with the key difference being the "match" criteria for the ISAKMP profile. Matches based on the IP address will not work for the telecommuter scenario because the IP address of the telecommuter may not be known in advance. Alternate mechanisms need to be used to make the VRF association.
If the VPN client is using Aggressive Mode or EzVPN, the groupname configured on the clients is used as the ID_KEY_ID. Based on the groupname, the key and attributes are downloaded locally from the PE or from a radius server and are used to map the VPN client to a VRF. In this section, you'll take a step-by-step look at the packet flow for this case. Refer to Figure 9-4 for this discussion.
Step 1. | IPSec policy configuration on the VPN client on the telecommuter triggers IKE packet destined to the IPSec PE (VPN-GW1-EAST).
| Step 2. | The IKE packet from the CE is received on VPN-GW1-EAST's FastEthernet0/0 interface.
| Step 2.1. | Crypto configuration on the interface triggers IKE phase 1 processing. The relevant portions of the configuration from VPN-GW1-EAST and the debug output for this step are shown in Example 9-19. Example 9-19. Configuration Snippet and Debug Output for Aggressive Mode IKE
interface FastEthernet0/0
description FVRF
ip address 9.1.1.35 255.255.255.248
duplex full
random-detect
crypto map vpn
00:13:32: ISAKMP (0:0): received packet from 9.1.1.154 dport 500 sport 500 Global (N)
NEW SA
| Step 2.2. | As you saw in Chapter 2, "IPSec Overview," IKE Aggressive Mode processing consists of three messages between the initiator and the responder. We won't go through all the messages; the debug output clearly shows the sequence of the messages and the IKE state changes.
|
One of the first steps in Aggressive Mode by the responder (VPN-GW1-EAST) is to check if there is an ID _KEY_ID in the identification payload which, in this example, is the groupname configured on the client (vpn 1 group). The groupname associates the client to the ISAKMP profile, which in turn maps the AAA options and points to the radius server to be used for downloading the keys for authenticating message two and three of Aggressive Mode. Example 9-20 shows the debug ouput for this step.
Example 9-20. Debug Output for Aggressive Mode IKEStep 2.2
vpn-gw1-east# debug crypto isakmp sa
00:13:32: ISAKMP (0:0): ID payload
next-payload : 13
type : 11
group id : vpn1group
protocol : 17
port : 0
length : 12
00:13:32: ISAKMP:(0:0:N/A:0):: peer matches vpn1-ra profile
aaa authentication login vpn group radius
aaa authorization network vpn group radius
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
radius-server host 100.1.1.4 auth-port 1645 acct-port 1646
radius-server key cisco
Step 2.3. | After this check passes, the key is downloaded from a RADIUS server and processing of Aggressive Mode's second and third message continues.
| Step 3. | At the end of Step 2.3, IKE SAs are established and the ISAKMP profile is known from Step 2.2, which associates the client with the appropriate IVRF. X-AUTH and MODE-CFG processing is complete at the end of this step, as shown in Example 9-21. Example 9-21. Association of the Client with IVRFStep 3
vpn-gw1-east#sh crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1 9.1.1.35 9.1.1.154 vpn1 ACTIVE 3des sha 2 23:51:08 CDX
| Step 4. | IKE Phase 2 (also known as Quick Mode) processing starts for IPSec SA establishment. Example 9-22 shows the relevant configuration and debug output. Example 9-22. Relevant Configuration and Debug Output for IPSec SA establishmentStep 4
crypto ipsec transform-set vpn1 esp-3des esp-sha-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 3 ipsec-isakmp dynamic dynamic
vpn-gw1-east#show cry ipsec sa
interface: FastEthernet0/0
Crypto map tag: vpn-map, local addr 9.1.1.35
protected vrf: vpn1
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (10.254.254.201/255.255.255.255/0/0)
current_peer 9.1.1.154 port 500
PERMIT, flags={}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 9.1.1.35, remote crypto endpt.: 9.1.1.154
path mtu 1500, ip mtu 1500
current outbound spi: 0xD046BD03(3494296835)
inbound esp sas:
spi: 0xA5C427BD(2781095869)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3001, flow_id: SW:1, crypto map: vpn-map
sa timing: remaining key lifetime (k/sec): (4415994/3562)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xD046BD03(3494296835)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3002, flow_id: SW:2, crypto map: vpn-map
sa timing: remaining key lifetime (k/sec): (4415994/3560)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
vpn-gw1-east#debug crypto ipsec
00:50:02: ISAKMP:(0:1:SW:1):Checking IPSec proposal 1
00:50:02: ISAKMP: transform 1, ESP_3DES
00:50:02: ISAKMP: attributes in transform:
00:50:02: ISAKMP: encaps is 1 (Tunnel)
00:50:02: ISAKMP: SA life type in seconds
00:50:02: ISAKMP: SA life duration (VPI) of 0x0 0x20 0xC4 0x9B
00:50:02: ISAKMP: SA life type in kilobytes
00:50:02: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
00:50:02: ISAKMP: authenticator is HMAC-SHA
00:50:02: ISAKMP:(0:1:SW:1):atts are acceptable.
00:50:02: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 9.1.1.35, remote= 9.1.1.154,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 10.254.254.201/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x2
00:50:02: ISAKMP:(0:1:SW:1): processing NONCE payload. message ID = -1537648483
00:50:02: ISAKMP:(0:1:SW:1): processing ID payload. message ID = -1537648483
00:50:02: ISAKMP:(0:1:SW:1): processing ID payload. message ID = -1537648483
00:50:02: ISAKMP:(0:1:SW:1): asking for 1 spis from ipsec
00:50:02: ISAKMP:(0:1:SW:1): Creating IPSec SAs
00:50:02: inbound SA from 9.1.1.154 to 9.1.1.35 (f/i) 0/ 1
(proxy 10.254.254.201 to 0.0.0.0)
00:50:02: has spi 0xA5C427BD and conn_id 0 and flags 2
00:50:02: lifetime of 2147483 seconds
00:50:02: lifetime of 4608000 kilobytes
00:50:02: has client flags 0x0
00:50:02: outbound SA from 9.1.1.35 to 9.1.1.154 (f/i) 0/1
(proxy 0.0.0.0 to 10.254.254.201)
00:50:02: has spi -800670461 and conn_id 0 and flags A
00:50:02: lifetime of 2147483 seconds
00:50:02: lifetime of 4608000 kilobytes
00:50:02: has client flags 0x0
00:50:02: ISAKMP:(0:1:SW:1): sending packet to 9.1.1.154 my_port 500 peer_port 500 (R)
QM_IDLE
00:50:02: ISAKMP:(0:1:SW:1):Node -1537648483, Input = IKE_MESG_FROM_IPSEC,
IKE_SPI_REPLY
00:50:02: ISAKMP:(0:1:SW:1):Old State = IKE_QM_SPI_STARVE New State = IKE_QM_R_QM2
00:50:02: IPSEC(key_engine): got a queue event with 2 kei messages
00:50:02: IPSEC(initialize_sas): ,
(key eng. msg.) INBOUND local= 9.1.1.35, remote= 9.1.1.154,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 10.254.254.201/0.0.0.0/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 2147483s and 4608000kb,
spi= 0xA5C427BD(2781095869), conn_id= 0, keysize= 0, flags= 0x2
00:50:02: IPSEC(initialize_sas): ,
(key eng. msg.) OUTBOUND local= 9.1.1.35, remote= 9.1.1.154,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 10.254.254.201/0.0.0.0/0/0 (type=1),
protocol= ESP, transform= esp-3des esp-sha-hmac (Tunnel),
lifedur= 2147483s and 4608000kb,
spi= 0xD046BD03(3494296835), conn_id= 0, keysize= 0, flags= 0xA
00:50:02: IPSEC(rte_mgr): VPN Route Added 10.254.254.201 255.255.255.255 via 9.1.1.154
in vpn1
00:50:02: IPSEC(rte_mgr): VPN Peer Route Added 9.1.1.154 via 9.1.1.33 in vpn1
00:50:02: IPSEC(create_sa): sa created,
(sa) sa_dest= 9.1.1.35, sa_proto= 50,
sa_spi= 0xA5C427BD(2781095869),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 3001
00:50:02: IPSEC(create_sa): sa created,
(sa) sa_dest= 9.1.1.154, sa_proto= 50,
sa_spi= 0xD046BD03(3494296835),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 3002
| Step 5. | The packet flow sequence from this step onwards is the same as in the branch site terminating into the IPSec aggregator explained in the previous section.
|
If the telecommuter VPN client is using Main Mode, then one option is to use RSA-SIG with certificates. In the case of certificates, you can match fields in the certificate to bind the session to a VRF as shown in Example 9-23. The certificate map defined is 'foo'. Customer Premise Equipment (CPE) or clients that match on the OU=EAST and O=VPN1 fields in the certificate presented by them to VPN-GW1-EAST will be bound to VRF VPN1.
Example 9-23. Use of Certificates Fields to Match and Bind to a VRF
vpn-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 vpn1 group radius
aaa authorization network vpn1 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
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
!
crypto isakmp profile vpn1-ra
vrf vpn1
ca trustpoint vpn1
match certificate foo
client configuration group vpn1group
client authentication list vpn1
isakmp authorization list vpn1
client configuration address respond
accounting vpn
!
crypto ca certificate map foo
subject-name co ou=EAST
subject-name co o=VPN1
In case of remote access clients, you can also statically assign a group using the "client configuration group <groupname>" to support extended authentication [XAUTH] and Mode Configuration [MODE-CFG]. The primary use of this is in cases in which the group information used cannot be retrieved from the certificate and needs to be statically assigned to support X-AUTH.
Termination of IPSec on a Unique IP Address Per VRF
If an IPSec tunnel needs to terminate on a unique IP address per VPN on the aggregation PE router, a unique interface or sub-interface is needed in the FVRF. These can be either unique VLANs, ATM PVCs, or Frame Relay sub-interfaces on the same router. The primary motivation for a unique IP address per VPN for IPSec termination is for cases in which the IPSec spokes use Main Mode with pre-shared key authentication and are assigned IP addresses dynamically on the WAN interface. In this case, match identity based on IP address does not work; it is not known what the tunnel endpoint address will be. This is an inherent limitation of the IPSec protocol itself. To overcome the issue, a unique IP address and unique VRF is assigned per VPN customer.
Figure 9-5 illustrates this scenario and Example 9-24 shows the configuration of the aggregation PE.
[View full size image]
Example 9-24. Configuration on VPN-GW1-EAST Terminating each VPN on a Unique Interface to Support Wild Card Keys
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
!
crypto keyring vpn1 vrf vpn1
pre-shared-key address 0.0.0.0 key vpn1aes
crypto keyring vpn2 vrf vpn2
pre-shared-key address 0.0.0.0 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 0.0.0.0 0.0.0.0 vrf vpn1
!
crypto isakmp profile vpn2
vrf vpn2 description IVRF
keyring vpn2
match identity address 0.0.0.0 0.0.0.0 vrf vpn2
!
crypto ipsec transform-set vpn1 esp-3des esp-sha-hmac
crypto ipsec transform-set vpn2 esp-3des esp-md5-hmac
!
!
interface Loopback0
ip address 9.2.1.100 255.255.255.255
!
interface FastEthernet0/0.1
description FVRF
encapsulation dot1q 100
ip vrf forwarding vpn1
ip address 9.1.1.35 255.255.255.252
duplex full
random-detect
crypto map vpn1
!
interface FastEthernet0/0.2
description FVRF
encapsulation dot1q 101
ip vrf forwarding vpn1
ip address 9.1.1.37 255.255.255.252
duplex full
random-detect
crypto map vpn2
!
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
!
ip route vrf vpn1 0.0.0.0 0.0.0.0 9.1.1.36
ip route vrf vpn2 0.0.0.0 0.0.0.0 9.1.1.38
!
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
IPSec CPE and VPN clients for customers VPN1 and VPN2 are configured with two different tunnel endpoint addresses of the gateway, which in this case are 9.1.1.35 and 9.1.1.37, respectively. It is important to note that you should have a default route per VRF and the router that front ends the PE on FastEthernet 0/0 should also be configured with 802.1q-encapsulated sub-interfaces.
|
No comments:
Post a Comment