Easy VPN Combined with VRF Lite
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-hmaccrypto ipsec profile IPSEC_PROFILE_EZVPN
set transform-set TS_3DES_SHA
set isakmp-profile ISAKMP_PROFILE_EZVPNinterface 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.254ip 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.
AS#debug crypto isakmp
Crypto ISAKMP debugging is on
AS#debug crypto ipsec
Crypto IPSEC debugging is on
AS#terminal monitor
!
! The debugging output starts with information about
! the client IP address and client group name (ISAKMP ID)
!
ISAKMP (0:0): received packet from 70.212.234.119 dport 500 sport 500 Global (N) NEW SA
ISAKMP: Created a peer struct for 70.212.234.119, peer port 500
ISAKMP: New peer created peer = 0x672A515C peer_handle = 0x80000018
ISAKMP: Locking peer struct 0x672A515C, refcount 1 for crypto_isakmp_process_block
ISAKMP:(0):Setting client config settings 676ECD94
ISAKMP/xauth: initializing AAA request
ISAKMP: local port 500, remote port 500
insert sa successfully sa = 6776ECA8
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing ID payload. message ID = 0
ISAKMP (0:0): ID payload
next-payload : 13
type : 11
group id : GROUP_VORACK11
protocol : 17
port : 500
length : 22
!
! The client ID matches the ISAKMP profile configured
! The profile bind the actual group policy to the connecting client
!ISAKMP:(0):: peer matches ISAKMP_PROFILE_VORACK11 profile
ISAKMP:(0):(Re)Setting client xauth list and state
ISAKMP/xauth: initializing AAA request
ISAKMP:(0): Profile ISAKMP_PROFILE_VORACK11 assigned peer the group named GROUP_VORACK11
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 215 mismatch
ISAKMP:(0): vendor ID is XAUTH
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is DPD
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 194 mismatch
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch
ISAKMP:(0): vendor ID is NAT-T v2
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is Unity!
! The server is going to request Xauth from the client
!ISAKMP:(0): Authentication by xauth preshared
!
! Matching the offered proposals against the configured policy
! If you don’t see a match here (“no matching proposals” for all offers)
! that means you need to adjust your server policy to match clientt’s
!ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption AES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP: keylength of 256.......
ISAKMP:(0):Checking ISAKMP transform 9 against priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(0):Hash algorithm offered does not match policy!
ISAKMP:(0):atts are not acceptable. Next payload is 3
ISAKMP:(0):Checking ISAKMP transform 10 against priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B!
! The keywords are “atts are acceptable” – means match is found
!ISAKMP:(0):atts are acceptable. Next payload is 3
ISAKMP:(0):Acceptable atts:actual life: 86400
ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:2147483
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0): vendor ID is NAT-T v2
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
ISAKMP:(0):Old State = IKE_READY New State = IKE_R_AM_AAA_AWAIT!
! Sending our own ID to the client. Using our IP address as identifier
! Authentication type is set to PSK + Xauth
!ISAKMP:(1034): constructed NAT-T vendor-02 ID
ISAKMP:(1034):SA is doing pre-shared key authentication plus XAUTH using id type ID_IPV4_ADDR
ISAKMP (0:1034): ID payload
next-payload : 10
type : 1
address : 24.176.176.130
protocol : 17
port : 0
length : 12
ISAKMP:(1034):Total payload length: 12
ISAKMP:(1034): sending packet to 70.212.234.119 my_port 500 peer_port 500 (R) AG_INIT_EXCH
ISAKMP:(1034):Sending an IKE IPv4 Packet.
ISAKMP:(1034):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
ISAKMP:(1034):Old State = IKE_R_AM_AAA_AWAIT New State = IKE_R_AM2ISAKMP (0:1034): received packet from 70.212.234.119 dport 500 sport 500 Global (R) AG_INIT_EXCH
ISAKMP:(1034): processing HASH payload. message ID = 0
ISAKMP:(1034): processing NOTIFY INITIAL_CONTACT protocol 1
spi 0, message ID = 0, sa = 6776ECA8
ISAKMP:received payload type 20
ISAKMP:received payload type 20!
! At this moment, ISAKMP SA has been authenticated (group password [pre-shared key] matched)
!ISAKMP:(1034):SA authentication status:
authenticated
ISAKMP:(1034):SA has been authenticated with 70.212.234.119
ISAKMP:(1034):SA authentication status:
authenticated
ISAKMP:(1034): Process initial contact,
bring down existing phase 1 and 2 SA's with local 24.176.176.130 remote 70.212.234.119 remote port 500
ISAKMP:(1034):returning IP addr to the address pool
ISAKMP: Trying to insert a peer 24.176.176.130/70.212.234.119/500/, and inserted successfully 672A515C.
ISAKMP:(1034):Returning Actual lifetime: 86400
ISAKMP: set new node -69603564 to CONF_XAUTH
ISAKMP:(1034):Sending NOTIFY RESPONDER_LIFETIME protocol 1
spi 1720591952, message ID = -69603564
ISAKMP:(1034): sending packet to 70.212.234.119 my_port 500 peer_port 500 (R) QM_IDLE
ISAKMP:(1034):Sending an IKE IPv4 Packet.
ISAKMP:(1034):purging node -69603564
ISAKMP: Sending phase 1 responder lifetime 86400ISAKMP:(1034):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
ISAKMP:(1034):Old State = IKE_R_AM2 New State = IKE_P1_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)!
! Need additional authentication, notify the client
!ISAKMP:(1034):Need XAUTH
ISAKMP: set new node -911851146 to CONF_XAUTH
ISAKMP/xauth: request attribute XAUTH_USER_NAME_V2
ISAKMP/xauth: request attribute XAUTH_USER_PASSWORD_V2
ISAKMP:(1034): initiating peer config to 70.212.234.119. ID = -911851146!
! Send CONF_XAUTH message to the client
!ISAKMP:(1034): sending packet to 70.212.234.119 my_port 500 peer_port 500 (R) CONF_XAUTH
ISAKMP:(1034):Sending an IKE IPv4 Packet.
ISAKMP:(1034):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1034):Old State = IKE_P1_COMPLETE New State = IKE_XAUTH_REQ_SENTISAKMP (0:1034): received packet from 70.212.234.119 dport 500 sport 500 Global (R) CONF_XAUTH
ISAKMP:(1034):processing transaction payload from 70.212.234.119. message ID = -911851146!
! Authentication response from the client: name/password
!ISAKMP: Config payload REPLY
ISAKMP/xauth: reply attribute XAUTH_USER_NAME_V2
ISAKMP/xauth: reply attribute XAUTH_USER_PASSWORD_V2
ISAKMP:(1034):deleting node -911851146 error FALSE reason "Done with xauth request/reply exchange"
ISAKMP:(1034):Input = IKE_MESG_FROM_PEER, IKE_CFG_REPLY
ISAKMP:(1034):Old State = IKE_XAUTH_REQ_SENT New State = IKE_XAUTH_AAA_CONT_LOGIN_AWAITISAKMP: set new node -51939905 to CONF_XAUTH
ISAKMP:(1034): initiating peer config to 70.212.234.119. ID = -51939905
ISAKMP:(1034): sending packet to 70.212.234.119 my_port 500 peer_port 500 (R) CONF_XAUTH
ISAKMP:(1034):Sending an IKE IPv4 Packet.
ISAKMP:(1034):Input = IKE_MESG_FROM_AAA, IKE_AAA_CONT_LOGIN
ISAKMP:(1034):Old State = IKE_XAUTH_AAA_CONT_LOGIN_AWAIT New State = IKE_XAUTH_SET_SENTISAKMP (0:1034): received packet from 70.212.234.119 dport 500 sport 500 Global (R) CONF_XAUTH
ISAKMP:(1034):processing transaction payload from 70.212.234.119. message ID = -51939905!
! The client confirms XAUTH phase
!ISAKMP: Config payload ACK
ISAKMP:(1034): (blank) XAUTH ACK Processed
ISAKMP:(1034):deleting node -51939905 error FALSE reason "Transaction mode done"
ISAKMP:(1034):Talking to a Unity Client
ISAKMP:(1034):Input = IKE_MESG_FROM_PEER, IKE_CFG_ACK
ISAKMP:(1034):Old State = IKE_XAUTH_SET_SENT New State = IKE_P1_COMPLETEISAKMP:(1034):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1034):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)
ISAKMP:(1034):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1034):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETEISAKMP (0:1034): received packet from 70.212.234.119 dport 500 sport 500 Global (R) QM_IDLE
ISAKMP: set new node 1273658318 to QM_IDLE!
! The Client requests configuration information from the server
! Simply speaking this is just a list of attributes client wants values for
!ISAKMP:(1034):processing transaction payload from 70.212.234.119. message ID = 1273658318
ISAKMP: Config payload REQUEST
ISAKMP:(1034):checking request:
ISAKMP: IP4_ADDRESS
ISAKMP: IP4_NETMASK
ISAKMP: IP4_DNS
ISAKMP: IP4_NBNS
ISAKMP: ADDRESS_EXPIRY
ISAKMP: MODECFG_BANNER
ISAKMP: MODECFG_SAVEPWD
ISAKMP: DEFAULT_DOMAIN
ISAKMP: SPLIT_INCLUDE
ISAKMP: SPLIT_DNS
ISAKMP: PFS
ISAKMP: BACKUP_SERVER
ISAKMP: APPLICATION_VERSION
ISAKMP: FW_RECORD
ISAKMP: MODECFG_HOSTNAME
ISAKMP: CONFIG_MODE_UNKNOWN Unknown Attr: 0x7005!
! Using “GROUP_VORACK1” for authorization (obtaining attribute values)
!ISAKMP/author: Author request for group
GROUP_VORACK11successfully sent to AAA
ISAKMP:(1034):Input = IKE_MESG_FROM_PEER, IKE_CFG_REQUEST
ISAKMP:(1034):Old State = IKE_P1_COMPLETE New State = IKE_CONFIG_AUTHOR_AAA_AWAIT!
! A list of values for the requested attributes to send to the client
!ISAKMP:(1034):attributes sent in message:
Address: 0.2.0.0
ISAKMP:(1034):allocating address 10.0.0.6
ISAKMP: Sending private address: 10.0.0.6
ISAKMP: Sending subnet mask: 255.255.255.0
ISAKMP: Sending ADDRESS_EXPIRY seconds left to use the address: 86395
ISAKMP: Sending save password reply value 0!
! Split ACL to be used at Phase 2 negotiation
!ISAKMP: Sending split include name ACL_VORACK network 177.0.0.0 mask 255.0.0.0 protocol 0, src port 0, dst port 0
ISAKMP: Sending APPLICATION_VERSION string: Cisco IOS Software, 2801 Software (C2801-ADVENTERPRISEK9-M), Version 12.4(15)T2, RELEASE SOFTWARE (fc7)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Fri 18-Jan-08 01:42 by prod_rel_team!
! Some attributes that has been requested are unknown to the server
!ISAKMP (0/1034): Unknown Attr: MODECFG_HOSTNAME (0x700A)
ISAKMP (0/1034): Unknown Attr: CONFIG_MODE_UNKNOWN (0x7005)
ISAKMP:(1034): responding to peer config from 70.212.234.119. ID = 1273658318
ISAKMP:(1034): sending packet to 70.212.234.119 my_port 500 peer_port 500 (R) CONF_ADDR
ISAKMP:(1034):Sending an IKE IPv4 Packet.
ISAKMP:(1034):deleting node 1273658318 error FALSE reason "No Error"
ISAKMP:(1034):Talking to a Unity Client
ISAKMP:(1034):Input = IKE_MESG_FROM_AAA, IKE_AAA_GROUP_ATTR
ISAKMP:(1034):Old State = IKE_CONFIG_AUTHOR_AAA_AWAIT New State = IKE_P1_COMPLETEISAKMP:(1034):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1034):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE!
! Phase 2 negotiations start at this point
!ISAKMP (0:1034): received packet from 70.212.234.119 dport 500 sport 500 Global (R) QM_IDLE
ISAKMP: set new node 783930934 to QM_IDLE
ISAKMP:(1034): processing HASH payload. message ID = 783930934
ISAKMP:(1034): processing SA payload. message ID = 783930934
ISAKMP:(1034):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP: attributes in transform:
ISAKMP: authenticator is HMAC-MD5
ISAKMP: key length is 256
ISAKMP: encaps is 1 (Tunnel)
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(1034):atts are acceptable.
ISAKMP:(1034):Checking IPSec proposal 1
ISAKMP:(1034):transform 1, IPPCP LZS
ISAKMP: attributes in transform:
ISAKMP: encaps is 1 (Tunnel)
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(1034):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
!
! Note that remote proxy ID is actually the NEW IP address allocated from the pool
!......
ISAKMP:(1034):Checking IPSec proposal 12
ISAKMP: transform 1, ESP_3DES
ISAKMP: attributes in transform:
ISAKMP: authenticator is HMAC-SHA
ISAKMP: encaps is 1 (Tunnel)
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(1034):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 24.176.176.130, remote= 70.212.234.119,
local_proxy= 0.0.0.0/0.0.0.0/0/0 (type=4),
remote_proxy= 10.0.0.6/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= NONE (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0
insert of map into mapdb AVL failed, map + ace pair already exists on the mapdb
Crypto mapdb : proxy_match
src addr : 0.0.0.0
dst addr : 10.0.0.6
protocol : 0
src port : 0
dst port : 0
ISAKMP:(1034): processing NONCE payload. message ID = 783930934
ISAKMP:(1034): processing ID payload. message ID = 783930934
ISAKMP:(1034): processing ID payload. message ID = 783930934
ISAKMP:(1034):QM Responder gets spi
ISAKMP:(1034):Node 783930934, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1034):Old State = IKE_QM_READY New State = IKE_QM_SPI_STARVE
ISAKMP:(1034): Creating IPSec SAs
inbound SA from 70.212.234.119 to 24.176.176.130 (f/i) 0/ 0
(proxy 10.0.0.6 to 0.0.0.0)
has spi 0xEB769FE1 and conn_id 0
lifetime of 2147483 seconds
outbound SA from 24.176.176.130 to 70.212.234.119 (f/i) 0/0
(proxy 0.0.0.0 to 10.0.0.6)
has spi 0x3E2906BA and conn_id 0
lifetime of 2147483 seconds
ISAKMP:(1034): sending packet to 70.212.234.119 my_port 500 peer_port 500 (R) QM_IDLE
ISAKMP:(1034):Sending an IKE IPv4 Packet.
ISAKMP:(1034):Node 783930934, Input = IKE_MESG_INTERNAL, IKE_GOT_SPI
ISAKMP:(1034):Old State = IKE_QM_SPI_STARVE New State = IKE_QM_R_QM2
IPSEC(key_engine): got a queue event with 1 KMI message(s)
Crypto mapdb : proxy_match
src addr : 0.0.0.0
dst addr : 10.0.0.6
protocol : 0
src port : 0
dst port : 0
IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 70.212.234.119
IPSEC(rte_mgr): VPN Route Event create SA based on crypto ACL in real time for 70.212.234.119
IPSEC(rte_mgr): VPN Route Refcount 1 Virtual-Access2
IPSEC(rte_mgr): VPN Route Added 10.0.0.6 255.255.255.255 via Virtual-Access2 in VORACK11 with tag 0 distance 1
IPSEC(policy_db_add_ident): src 0.0.0.0, dest 10.0.0.6, dest_port 0!
! Phase 3 SA has been created at this point, interface UP
!IPSEC(create_sa): sa created,
(sa) sa_dest= 24.176.176.130, sa_proto= 50,
sa_spi= 0xEB769FE1(3950419937),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2113
IPSEC(create_sa): sa created,
(sa) sa_dest= 70.212.234.119, sa_proto= 50,
sa_spi= 0x3E2906BA(1042876090),
sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2114%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
