Entries Tagged as ''

ezRemeber ezVPN Configuration

When playing around Easy VPN server configuration, I felt it’s not straight forward to remember, especially from Cisco configuration guide. Later, I figured it out the way to remember those complicated configuration and very glad to share in here. Basically, the configuration is divided to 6 parts.

  1. Phase 1
  2. Phase 1.5
  3. Phase 2
  4. Dynamic-mapping
  5. Crypto-mapping
  6. Apply to the interface

Phase 1

IPSec Phase I configuration is the same as Lan to Lan (L2L) IPSec configuration. We need to define four basic parameters for crypto isakmp policy.

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

Compared to LAN to LAN IPSec, the ezVPN pre-shared key is defined in easy VPN group. The group name is ID and the pre-shared key is configured under the group settings using the command key <STRING>.

!
crypto isakmp client configuration group EZVPN
key CISCO
pool EZVPN
acl SPLIT_TUNNEL
!

However, I prefer to configure ezVPN group on Phase 1.5.

Phase 1.5

This so called phase 1.5 implements the special ISAKMP which allows the VPN client requests certain attribute values. Unlike L2L IPSec, which peers are specifically defined, the ezVPN client needs ezVPN Server to tell the attributes that clients request, such as IP address (pool), DNS Server, Split Tunnel and pre-shared key.

!
ip local pool EZVPN 172.22.0.1 172.22.0.254
!
ip access-list extended SPLIT_TUNNEL
permit ip 172.17.94.0 0.0.0.255 any
!
crypto isakmp client configuration address-pool local EZVPN
crypto isakmp client configuration group EZVPN
key CISCO
pool EZVPN
acl SPLIT_TUNNEL

Note that the per-shared key is only for Phase 1 authentication. Phase 1.5 still need authentication. ISAKMP configuration mode allows for Extended Authentication (Xauth) after the ISAKMP SA has been established. The Xauth is basically refer to AAA list in IOS.

aaa new-model
!
!
aaa authentication login CONSOLE none
aaa authentication login EZVPN local
aaa authorization network EZVPN local
!
username CISCO password 0 CISCO
!
crypto map VPN client authentication list EZVPN
crypto map VPN isakmp authorization list EZVPN

It’s interesting for me that the client authentication and isakmp authorization are actually happened on Phase 1.5, but the configuration is on the final crypto mapping.

Phase 2

The configuration is the same as L2L IPSec.

!
crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac

Dynamic Mapping

Before mapping crypto to isakmp-ipsec, we should create a dyanmic mapping to accept connections from any remote peer. This part is different with L2L IPSec which specify the peer address by match address <PEER ADDRESS>.

!
crypto dynamic-map DYNAMIC 10
set transform-set 3DES_MD5
reverse-route

To let router has knowledge of the remote end-point, it must has a route on the routing table for the end-point. After issuing reverse-route command, when ezVPN session is up, there is a static route stored in the routing table. To let the other routers has knowledge of ezVPN client, we can simply redistribute static to some dynamic routing protocal such as EIGRP or OSPF.

CRYPTO Mapping

We have defined two lines crypto mapping for authorization and authentication. We need finalize all crypto mappings. Let me summarize what crypto mapping does:

  1. client authentication and isakmp authorization.
  2. client address response.
  3. ipsec-isakmp dynamic mapping.

!
crypto map VPN client configuration address respond
crypto map VPN 10 ipsec-isakmp dynamic DYNAMIC

Apply to the Interface

!
interface FastEthernet0/0
crypto map VPN

ASA Static NAT Interface

When I am dealing with ASA Static NAT interface, I am wondering what’s the order of the interfaces in the bracket. For example, one scenario is to access inside server from global accessible IP address, then we have the following configuration:

static (inside, outside) 150.1.136.100 10.0.0.1

Another scenarios is to let inside desktop to access outside DNS server as inside accessible IP address, then, the interfaces in the bracket are swapped.

static (outside, inside) 10.0.0.100 150.1.136.200

I actually try to figure out why Cisco developer made that syntax, which is not intuitive. Anyway, after take a look Cisco reference, the better explaination is like this:

static (real_interface, mapped_interface) mapped_ip real_ip

So, based on that, the static NAT is much more clearly understanding.

Vulnerability Management Axioms

The article is coming from here. I quoted part of it because it’s useful when we design vulnerability management tools.

To get anywhere with vulnerability management, Northcutt said there are five things to consider first:

  1. Vulnerabilities are the gateways through which threats are manifested.
  2. Vulnerability scans without remediation have little value.
  3. A little scanning and remediation is better than a lot of scanning and less remediation.
  4. Vulnerabilities in need of fixing must be prioritized based on which ones post the most immediate risk to the network.
  5. Security practitioners need a process that will allow them to stay on the trail of vulnerabilities so the fixes can be more frequent and effective.