Posts Tagged ‘vrf’
Although the CCIE Security lab still has old IOS 12.2T installed on all routers, it’s more convenient to discuss ezVPN technology using the approach prompted by recent IOS releases. Specifically, for our purposes we will utilize the feature known as VTI (Virtual Tunnel Interface) to simplify IPsec configurations a great deal of times.
In this post we are going to combine two powerful technologies in order to provide an effective security solution, particularly suitable for large enterprises. The first technology is known as “VRF-lite”. In short, it allows separating a physical router into a number of virtual routers. Essentially, each virtual router has it’s own routing table, distinguished from others by using a special Routing Distinguisher (RD) which is a 64bit integer, usually represented as “X:Y”. Inside a router you need to configure interfaces belonging to particular VRF and enable VRF-specific routing processes. The real power of VRF-lite comes to hand when you need to share the same device between isolated groups of users – e.g. “Sales” and “Customer Support”.
Easy VPN (ezVPN) is well known Client-Server VPN technology based on IPsec. Originally, IPsec was a peer-to-peer technology, where configurations are basically symmetrical on both ends of an IPsec tunnel. The idea of ezVPN is to make client configuration as simple as possible, while putting additional configuration on the server. To recap, recall that IPsec utilizes two phases secures “connection” establishment process: Phase 1 – ISAKMP SA (management channel) and Phase 2 – IPsec SA (protect user data). In order to avoid excessive configuration on client side, additional ISAKMP SA Phase has been introduced – Phase 1.5. The purpose of this phase is to push configuration information to the client and perform additional name-based authentication (Xauth – extended authentication).
With ezVPN, secure connection establishment looks like following:
Phase 1: Client contacts server, sends it’s identifier (group name) either using ISAKMP Aggressive Mode, or certificate exchange
Phase 1.5: Based on group configuration, server may initiate additional authentication process (called Xauth) to verify user identity. After successful authentication, client sends a Configuration Request. With group and authenticated username on hand, server may then query local database or remote AAA server (e.g. RADIUS) for configuration information, which usually includes client VPN IP address, Split-Tunnel ACL, DNS/WINS servers etc.
Phase 2: Client obtains it’s new IP address and other additional information and then tries to establish IPsec SA based on Split-Tunnel ACL (which specifies traffic to be encrypted) and new VPN IP address. Essentially, split-tunnel ACL is used to create Proxy-Identifiers for Phase 2. As connection is established, server may create a static route, corresponding to the client VPN IP address using process know as Reverse Route Injection (RRI).
ezVPN has two general modes of operation. The first is known as “Client-mode”: Server allocates new IP address and pushes it’s down to a client. If the client is a router (feature known as ezVPN Remote), then a special NAT rule is installed automatically to translate “inside” users traffic into the VPN IP address using PAT. The second mode of operations is known as “Network-Extension”. Using this mode, client does not request a new IP address, but rather uses it’s inside interface network to build the Phase 2 IPsec SA (proxy ID). This is more similar to classic IPsec VPN tunnel, with added functionality – such as user authentication, DNS servers auto-configuration (could be imported in DHCP pools), etc.
Let’s proceed to an example. First thing you need to do – enable AAA and create AAA lists tailored for ezVPN purposes. In this example we use local authentication and authorization, but you can perform RADIUS authorization as well, to pull user-specific attributes. Don’t forget to configure the default authentication and authorization lists, or you can easily get yourself locked out of the router you configure.
aaa new-model aaa authentication login default local aaa authorization network default local ! aaa authentication login AUTH_EZVPN local aaa authorization network AUTHOR_EZVPN local
Create a new VRF to isolate VPN users and add an interface into this VRF (to simulate a target network in the VPN).
ip vrf VRF_EZVPN rd 1:100 ! interface Loopback0 ip vrf forwarding VRF_EZVPN ip address 10.0.0.1 255.255.255.0
Configure global ISAKMP policy. Remember, you need DH group 2 for ezVPN clients:
crypto isakmp policy 10 authentication pre-share group 2 encryption 3des
ezVPN group policy configuration comes after that. Group name should match the name used by clients (it could be either specified directly or extracted from the “ou” field of DN in the x.509 certificate. Advanced scenarios could use X.509 ACLs DN fields matching). The least amount of information should include an authentication key (group-wide), address-pool (for Client mode) and a split-tunnel ACL (a good idea to use this one almost all the times). There is a bunch of other fancy options, but these are the bare minimum that should be configured for any scenario.
crypto isakmp client configuration group GROUP_EZVPN key CISCO pool POOL_EZVPN acl ACL_EZVPN
ISAKMP profile specifies IPsec “Phase 1/Phase 1.5” settings for a particular session. It is a must to configure the match option for an ISAKMP profile, to define the scope of the configuration. For ezVPN configuration it’s common to match the group name for VPN connection. Attributes to be specified under ISAKMP profile include the following: “isakmp authorization list” (the source of group policy – local or remote), “client authentication list” (the AAA list to authenticate client with) and “client configuration group” (group-policy for matching clients). Pay attention to “virtual-template” keyword, which defines a virtual interface used to clone the tunnels for connecting users (this is the feature called VTI – virtual tunnel interface).
crypto isakmp profile ISAKMP_PROFILE_EZVPN match identity group GROUP_EZVPN isakmp authorization list AUTHOR_EZVPN client authentication list AUTH_EZVPN client configuration address respond client configuration group GROUP_EZVPN virtual-template 1
The next few lines specify Phase 2 policy: encryption method and IPsec profile. The purpose of the IPsec profile is to group all Phase 2 settings and apply them to a particular IPsec tunnel interface. The IPsec tunnel interface, in turn, determines the identities of protected objects – source and destination subnets. In our case it’s a dynamic interface, but you can use regular tunnels for point-to-point connections. With Virtual-Template interface intuitive syntax, client IP address will be assigned automatically and later protected by the IPsec profile. Note the VRF setting under the virtual interface, which is a configuration to bring the connecting users into the VRF.
crypto ipsec transform-set TS_3DES_SHA esp-3des esp-sha-hmac crypto ipsec profile IPSEC_PROFILE_EZVPN set transform-set TS_3DES_SHA set isakmp-profile ISAKMP_PROFILE_EZVPN interface Virtual-Template1 type tunnel ip unnumbered Loopback0 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC_PROFILE_EZVPN ip vrf forwarding VRF_EZVPN
The last remaining things to configure are the address pool (referenced by the group policy) and the split tunnel ACL (which specifies the protected networks).
ip local pool POOL_EZVPN 10.0.0.1 10.0.0.254 ip access-list ext ACL_EZVPN permit ip 172.16.2.0 0.0.0.255 any
After all the above things have been configured, perform a test run. Configure a Cisco VPN client to connect to the server, and initiate the session, with the following debugs enabled in the server.