• EzVPN clients will get addresses on the 2.0.0.0/24 network
• EzVPN clients will have access to only the 3.0.0.0/24 network
• The server will accept clients with certificates from the CA on host 1.2.3.4
• The server will allow users with OU=EZVPN

aaa new-model
aaa authentication login EZ_AUTHEN local
aaa authorization network EZ_AUTHOR local
!
username cisco password cisco1234
!
clock timezone GMT 0
ntp server 1.2.3.4
!
crypto pki trustpoint CA
  enrollment url http://1.2.3.4
  subject-name ROUTER.example.com
  revocation-check none
!
crypto pki authenticate CA
crypto pki enroll CA
!
crypto isakmp policy 1
  encryption 3DES
  hash SHA
  authentication rsa-sig
  group 2
!
crypto isakmp identity dn
!
ip local pool EZ_POOL 2.0.0.1 2.0.0.254
!
ip access-list extended EZ_ROUTES
  permit 3.0.0.0 0.0.0.255
!
crypto isakmp client configuration group EZVPN
  pool EZ_POOL
  acl EZ_ROUTES
!
crypto isakmp profile EZ_PROFILE
  match identity group EZVPN
  client authentication list EZ_AUTHEN
  isakmp authorization list EZ_AUTHOR
  client configuration address respond
  virtual-template 1
!
crypto ipsec transform-set 3DES_SHA esp-3des esp-sha-hmac
!
crypto ipsec profile EZ_IPSEC_PROFILE
  set transform-set 3DES_SHA
  set isakmp-profile EZ_PROFILE
!
interface Virtual-Template 1 type tunnel
  ip unnumbered FastEthernet0/1
  tunnel mode ipsec ipv4
  tunnel protection ipsec profile EZ_IPSEC_PROFILE
!

While working through a CCIE Security practice lab, I came across a task that read (in essence): “Only allow SSH and SNMP access to the router through interface Gig0/1.  Do not use an interface or VTY ACL to accomplish this.”   A search through the IOS configuration guides and command references was unhelpful, including the last-resort tactic of “go to the Master Index and use Ctrl-F to search for likely keywords.”  Finally, I resorted to asking on GroupStudy.  Within minutes, the answer came back:  use management-plane protection.  What on earth is that?  To quote Cisco:

The Management Plane Protection (MPP) feature in Cisco IOS software provides the capability to restrict the interfaces on which network management packets are allowed to enter a device. The MPP feature allows a network operator to designate one or more router interfaces as management interfaces. Device management traffic is permitted to enter a device only through these management interfaces. After MPP is enabled, no interfaces except designated management interfaces will accept network management traffic destined to the device.

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecmpp.html

This feature was added in 12.4(6)T but only seems to be documented under Feature Guides, not in the main IOS command reference or configuration guides.  Gee, thanks Cisco!

A configuration example (based on the practice lab task above):

control-plane host
  management-interface GigabitEthernet0/1 allow ssh snmp
end

When this configuration is applied to the router (assuming SSH has been previously configured), remote SSH and SNMP connections to the router will only be accepted when entering through Gi0/1.  This is based on the interface, not on the IP address.  SSH and SNMP connections to Gi0/1′s IP address entering through other interfaces will fail.  In addition, other management traffic (telnet, etc.) entering through Gi0/1 will also fail.  The complete list of what IOS considers management traffic is:

• SSH v1 and v2
• telnet
• HTTP / HTTPS
• FTP
• SNMP (all version)
• TFTP
• BEEP (Blocks Extensible Exchange Protocol)

Note that other traffic destined for the router (such as routing protocols and ARP) are not affected, nor is traffic routed through the management interface.  This is different from the management-interface functionality on an ASA, where the designated port can only be used for management traffic.

In summary, it is quite annoying that Cisco doesn’t seem to have actually documented this feature properly, since it has the potential to be a very useful tool in the network administrator’s toolbox.  Depending on the network design, enabling MPP makes it less likely that a management protocol becomes accessible on an interface connected to a hostile network, while simplifying interface ACLs needed to properly secure the device.