Full-crypto VPN hardware client configuration for Cisco EzVPN

This article explains the VPN hardware client configuration that will support a full-crypto peering relationship for Cisco's EzVPN IPsec gateway.

This Content Component encountered an error

In the last article in our series on building router-based VPN gateways, we learned how to support network-to-network IPsec VPN topologies by building a gateway with Cisco EzVPN. Now we'll move on to the hardware client configuration that will support a full-crypto peering relationship for the EzVPN gateway.

The typical hardware client device build has four configuration elements: the DHCP/DNS server configuration, the hardware client configuration, the interface configuration, and the IP routing configuration.

Unlike other IOS IPsec configurations, the hardware client requires no ISAKMP policy, transform set or crypto map definition. Only the client configuration is needed to establish the IPsec link with the gateway. Hardware client configurations utilize "built-in" ISAKMP and transform set definitions. EzVPN supports 20 different ISAKMP policies utilizing AES, DES, 3DES for encryption and SHA and MD5 for authentication, but only supports Diffie-Hellman Group 2 (1024-bit) key lengths. This gives administrators flexibility in terms of encryption and authentication, but DH Group 2 must be used or ISAKMP Phase 1 negotiation will fail.

 
Read our entire series of step-by-step articles on building Cisco IPsec VPNs

 Transform set support also offers diverse authentication and encryption selection, with minor restrictions. This translates to only transform sets that support ESP with encryption and authentication being available. That means there is no AH support, and no transform sets using ESP with encryption and without authentication, or ESP with authentication and without encryption can be configured on the VPN gateway, at least if you expect to have a successful Phase 2 negotiations. The VPN gateway configuration in the previous article takes these rules into account, but a number of other ISAKMP and transform set configurations can be implemented and supported by the hardware client. Now on to the client configuration:

I. DHCP/DNS services configuration
With an EZ-NEM remote office configuration, the router (or the LAN routing switch) is typically configured to provide DHCP and DNS services. Alternatively a local server could be configured to provide these services. But the idea with this type of solution is to consolidate services to make support and replacement (if needed) easy. Here is the basic configuration for two directly connected networks' DHCP scopes and DNS proxy services with the core DNS server (172.30.40.101) and four Internet root DNS server definitions:

 

 outlan-VPN-RTR(config)#ip dhcp pool vlan-100 outlan-VPN-RTR(dhcp-config)#network 172.30.100.0 255.255.255.0 outlan-VPN-RTR(dhcp-config)#default-router 172.30.100.1 outlan-VPN-RTR(dhcp-config)#dns-server 1.1.1.1 outlan-VPN-RTR(dhcp-config)#domain-name usr.outlan.net outlan-VPN-RTR(dhcp-config)#exit outlan-VPN-RTR(config)#ip dhcp excluded-address 172.30.100.1 outlan-VPN-RTR(config)#ip dhcp pool vlan-120 outlan-VPN-RTR(dhcp-config)#network 172.30.120.0 255.255.255.0 outlan-VPN-RTR(dhcp-config)#default-router 172.30.100.1 outlan-VPN-RTR(dhcp-config)#dns-server 1.1.1.1 outlan-VPN-RTR(dhcp-config)#domain-name usr.outlan.net outlan-VPN-RTR(dhcp-config)#exit outlan-VPN-RTR(config)# ip dhcp excluded-address 172.30.120.1 outlan-VPN-RTR(config)#ip domain-name outlan.net outlan-VPN-RTR(config)#ip dns server outlan-VPN-RTR(config)#ip name-server 172.30.40.101 outlan-VPN-RTR(config)#ip name-server 192.36.148.17 outlan-VPN-RTR(config)#ip name-server 192.112.36.4 outlan-VPN-RTR(config)#ip name-server 193.0.14.129 outlan-VPN-RTR(config)#ip name-server 198.32.64.12

II. Hardware client configuration
The hardware client definition follows a format quite similar to the software client definition. The basic client definition requires the following attributes:

 

  1. EzVPN client connection definition name is set with the command <crypto ipsec client ezvpn {client name}>
  2. ISAKMP group authentication is set with the command <group {group-name} key {key string}>
  3. Connection mode definition, for full-time remote location connections, is set with the command <connect {auto | manual | acl {acl}}>
  4. Client mode definition is set with the command <mode {client network-extension}>
  5. Host (peer) definition allows multiple definitions to be defined. The client connects to the peers in descending order and is set with the command <peer {ip address | hostname}>
  6. XAUTH user and password definition is set with the command <username {name} password {passwd}>
  7. XAUTH authentication trigger definition sets up the authentication process. Once the connection has been triggered, the XAUTH credentials need to be sent. This is set with the command <xauth userid mode {interactive | http-intercept | local}>

    Below is a syntax example detailing the hardware client connection definition configuration:

     

     outlan-VPN-RTR(config)#crypto ipsec client ezvpn hard-client outlan-VPN-RTR(config-crypto-ezvpn)#connect auto outlan-VPN-RTR(config-crypto-ezvpn)#group hard-client-fc key supersecret outlan-VPN-RTR(config-crypto-ezvpn)#username outlan-rtr1 password outlan-rtr1 outlan-VPN-RTR(config-crypto-ezvpn)#xauth userid mode local outlan-VPN-RTR(config-crypto-ezvpn)#mode network-extension outlan-VPN-RTR(config-crypto-ezvpn)#peer 190.55.2.98 outlan-VPN-RTR(config-crypto-ezvpn)#peer 45.240.90.194
    

     

  8. Traffic qualifier ACL is an optional client definition for use in scenarios in which the hardware client router does not have directly connected interfaces on all of the IP subnets that must be secured. The client hardware has a provision for including such subnets using a traffic qualifier ACL. The ACL follows the same format that a "gateway" traffic ACL uses: Local Network -> Remote Network (any), where the local networks are those adjacent to the hardware client router and the remote networks are reachable through the VPN gateway. Here is the ACL for our example network:

     

     outlan-VPN-RTR(config)#access-list 140 permit ip 172.30.89.0 0.0.0.255 any outlan-VPN-RTR(config)#access-list 140 permit ip 172.30.62.0 0.0.0.255 any
    

    Once the ACL is defined, it is referenced within the client definition using client configuration sub-command <acl {acl name}>.

III. Interface creation and designation
With the hardware client profile definition in place, next we must configure the interface addressing and local subnet crypto client designations. Like NAT, the hardware client interface configuration uses "inside" and "outside" designations. There can be only one outside interface and there must be at least one inside interface in order for the policy to be enabled:

 

 outlan-VPN-RTR(config)#ip access-list extended VPN-IN outlan-VPN-RTR(config-ext-nacl)# remark permit DHCP Client Traffic outlan-VPN-RTR(config-ext-nacl)# permit udp any any eq bootpc outlan-VPN-RTR(config-ext-nacl)# remark permit IPSEC Phase 1 Phase 2 traffic outlan-VPN-RTR(config-ext-nacl)# permit esp host 190.55.2.98 any outlan-VPN-RTR(config-ext-nacl)# permit udp host 190.55.2.98 any eq isakmp outlan-VPN-RTR(config-ext-nacl)# permit esp host 45.240.90.194 any outlan-VPN-RTR(config-ext-nacl)# permit udp host 45.240.90.194 any eq isakmp outlan-VPN-RTR(config-ext-nacl)#exit outlan-VPN-RTR(config)# interface FastEthernet0/0 outlan-VPN-RTR(config-if)#ip address dhcp outlan-VPN-RTR(config-if)#ip access-group VPN-IN in outlan-VPN-RTR(config-if)#crypto ipsec client ezvpn hard-client outside outlan-VPN-RTR(config-if)#exit outlan-VPN-RTR(config)# interface Vlan100 outlan-VPN-RTR(config-if)#ip address 172.30.100.1 255.255.255.0 outlan-VPN-RTR(config-if)#crypto ipsec client ezvpn hard-client inside outlan-VPN-RTR(config-if)#exit outlan-VPN-RTR(config)# interface Vlan120 outlan-VPN-RTR(config-if)#ip address 172.30.120.1 255.255.255.0 outlan-VPN-RTR(config-if)#crypto ipsec client ezvpn hard-client inside outlan-VPN-RTR(config-if)#exit

IV. IP routing configuration
The routing configuration for this example is very simple. There is no default route configuration, because the outside interface is configured with DHCP and the default route will be provided as part of the DHCP lease from the ISP. For aesthetic purposes we could set the DR to the physical interface Fa0/0, but it is not required. It's also simple because all traffic to one of the inside interfaces is encrypted and sent to the VPN gateway. We do, however, need to provide some routing logic for the adjacent subnets that the client will also be securing. This can be handled with some static routes:

 

 outlan-VPN-RTR(config)# ip route 172.30.62.0 255.255.255.0 1.1.1.254 outlan-VPN-RTR(config)# ip route 172.30.89.0 255.255.255.0 1.1.1.254

With "connect auto" set in the hardware client profile, the client will open negotiations with the VPN gateway as soon as the interface designations have been set and the interfaces are up. If you have been building along on your own network, your client and VPN gateway should now be connected and able to pass secured traffic.

 That wraps up the full-crypto client configuration. To find out about split tunneling with the hardware client, you'll need to read the next article. For more on that and our other step-by-step information on Cisco IOS IPsec VPN configuration, go to the main page of this series.

This was first published in September 2008

Dig deeper on VPN design

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close