High Availability Site-to-Site IPSec VPNs

In this post we will describe high-availability for site-to-site IPSec VPN networks, Hot Standby Router Protocol (HSRP) is often used to track routers’ interface status to achieve failover between routers.

 

image

Here we define ISAKMP policy and IKE pre-shared key for IKE authentication, Note that 10.1.234.234 is the HSRP virtual IP address of the remote HSRP routers.

image

The trick here is with the IKE keepalive to detect the IPSec liveness of the remote VPN router. When HSRP failover happens, IKE keepalive will detect the HSRP router switchover.

Now on R3/R4 we can configure the following:

image

in here, we define HSRP under the interface. HSRP will track the internal interface. Now an HSRP group name must be  and will be used for IPSec configuration.  The “redundancy” keyword in the crypto map command specifies the HSRP group to which IPSec will be configured. 

if we test this configuration:

image

we get on R4 the following

image

Lets do R3 configuration now:

image

Now in This example we are going to demonstrate how HSRP and IPSec failover work together using the above setup and configuration, now in  normal operation,

image

and here we see that R3 is the Active router for HSRP.

image

now,

image

image

image

When failover occurs on the R3 the primary HSRP router, becomes a standby router. Existing ISAKMP and IPSec SAs are torn down. The R4 becomes active and establishes new IPSec SAs with R1.

image 

image

 

A Networker Blog

EzVPN Configuration on a PIX (>I)

My First EZVPN COnfiguration on a PIX
The configuration of the ASA is:
hostname EzVPNServer
username CISCO password TYX7NfYD.Yf733Bn encrypted
!
interface Ethernet0
nameif outside
security-level 0
ip address 10.1.29.9 255.255.255.0
!
interface Ethernet1
nameif inside
security-level 100
ip address 10.1.19.9 255.255.255.0
!
access-list EZACL extended permit ip 150.1.19.0 255.255.255.0 any
ip local pool xEz 192.168.3.0-192.168.3.255 mask 255.255.255.0
!
router ospf 1
network 0.0.0.0 0.0.0.0 area 0
log-adj-changes
redistribute static subnets
!
crypto ipsec transform-set X esp-3des esp-md5-hmac
crypto dynamic-map DMAP 10 set transform-set X
crypto dynamic-map DMAP 10 set reverse-route
crypto map STATIC 10 ipsec-isakmp dynamic DMAP
crypto map STATIC interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
no crypto isakmp nat-traversal
group-policy T internal
group-policy T attributes
dns-server value 1.2.3.4
split-tunnel-policy tunnelspecified
split-tunnel-network-list value EZACL
address-pools value xEz
tunnel-group EzTunnel type remote-access
tunnel-group EzTunnel general-attributes
address-pool xEz
default-group-policy T
tunnel-group EzTunnel ipsec-attributes
pre-shared-key *
prompt hostname context
Cryptochecksum:fe78832de471bc1fc7e2040783f61405
on the IOS the Client Mode is:
R3(config)#crypto ipsec client ezvpn EzTunnel
R3(config-crypto-ezvpn)#?
Crypto EzVPN configuration commands:
acl            Specify access-list identifier for SA establishment
backup         Configure an EzVPN as a backup
connect        Connect
exit           Exit from EzVPN configuration mode
group          Group Name
local-address  Interface to use for local address for this ezvpn
configuration
mode           Mode
no             Negate a command or set its defaults
peer           Allowed Encryption/Decryption Peer
username       User Name
xauth          XAuth parameters
R3(config-crypto-ezvpn)#group EzTunnel ?
key  Group Key
R3(config-crypto-ezvpn)#group EzTunnel key CISCO
R3(config-crypto-ezvpn)#peer 10.1.29.9
R3(config-crypto-ezvpn)#connect ?
acl     Configure matching ACL to trigger EzVPN connection
auto    Automatic
manual  Manual
R3(config-crypto-ezvpn)#connect manual
R3(config-crypto-ezvpn)#exit
R3(config)#int lo0
R3(config-if)#crypto ipsec client ezvpn EzTunnel inside
R3(config)#int f0/0
R3(config-if)#crypto ipsec client ezvpn EzTunnel outside
R3(config-if)#
R3(config-if)#
R3(config-if)#
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
EZVPN(EzTunnel): Current State: IDLE
EZVPN(EzTunnel): Event: VALID_CONFIG_ENTERED
EZVPN(EzTunnel): ezvpn_check_tunnel_interface_state
EZVPN(EzTunnel): New State: VALID_CFG
EZVPN(EzTunnel): Current State: VALID_CFG
EZVPN(EzTunnel): Event: VALID_CONFIG_ENTERED
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: VALID_CFG
EZVPN(EzTunnel): Event: TUNNEL_INTERFACE_UP
EZVPN(EzTunnel): ezvpn_check_tunnel_interface_address
EZVPN(EzTunnel): New State: TUNNEL_INT_UP
EZVPN(EzTunnel): Current State: TUNNEL_INT_UP
EZVPN(EzTunnel): Event: TUNNEL_HAS_PUBLIC_IP_ADD
EZVPN(EzTunnel): New State: TRACKING
EZVPN(EzTunnel): Current State: TRACKING
R3(config-if)#
R3(config-if)#
EZVPN(EzTunnel): Event: TRACKED OBJECT UP
EZVPN(EzTunnel): New State: CONNECT_REQUIRED
R3(config-if)#do crypto ipsec client ezvpn connect
R3(config-if)#
EZVPN(EzTunnel): Deleted PSK for address 10.1.29.9
EZVPN(EzTunnel): Current State: CONNECT_REQUIRED
EZVPN(EzTunnel): Event: CONNECT
EZVPN(EzTunnel): ezvpn_connect_request
EZVPN(EzTunnel): Found valid peer 10.1.29.9
EZVPN(EzTunnel): Added PSK for address 10.1.29.9
EZVPN(EzTunnel): New State: READY
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: IKE_PFS
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: CONN_UP
EZVPN(EzTunnel): ezvpn_conn_up 4C3F5510 A7DE64D0 ED55F8C7 034BCBAF
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: XAUTH_REQUEST
R3(config-if)#
EZVPN(EzTunnel): ezvpn_xauth_request
EZVPN(EzTunnel): ezvpn_parse_xauth_msg
EZVPN: Attributes sent in xauth request message:
XAUTH_TYPE_V2(EzTunnel): 0
XAUTH_USER_NAME_V2(EzTunnel):
XAUTH_USER_PASSWORD_V2(EzTunnel):
EZVPN(EzTunnel): New State: XAUTH_REQ
R3(config-if)#
EZVPN(EzTunnel): Pending XAuth Request, Please enter the following command:
EZVPN: crypto ipsec client ezvpn xauth
R3(config-if)#do crypto ipsec client ezvpn xauth
Username: CISC
EZVPN(EzTunnel): Current State: XAUTH_REQ
EZVPN(EzTunnel): Event: XAUTH_PROMPTING
EZVPN(EzTunnel): New State: XAUTH_PROMPT
CISCO
Password:
R3(config-if)#
EZVPN(EzTunnel): Current State: XAUTH_PROMPT
EZVPN(EzTunnel): Event: XAUTH_REQ_INFO_READY
EZVPN(EzTunnel): ezvpn_xauth_reply
XAUTH_TYPE_V2(EzTunnel): 0
XAUTH_USER_NAME_V2(EzTunnel): CISCO
XAUTH_USER_PASSWORD_V2(EzTunnel): <omitted>
EZVPN(EzTunnel): New State: XAUTH_REPLIED
EZVPN(EzTunnel): Current State: XAUTH_REPLIED
EZVPN(EzTunnel): Event: XAUTH_STATUS
EZVPN(EzTunnel): xauth status received: Success
EZVPN(EzTunnel): New State: READY
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: MODE_CONFIG_REPLY
EZVPN(EzTunnel): ezvpn_mode_config
EZVPN(EzTunnel): ezvpn_parse_mode_config_msg
EZVPN: Attributes sent in message:
Address: 192.168.2.1
Mask: 255.255.255.0
DNS Primary: 1.2.3.4
Savepwd off
Split Tunnel List: 1
Address    : 150.1.19.0
Mask       : 255.255.255.0
Protocol   : 0x0
Source Port: 0
Dest Port  : 0
EZVPN: Unk
R3(config-if)#nown/Unsupported Attr: APPLICATION_VERSION (0x7)
EZVPN(EzTunnel): ezvpn_nat_config
EZVPN(EzTunnel): New State: SS_OPEN
EZVPN(EzTunnel): Current State: SS_OPEN
EZVPN(EzTunnel): Event: SOCKET_READY
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: SS_OPEN
EZVPN(EzTunnel): Event: MTU_CHANGED
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: SS_OPEN
EZVPN(EzTunnel): Event: SOCKET_UP
ezvpn_socket_up
%CRYPTO-6-EZVPN_CONNECTION_UP: (Client)  User=  Group=EzTunnel  Client_public_ad
dr=10.1.23.3  Server_public_addr=10.1.29.9  Assigned_client_addr=192.168.3.1
EZVPN(EzTunnel): Tunnel UP! Letting user know about it
EZVPN(EzTunnel): New State: IPSEC_ACTIVE
R3(config-if)#
%LINK-3-UPDOWN: Interface Loopback1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up
R3(config-if)#do show ip int brief
Interface                  IP-Address      OK? Method Status                Prot
ocol
FastEthernet0/0            10.1.23.3       YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
NVI0                       unassigned      NO  unset  up                    up
Loopback0                  150.1.3.3       YES manual up                    up
Loopback1                  192.168.3.1     YES manual up                    up
R3(config-if)#
on R1 we get, because route-reverse
R1#show ip route ospf
10.0.0.0/24 is subnetted, 3 subnets
O       10.1.29.0 [110/20] via 10.1.19.9, 00:04:21, FastEthernet0/0
O       10.1.23.0 [110/30] via 10.1.19.9, 00:04:21, FastEthernet0/0
192.168.3.0/32 is subnetted, 1 subnets
O       192.168.3.1 [110/31] via 10.1.19.9, 00:04:21, FastEthernet0/0
150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
O       150.1.3.3/32 [110/31] via 10.1.19.9, 00:04:21, FastEthernet0/0
O       150.1.2.2/32 [110/21] via 10.1.19.9, 00:04:21, FastEthernet0/0
R1#
back to R3
R3#ping 10.1.19.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.19.1, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)
R3#ping 10.1.19.1 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.19.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.3.3
.
Success rate is 0 percent (0/1)
R3#ping 10.1.19.1 so lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.19.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/112/144 ms
R3#
on the PIX
EzVPNServer(config)# %PIX-3-106014: Deny inbound icmp src outside:10.1.23.3 dst
inside:10.1.19.1 (type 8, code 0)
%PIX-3-106014: Deny inbound icmp src outside:10.1.23.3 dst inside:10.1.19.1 (typ
e 8, code 0)
%PIX-6-302020: Built inbound ICMP connection for faddr 192.168.3.1/7 gaddr 10.1.
19.1/0 laddr 10.1.19.1/0 (CISCO)
%PIX-6-302020: Built outbound ICMP connection for faddr 192.168.3.1/7 gaddr 10.1
.19.1/0 laddr 10.1.19.1/0

My First EzVPN Configuration:


212

The configuration of the PIX (>I) is:

username CISCO password TYX7NfYD.Yf733Bn encrypted
!
interface Ethernet0
nameif outside
security-level 0
ip address 10.1.29.9 255.255.255.0
!
interface Ethernet1
nameif inside
security-level 100
ip address 10.1.19.9 255.255.255.0
!
access-list EZACL extended permit ip 150.1.19.0 255.255.255.0 any
ip local pool xEz 192.168.3.0-192.168.3.255 mask 255.255.255.0
!
router ospf 1
network 0.0.0.0 0.0.0.0 area 0
log-adj-changes
redistribute static subnets ! for RRI
!
crypto ipsec transform-set X esp-3des esp-md5-hmac
crypto dynamic-map DMAP 10 set transform-set X
crypto dynamic-map DMAP 10 set reverse-route
crypto map STATIC 10 ipsec-isakmp dynamic DMAP
crypto map STATIC interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
no crypto isakmp nat-traversal

group-policy T internal
group-policy T attributes
dns-server value 1.2.3.4
split-tunnel-policy tunnelspecified
split-tunnel-network-list value EZACL
address-pools value xEz
tunnel-group EzTunnel type remote-access
tunnel-group EzTunnel general-attributes
address-pool xEz
default-group-policy T
tunnel-group EzTunnel ipsec-attributes
pre-shared-key *
prompt hostname context

on the IOS the Client Mode Configuration is:


R3(config)#crypto ipsec client ezvpn EzTunnel
R3(config-crypto-ezvpn)#?
Crypto EzVPN configuration commands:
acl            Specify access-list identifier for SA establishment
backup         Configure an EzVPN as a backup
connect        Connect
exit           Exit from EzVPN configuration mode
group          Group Name
local-address  Interface to use for local address for this ezvpn
configuration
mode           Mode
no             Negate a command or set its defaults
peer           Allowed Encryption/Decryption Peer
username       User Name
xauth          XAuth parameters
R3(config-crypto-ezvpn)#group EzTunnel ?
key  Group Key
R3(config-crypto-ezvpn)#group EzTunnel key CISCO
R3(config-crypto-ezvpn)#peer 10.1.29.9
R3(config-crypto-ezvpn)#connect ?
acl     Configure matching ACL to trigger EzVPN connection
auto    Automatic
manual  Manual
R3(config-crypto-ezvpn)#connect manual
R3(config-crypto-ezvpn)#exit
R3(config)#int lo0
R3(config-if)#crypto ipsec client ezvpn EzTunnel inside
R3(config)#int f0/0
R3(config-if)#crypto ipsec client ezvpn EzTunnel outside
R3(config-if)#
R3(config-if)#
R3(config-if)#
%CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
EZVPN(EzTunnel): Current State: IDLE
EZVPN(EzTunnel): Event: VALID_CONFIG_ENTERED
EZVPN(EzTunnel): ezvpn_check_tunnel_interface_state
EZVPN(EzTunnel): New State: VALID_CFG
EZVPN(EzTunnel): Current State: VALID_CFG
EZVPN(EzTunnel): Event: VALID_CONFIG_ENTERED
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: VALID_CFG
EZVPN(EzTunnel): Event: TUNNEL_INTERFACE_UP
EZVPN(EzTunnel): ezvpn_check_tunnel_interface_address
EZVPN(EzTunnel): New State: TUNNEL_INT_UP
EZVPN(EzTunnel): Current State: TUNNEL_INT_UP
EZVPN(EzTunnel): Event: TUNNEL_HAS_PUBLIC_IP_ADD
EZVPN(EzTunnel): New State: TRACKING
EZVPN(EzTunnel): Current State: TRACKING
R3(config-if)#
R3(config-if)#
EZVPN(EzTunnel): Event: TRACKED OBJECT UP
EZVPN(EzTunnel): New State: CONNECT_REQUIRED</pre>
!Here need to connect 
R3(config-if)#do crypto ipsec client ezvpn connect
R3(config-if)#
EZVPN(EzTunnel): Deleted PSK for address 10.1.29.9
EZVPN(EzTunnel): Current State: CONNECT_REQUIRED
EZVPN(EzTunnel): Event: CONNECT
EZVPN(EzTunnel): ezvpn_connect_request
EZVPN(EzTunnel): Found valid peer 10.1.29.9
EZVPN(EzTunnel): Added PSK for address 10.1.29.9
EZVPN(EzTunnel): New State: READY
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: IKE_PFS
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: CONN_UP
EZVPN(EzTunnel): ezvpn_conn_up 4C3F5510 A7DE64D0 ED55F8C7 034BCBAF
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: XAUTH_REQUEST
R3(config-if)#
EZVPN(EzTunnel): ezvpn_xauth_request
EZVPN(EzTunnel): ezvpn_parse_xauth_msg
EZVPN: Attributes sent in xauth request message:
XAUTH_TYPE_V2(EzTunnel): 0
XAUTH_USER_NAME_V2(EzTunnel):
XAUTH_USER_PASSWORD_V2(EzTunnel):
EZVPN(EzTunnel): New State: XAUTH_REQ
EZVPN(EzTunnel): Current State: XAUTH_REPLIED
EZVPN(EzTunnel): Event: XAUTH_STATUS
EZVPN(EzTunnel): xauth status received: Success
EZVPN(EzTunnel): New State: READY
EZVPN(EzTunnel): Current State: READY
EZVPN(EzTunnel): Event: MODE_CONFIG_REPLY
EZVPN(EzTunnel): ezvpn_mode_config
EZVPN(EzTunnel): ezvpn_parse_mode_config_msg
EZVPN: Attributes sent in message:
        Address: 192.168.2.1
        Mask: 255.255.255.0
        DNS Primary: 1.2.3.4
        Savepwd off
        Split Tunnel List: 1
              Address    : 150.1.19.0
              Mask       : 255.255.255.0
              Protocol   : 0x0
              Source Port: 0
              Dest Port  : 0
EZVPN: Unknown/Unsupported Attr: APPLICATION_VERSION (0x7)
EZVPN(EzTunnel): ezvpn_nat_config
EZVPN(EzTunnel): New State: SS_OPEN
EZVPN(EzTunnel): Current State: SS_OPEN
EZVPN(EzTunnel): Event: SOCKET_READY
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: SS_OPEN
EZVPN(EzTunnel): Event: MTU_CHANGED
EZVPN(EzTunnel): No state change
EZVPN(EzTunnel): Current State: SS_OPEN
EZVPN(EzTunnel): Event: SOCKET_UP
ezvpn_socket_up
%CRYPTO-6-EZVPN_CONNECTION_UP: (Client)  User=  Group=EzTunnel  Client_public_ad
dr=10.1.23.3  Server_public_addr=10.1.29.9  Assigned_client_addr=192.168.3.1
EZVPN(EzTunnel): Tunnel UP! Letting user know about it
EZVPN(EzTunnel): New State: IPSEC_ACTIVE
R3(config-if)#
%LINK-3-UPDOWN: Interface Loopback1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up
R3(config-if)#do show ip int brief

Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.1.23.3       YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down
NVI0                       unassigned      NO  unset  up                    up
Loopback0                  150.1.3.3       YES manual up                    up
Loopback1                  192.168.3.1     YES manual up                    up
R3(config-if)#

All right!!, now we can see that on R1 we get,

R1#show ip route ospf
10.0.0.0/24 is subnetted, 3 subnets
O       10.1.29.0 [110/20] via 10.1.19.9, 00:04:21, FastEthernet0/0
O       10.1.23.0 [110/30] via 10.1.19.9, 00:04:21, FastEthernet0/0
192.168.3.0/32 is subnetted, 1 subnets
O       192.168.3.1 [110/31] via 10.1.19.9, 00:04:21, FastEthernet0/0
150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
O       150.1.3.3/32 [110/31] via 10.1.19.9, 00:04:21, FastEthernet0/0
O       150.1.2.2/32 [110/21] via 10.1.19.9, 00:04:21, FastEthernet0/0
R1#

the 192.168.3.1 [110/31] via 10.1.19.9 route this ecause route-reverse injection, let go back to R3

R3#ping 10.1.19.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.19.1, timeout is 2 seconds:..

Success rate is 0 percent (0/2)
R3#ping 10.1.19.1 so lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.19.1, timeout is 2 seconds:
Packet sent with a source address of 150.1.3.3
.
Success rate is 0 percent (0/1)
R3#ping 10.1.19.1 so lo1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.19.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/112/144 ms
R3#

on the PIX

EzVPNServer(config)# %PIX-3-106014: Deny inbound icmp src outside:10.1.23.3 dst
inside:10.1.19.1 (type 8, code 0)
%PIX-3-106014: Deny inbound icmp src outside:10.1.23.3 dst inside:10.1.19.1 (typ
e 8, code 0)
%PIX-6-302020: Built inbound ICMP connection for faddr 192.168.3.1/7 gaddr 10.1.
19.1/0 laddr 10.1.19.1/0 (CISCO)
%PIX-6-302020: Built outbound ICMP connection for faddr 192.168.3.1/7 gaddr 10.1
.19.1/0 laddr 10.1.19.1/0
EzVPNServer# show crypto isakmp sa
   Active SA: 1
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1   IKE Peer: 10.1.23.3
    Type    : user            Role    : responder
    Rekey   : no              State   : AM_ACTIVE
EzVPNServer#
%PIX-7-111009: User 'enable_15' executed cmd: show crypto isakmp sa

on a Windows XP Machine, the Client Configuration is:

2121

2122

2123

Nice!!!

A Networker Blog

IKE – Internet Key Exchange

IKE Phases
Phase 1:
* Authenticate the peers
* Negotiate a bidirectional SA
* Main mode (6 messages)  or aggressive mode (3 messages)
** show crypto isakmp sa
Phase 1.5:
* Xauth (User Authentication)
* Mode config (Push Config)
Phase 2:
* IPsec SAs/SPIs
* Quick mode
show crypto ipsec sa

RFC 2401 defines the architecture for IPSec, including the framework and the services provided. RFC 2401 also defines how the services work together and how and where to use them.

IPSec uses three main protocols to create a security framework:

 

  • Internet Key Exchange (IKE)
  • Encapsulating Security Payload (ESP)
  • Authentication Header (AH)

Internet Key Exchange (IKE)  is the protocol for exchanging keys. It provides a framework for the negotiation of security parameters and establishes authenticated keys.

IPSec uses symmetrical encryption algorithms for data protection, which are more efficient and easier to implement in hardware than other types of algorithms.

These algorithms need a secure method of key exchange to ensure data protection. The IKE protocols provide the capability for secure key exchange.

Internet Key Exchange (IKE) solves the problems of manual and unscalable implementation of IPSec by automating the entire key exchange process, including

  • negotiation of security association (SA) characteristics
  • automatic key generation
  • automatic key refresh
  • manageable manual configuration

To implement a VPN solution with encryption, the periodic changing of encryption keys is necessary. Failure to change these keys makes the network susceptible to brute force attacks.

IPSec solves this problem with the IKE protocol, which uses two other protocols to authenticate a peer and generate keys. The IKE protocol uses a mathematical routine called a Diffie-Hellman exchange to generate symmetrical keys to be used by two IPSec peers.

IKE also manages the negotiation of other security parameters, such as data to be protected, strength of the keys, hash methods used, and whether packets are protected from replay. IKE uses UDP port 500.

IKE negotiates an SA, which is an agreement between two peers engaging in an IPSec exchange. To establish successful communication, the SA comprises three required parameters:

  • Oakley
  • ISAKMP
  • Skeme

Resume of the IKE Phases

IKE Phase 1:

* Authenticate the peers

Optionally, phase 1 can also include an authentication in which each peer is able to verify the identity of the other. This conversation between two IPSec peers can be subject to eavesdropping with no significant vulnerability of the keys being recovered.

* Negotiate a bidirectional SA

Phase 1 SAs are bidirectional – data may be sent and received using the same key material generated. Two modes are available for phase 1 SA negotiations: main mode or aggressive mode.

* Main mode (6 messages) or aggressive mode (3 messages)

in – Main mode

In the main mode, an IKE session begins with the initiator sending a proposal or proposals to the responder. These proposals define which encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy should be enforced. Multiple proposals can be sent in one offering.

The first exchange between nodes establishes the basic security policy. The responder chooses the appropriate proposal and sends it to the initiator. The next exchange passes Diffie-Hellman public keys and other data. All further negotiation is encrypted within the IKE SA. The third exchange authenticates the ISAKMP session. Once the IKE SA is established, IPSec negotiation (quick mode) begins.

in – Aggressive mode

The aggressive mode squeezes the IKE SA negotiation into three packets, with all data required for the SA passed by the initiator. The responder sends the proposal, key material, and identification, and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder ID pass in plaintext.

** show crypto isakmp sa

IKE Phase 1 is the initial negotiation of SAs between two IPSec peers.

IKE Phase 1.5 (Optional):

* Xauth (User Authentication)

IKE Phase 1.5 is optional. To further authenticate VPN participants (clients), you can use a protocol called Extended Authentication (Xauth), which provides user authentication of IPSec tunnels within the IKE protocol. Additionally, you can exchange other parameters between the peers.

* Mode config (Push Config)

Mode configuration is used to deliver parameters such as IP address and DNS address to the client.

IKE Phase 2:

* IPsec SAs/SPIs

IKE Phase 2 SAs are negotiated by the IKE process (ISAKMP) on behalf of other services such as IPSec, which need key material for operation.

Because the SAs used by IPSec are unidirectional, separate key exchanges are needed for data flowing in the forward direction and the reverse direction. The two peers have already agreed upon the transform sets, hash methods, and other parameters during the phase 1 negotiation.

* Quick mode

Quick mode is the method used for the phase 2 SA negotiations. – The quick mode IPSec negotiation is similar to an aggressive mode IKE negotiation, except negotiation must be protected within an IKE SA. Quick mode negotiates the SA for the data encryption and manages the key exchange for that IPSec SA.

** show crypto ipsec sa


Main mode:

has three two-way exchanges between the initiator and receiver:

— First exchange—The algorithms and hashes used to secure the IKE communications are negotiated and agreed upon between peers.

— Second exchange—This exchange uses a DH exchange to generate shared secret keys and pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity. The shared secret key is used to generate all the  other encryption and authentication keys.

— Third exchange—This exchange verifies the other side’s identity. It is used to authenticate the remote peer. The main outcome of main mode is a secure communication path for subsequent exchanges between the peers. Without proper authentication, you might establish a secure communication channel with a hacker who could be stealing all your sensitive material.

– Takes longer time to negotiate

– Hides party identities performing DH exchange

 

            Initiator                    Responder
  HDR, SA -->
                                  <--    HDR, SA
              HDR, KE, Ni, GSSi   -->
                                  <--    HDR, KE, Nr, GSSr
              HDR*, IDii, HASH_I  -->
                                  <--    HDR*, IDir, HASH_R

 

in this log you can find the different states of   the Main Mode

  • IKE_READY New State = IKE_I_MM1
  • IKE_I_MM1 New State = IKE_I_MM2
  • IKE_I_MM2 New State = IKE_I_MM3
  • IKE_I_MM3 New State = IKE_I_MM4
  • IKE_I_MM4 New State = IKE_I_MM5
  • IKE_I_MM5 New State = IKE_I_MM6

crypto isakmp key cisco123 address 2.2.2.2
!
!
crypto ipsec transform-set R3R2 esp-aes 192 esp-md5-hmac
!
crypto map NAME local-address Loopback0
crypto map NAME 10 ipsec-isakmp
set peer 2.2.2.2
set transform-set R3R2
match address 100
!
!
!
AKMP: Created a peer struct for 2.2.2.2, peer port 500
ISAKMP: New peer created peer = 0x66F2A5F4 peer_handle = 0x80000004
ISAKMP: Locking peer struct 0x66F2A5F4, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 66F1F9DC
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):found peer pre-shared key matching 2.2.2.2
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1
ISAKMP:(0): beginning Main Mode exchange
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_NO_STATE
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_NO_STATE
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0):found peer pre-shared key matching 2.2.2.2
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM2
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4
ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):found peer pre-shared key matching 2.2.2.2
ISAKMP:(1002): processing vendor id payload
ISAKMP:(1002): vendor ID is Unity
ISAKMP:(1002): processing vendor id payload
ISAKMP:(1002): vendor ID is DPD
ISAKMP:(1002): processing vendor id payload
ISAKMP:(1002): speaking to another IOS box!
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1002):Old State = IKE_I_MM4  New State = IKE_I_MM4
ISAKMP:(1002):Send initial contact
ISAKMP:(1002):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (0:1002): ID payload
next-payload : 8
type         : 1
address      : 3.3.3.3
protocol     : 17
port         : 500
length       : 12
ISAKMP:(1002):Total payload length: 12
ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1002):Old State = IKE_I_MM4  New State = IKE_I_MM5
ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP:(1002): processing ID payload. message ID = 0
ISAKMP (0:1002): ID payload
next-payload : 8
type         : 1
address      : 2.2.2.2
protocol     : 17
port         : 500
length       : 12
ISAKMP:(1002):: peer matches *none* of the profiles
ISAKMP:(1002): processing HASH payload. message ID = 0
ISAKMP:(1002):SA authentication status:
authenticated
ISAKMP:(1002):SA has been authenticated with 2.2.2.2
ISAKMP: Trying to insert a peer 3.3.3.3/2.2.2.2/500/,  and inserted successfully 66F2A5F4.
ISAKMP:(1002):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(1002):Old State = IKE_I_MM5  New State = IKE_I_MM6
ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP: set new node 383677917 to QM_IDLE
ISAKMP:(1002): processing HASH payload. message ID = 383677917
ISAKMP:(1002): processing DELETE payload. message ID = 383677917
ISAKMP:(1002):peer does not do paranoid keepalives.
ISAKMP:(1002):deleting node 383677917 error FALSE reason "Informational (in) state 1"
IPSEC(key_engine): got a queue event with 1 KMI message(s)
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1002):Old State = IKE_I_MM6  New State = IKE_I_MM6
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1002):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE
ISAKMP:(1002):beginning Quick Mode exchange, M-ID of 446518647
ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1002):Node 446518647, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1002):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1002):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1002): processing HASH payload. message ID = 446518647
ISAKMP:(1002): processing SA payload. message ID = 446518647
ISAKMP:(1002):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in secondsISAKMP:
SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-MD5
ISAKMP:      key length is 192
ISAKMP:(1002):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 3.3.3.3, remote= 2.2.2.2,
local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
protocol= ESP, transform= esp-aes 192 esp-md5-hmac  (Tunnel),
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0
Crypto mapdb : proxy_match
src addr     : 3.3.3.3
dst addr     : 2.2.2.2
protocol     : 0
src port     : 0
dst port     : 0
ISAKMP:(1002): processing NONCE payload. message ID = 446518647
ISAKMP:(1002): processing ID payload. message ID = 446518647
ISAKMP:(1002): processing ID payload. message ID = 446518647
ISAKMP:(1002): Creating IPSec SAs
inbound SA from 2.2.2.2 to 3.3.3.3 (f/i)  0/ 0
(proxy 2.2.2.2 to 3.3.3.3)
has spi 0x8B6DC3A5 and conn_id 0
lifetime of 3600 seconds
lifetime of 4608000 kilobytes
outbound SA from 3.3.3.3 to 2.2.2.2 (f/i) 0/0
(proxy 3.3.3.3 to 2.2.2.2)
has spi  0x83BD1925 and conn_id 0
lifetime of 3600 seconds
lifetime of 4608000 kilobytes
ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1002):deleting node 446518647 error FALSE reason "No Error"
ISAKMP:(1002):Node 446518647, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1002):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)
Crypto mapdb : proxy_match
src addr     : 3.3.3.3
dst addr     : 2.2.2.2
protocol     : 0
src port     : 0
dst port     : 0
IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 2.2.2.2
IPSec: Flow_switching Allocated flow for sibling 80000003
IPSEC(policy_db_add_ident): src 3.3.3.3, dest 2.2.2.2, dest_port 0
IPSEC(create_sa): sa created,
(sa) sa_dest= 3.3.3.3, sa_proto= 50,
sa_spi= 0x8B6DC3A5(2339226533),
sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 3
IPSEC(create_sa): sa created,
(sa) sa_dest= 2.2.2.2, sa_proto= 50,
sa_spi= 0x83BD1925(2210208037),
sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 4
IPSEC(update_current_outbound_sa): updated peer 2.2.2.2 current outbound sa to SPI 83BD1925

Main Mode

Aggressive mode:

fewer exchanges are done and with fewer packets. The first exchange covers almost all of the steps:

the IKE policy set negotiation; the DH public key generation; a nonce, which the other party signs; and an identity packet,  which can be used to verify the identity of the other party via a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange.

– Takes less time to negotiate

– Does not hide party identities

 

             Initiator                    Responder

              HDR, SA, KE, Ni,
                IDii, GSSi        -->
                                  <--    HDR, SA, KE, Nr,
                                         IDir, GSSr, HASH_R
              HDR, HASH_I         -->


crypto isakmp policy 10
 authentication pre-share
!
crypto isakmp peer address 2.2.2.2
 set aggressive-mode password cisco123
 set aggressive-mode client-endpoint ipv4-address 3.3.3.3
!
!
crypto ipsec transform-set R3R2 esp-aes 192 esp-md5-hmac
!
crypto map NAME local-address Loopback0
crypto map NAME 10 ipsec-isakmp
 set peer 2.2.2.2
 set transform-set R3R2
 match address 100
!
!
!
!
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex half
!
interface FastEthernet1/0
 ip address 10.1.13.3 255.255.255.0
 duplex auto
 speed auto
 crypto map NAME
!
access-list 100 permit ip host 3.3.3.3 host 2.2.2.2
!
!
IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 3.3.3.3, remote= 2.2.2.2,
    local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
    remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
    protocol= ESP, transform= NONE  (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x38875DE9(948395497), conn_id= 0, keysize= 192, flags= 0x0
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 2.2.2.2, peer port 500
ISAKMP: New peer created peer = 0x6678E794 peer_handle = 0x80000007
ISAKMP: Locking peer struct 0x6678E794, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 670BE478
ISAKMP:(0):SA has tunnel attributes set.
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (0:0): ID payload
        next-payload : 13
        type         : 1
        address      : 3.3.3.3
        protocol     : 17
        port         : 0
        length       : 12
ISAKMP:(0):Total payload length: 12
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_AM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_AM1

ISAKMP:(0): beginning Aggressive Mode exchange
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) AG_INIT_EXCH
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) AG_INIT_EXCH
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing ID payload. message ID = 0
ISAKMP (0:0): ID payload
        next-payload : 10
        type         : 1
        address      : 2.2.2.2
        protocol     : 17
        port         : 0
        length       : 12
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is Unity
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is DPD
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): speaking to another IOS box!
ISAKMP:(0):SA using tunnel password as pre-shared key.
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):SA using tunnel password as pre-shared key.
ISAKMP:(1003): processing HASH payload. message ID = 0
ISAKMP:(1003):SA authentication status:
        authenticated
ISAKMP:(1003):SA has been authenticated with 2.2.2.2
ISAKMP: Trying to insert a peer 3.3.3.3/2.2.2.2/500/,  and inserted successfully 6678E794.
ISAKMP:(1003):Send initial contact
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) AG_INIT_EXCH
ISAKMP:(1003):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
ISAKMP:(1003):Old State = IKE_I_AM1  New State = IKE_P1_COMPLETE

ISAKMP:(1003):beginning Quick Mode exchange, M-ID of -243305607
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1003):Node -243305607, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1003):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1003):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

ISAKMP (0:1003): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP: set new node -689131644 to QM_IDLE
ISAKMP:(1003): processing HASH payload. message ID = -689131644
ISAKMP:(1003): processing DELETE payload. message ID = -689131644
ISAKMP:(1003):peer does not do paranoid keepalives.

ISAKMP:(1003):deleting node -689131644 error FALSE reason "Informational (in) state 1"
IPSEC(key_engine): got a queue event with 1 KMI message(s)
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
ISAKMP (0:1003): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1003): processing HASH payload. message ID = -243305607
ISAKMP:(1003): processing SA payload. message ID = -243305607
ISAKMP:(1003):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-MD5
ISAKMP:      key length is 192
ISAKMP:(1003):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 3.3.3.3, remote= 2.2.2.2,
    local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
    remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
    protocol= ESP, transform= esp-aes 192 esp-md5-hmac  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0
Crypto mapdb : proxy_match
        src addr     : 3.3.3.3
        dst addr     : 2.2.2.2
        protocol     : 0
        src port     : 0
        dst port     : 0
ISAKMP:(1003): processing NONCE payload. message ID = -243305607
ISAKMP:(1003): processing ID payload. message ID = -243305607
ISAKMP:(1003): processing ID payload. message ID = -243305607
ISAKMP:(1003): Creating IPSec SAs
        inbound SA from 2.2.2.2 to 3.3.3.3 (f/i)  0/ 0
        (proxy 2.2.2.2 to 3.3.3.3)
        has spi 0x38875DE9 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
        outbound SA from 3.3.3.3 to 2.2.2.2 (f/i) 0/0
        (proxy 3.3.3.3 to 2.2.2.2)
        has spi  0x77695521 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1003):deleting node -243305607 error FALSE reason "No Error"
ISAKMP:(1003):Node -243305607, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1003):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)
Crypto mapdb : proxy_match
        src addr     : 3.3.3.3
        dst addr     : 2.2.2.2
        protocol     : 0
        src port     : 0
        dst port     : 0
IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 2.2.2.2
IPSec: Flow_switching Allocated flow for sibling 80000004
IPSEC(policy_db_add_ident): src 3.3.3.3, dest 2.2.2.2, dest_port 0

IPSEC(create_sa): sa created,
  (sa) sa_dest= 3.3.3.3, sa_proto= 50,
    sa_spi= 0x38875DE9(948395497),
    sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 5
IPSEC(create_sa): sa created,
  (sa) sa_dest= 2.2.2.2, sa_proto= 50,
    sa_spi= 0x77695521(2003391777),
    sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 6
IPSEC(update_current_outbound_sa): updated peer 2.2.2.2 current outbound sa to SPI 77695521

Aggresive

 

list of current RFCs concerning IPSec

RFC 1829: The ESP DES-CBC transform

RFC 1851: The ESP triple DES transform

RFC 2085: HMAC-MD5 IP authentication with replay prevention

RFC 2207: RSVP extensions for IPSec data flows

RFC 2401: Security architecture for the Internet Protocol

RFC 2402: IP Authentication Header

RFC 2403: The use of HMAC-MD5-96 within ESP and AH

RFC 2404: The use of HMAC-SHA-1-96 within ESP and AH

RFC 2405: The ESP DES-CBC Cipher Algorithm with Explicit IV

RFC 2406: IP Encapsulating Security Payload (ESP)

RFC 2407: The Internet IP security domain of interpretation for ISAKMP

RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)

RFC 2409: The Internet Key Exchange (IKE)

RFC 2410: The NULL Encryption and its use with IPSec

RFC 2451: The ESP CBC-Mode Cipher Algorithm

RFC 2539: Storage of Diffie-Hellman Keys in the Domain Name Space (DNS)

RFC 2631: Diffie-Hellman Key Agreement Method

RFC 2857: The use of HMAC-RIPEMD-160-96 within ESP and AH

RFC 2875: Diffie-Hellman Proof-of-Possession Algorithms

RFC 3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay

RFC 3104: RSIP Support for End-of-End IPSec

RFC 3145: L2LTP disconnect cause information

RFC 3193: Securing L2LTP using IP

RFC 3301: Layer Two Tunneling Protocol (L2LTP): ATM access network extensions

 

 

 

In Summary

IPSec is a way to secure data transmissions over unprotected networks. IPSec provides data confidentiality, data integrity, data origin authentication, and anti-replay, which verify the uniqueness of each data packet. IPSec uses the Encapsulating Security Payload (ESP) and Authentication Header (AH) IP protocols, as well as the Internet Key Exchange (IKE) protocol. IPSec also handles peer authentication.

IPSec solves the encryption problem of a VPN solution by using the IKE protocol, which uses UDP port 500. IKE is executed in two phases. Phase 1 initializes the SAs between two peers, and phase 2 manages the bidirectional flow of information between the two peers. Phase 1 can be split into two, so that you can do an extended authentication (Xauth) on VPN clients. IKE can be used in a combination of three modes – main mode, aggressive mode, and quick mode.

A Networker Blog

Reflexive ACLs

Reflexive ACLs allow IP packets to be filtered based on upper-layer session information.

Reflexive ACLs provide a level of security against spoofing and certain denial of service (DoS) attacks.

Reflexive ACLs are  harder to spoof because more  criteria must match in the packet for example, source and destination addresses and port numbers, not just acknowledgment (ACK) and reset (RST) bits.

The following configuration makes the  router keep track of the  traffic initiated from inside.

ip access-list extended OUTBOUND
permit icmp 1.1.1.0 0.0.0.255 12.16.0.0 0.0.0.255
permit tcp 1.1.1.0 0.0.0.255 12.16.0.0 0.0.0.255 reflect myfw

In the next configuration, we create an inbound policy, now the router will check  incoming traffic to see if it was initiated from inside an the reflexive ACL part of the OUTBOUND ACL, called MYFE, to the INBOUND ACL.

ip access-list extended INBOUND
permit icmp 12.16.0.0 0.0.0.255 1.1.1.0 0.0.0.255
evaluate myfw

Applies both an inbound and an outbound ACL to the outgoing interface.


Router(config)#interface Ethernet0/1
Router(config-if)#ip address 172.16.1.2 255.255.255.0
Router(config-if)#ip access-group INBOUND in
Router(config-if)#ip access-group OUTBOUND out

A Networker Blog

Cisco TCP intercept

TCP intercept feature implements software to protect TCP servers from TCP
SYN-flooding attacks, which are a type of denial-of-service attack

by

http://www.cert.org/tech_tips/denial_of_service.html

A “denial-of-service” attack is characterized by an explicit attempt by
attackers to prevent legitimate users of a service from using that service.
Examples include

* attempts to “flood” a network, thereby preventing legitimate network
traffic
* attempts to disrupt connections between two machines, thereby preventing
access to a service
* attempts to prevent a particular individual from accessing a service
* attempts to disrupt service to a specific system or person

so lets do a DOS 😛  “just 4 education purpose”

Having this topology

R2 — R1 — R4 — BB2
|
R5

R2#traceroute 212.2.12.254

Type escape sequence to abort.
Tracing the route to 212.2.12.254

1 192.168.12.1 0 msec 0 msec 4 msec
2 192.168.134.4 28 msec 32 msec 28 msec
3 212.2.12.254 28 msec *  28 msec
R2#

R5#traceroute 212.2.12.254

Type escape sequence to abort.
Tracing the route to 212.2.12.254

1 192.168.45.4 28 msec 28 msec 28 msec
2  *
212.2.12.254 28 msec *
R5#

R1#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#do show ip int brief  | ex una
Interface                  IP-Address      OK? Method Status
Protocol
FastEthernet0/0            192.168.173.1   YES NVRAM  up                    up
Serial0/0/0                192.168.134.1   YES manual up                    up
Serial0/0/1                192.168.12.1    YES NVRAM  up                    up
Loopback0                  110.110.1.1     YES NVRAM  up                    up
R1(config)#

So the packets in R1 goes like this

*Aug  3 21:53:58.896: IP: s=212.2.12.254 (Serial0/0/0), d=192.168.12.0
(Serial0/0/1), g=192.168.12.0, len 100, forward

lets modify a little bit the process

R1#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0/1
R1(config-if)#ip nat in
R1(config-if)#exit
*Aug  3 21:39:00.928: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0,
changed state to up
R1(config)#int s0/0/0
R1(config-if)#ip nat out
R1(config-if)#exit
R1(config)#ip nat inside source static 192.168.12.0 192.168.45.5
R1(config)#
*Aug  3 22:01:05.580: ipnat_add_static_cfg: id 6, flag 6
*Aug  3 22:01:05.580: id 6, flags 0, domain 0, lookup 0, from_addr C0A80C00,
from_mask FFFFFFFF, from_port 0, to_addr C0A82D05, to_port 0 to_mask FFFFFFFF,
proto 0
*Aug  3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8516]
*Aug  3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8516]
*Aug  3 22:01:05.600: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8516]
R1(config)#
*Aug  3 22:01:07.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8517]
*Aug  3 22:01:07.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8517]
R1(config)#do u
*Aug  3 22:01:09.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8518]
*Aug  3 22:01:09.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8518]
R1(config)#do u all
All possible debugging has been turned off
R1(config)#

So we are now translating the thing 🙂

Now BB2 thinks that the thing comes from R5

*Aug  3 22:36:29.904: IP: tableid=0, s=192.168.45.5 (FastEthernet0/0),
d=212.2.12.254 (FastEthernet0/0), routed via RIB
*Aug  3 22:36:29.904: IP: s=192.168.45.5 (FastEthernet0/0), d=212.2.12.254
(FastEthernet0/0), len 100, rcvd 3
*Aug  3 22:36:29.904: IP: tableid=0, s=212.2.12.254 (local), d=192.168.45.5
(FastEthernet0/0), routed via FIB
*Aug  3 22:36:29.904: IP: s=212.2.12.254 (local), d=192.168.45.5
(FastEthernet0/0), len 100, sending
BB2#

hehehe

now lets configure the TCP intercept to see how it works

again in this cisco link
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur
_c/scprt3/scddenl.htm

A SYN-flooding attack occurs when a hacker floods a server with a barrage of
requests for connection. Because these messages have unreachable return
addresses, the connections cannot be established. The resulting volume of
unresolved open connections eventually overwhelms the server and can cause it
to deny service to valid requests, thereby preventing legitimate users from
connecting to a web site, accessing e-mail, using FTP service, and so on.

Page 27 http://www.faqs.org/rfcs/rfc793.html

The synchronization requires each side to send it’s own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side.  Each side must also receive the other side’s
initial sequence number and send a confirming acknowledgment.

1) A –> B  SYN my sequence number is X
2) A <– B  ACK your sequence number is X
3) A <– B  SYN my sequence number is Y
4) A –> B  ACK your sequence number is Y

so lets try this on R2, BB1 and see what is the deal

BB2#debug ip tcp pac
TCP Packet debugging is on
BB2#
rack8>2
[Resuming connection 2 to R2 … ]

R2#telnet 212.2.12.254
Trying 212.2.12.254 …
rack8>11
[Resuming connection 11 to bb2 … ]

*Aug  3 22:40:28.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23 seq
1721243964
OPTS 4 SYN  WIN 4128
*Aug  3 22:40:28.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1347870184
OPTS 4 ACK 1721243965 SYN  WIN 4128
*Aug  3 22:40:28.884: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1721243965
RST  WIN 0
BB2#
*Aug  3 22:40:30.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23 seq
1721243964
OPTS 4 SYN  WIN 4128
*Aug  3 22:40:30.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1849125975
OPTS 4 ACK 1721243965 SYN  WIN 4128
*Aug  3 22:40:30.880: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1721243965
RST  WIN 0
BB2#
rack8>

So BB3 thinks that I comes from R5 :S

So lets configure R4 with this access-list

ip tcp intercept list 102
ip tcp intercept watch-timeout 15
ip tcp intercept mode watch
access-list 102 permit tcp any 212.2.12.0 0.0.0.255

R4#show tcp intercept  statistics
Watching new connections using access-list 102
1 incomplete, 0 established connections (total 1)
2 connection requests per minute
R4#
*Aug  3 22:13:40.019: INTERCEPT: server packet passed in SYNRCVD
(192.168.45.5:55622 <- 212.2.12.254:23)
*Aug  3 22:13:41.019: INTERCEPT: SYNRCVD timing out (192.168.45.5:55622 <->
212.2.12.254:23)
*Aug  3 22:13:41.019: INTERCEPT(*): (192.168.45.5:55622 RST ->
212.2.12.254:23)

or we can modify watch time to see the thing faster 🙂

R4#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#no ip tcp intercept watch-timeout 15
R4(config)#ip tcp intercept watch-timeout 5
command accepted, interfaces with mls configured might cause inconsistent
behavior

R4(config)#^Z
R4#show run
*Aug  3 22:15:21.359: %SYS-5-CONFIG_I: Configured from console by console
R4#show run | in intercept
ip tcp intercept list 102
ip tcp intercept watch-timeout 5
ip tcp intercept mode watch
R4#
rack8>2
[Resuming connection 2 to R2 … ]

% Connection timed out; remote host not responding

R2#
R2#telnet 212.2.12.254
Trying 212.2.12.254 …
rack8>4
[Resuming connection 4 to R4 … ]

R4#
R4#
*Aug  3 22:15:33.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
*Aug  3 22:15:33.731: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#show run | in inter
*Aug  3 22:15:35.727: INTERCEPT: server packet passed in SYNRCVD
(192.168.45.5:46993 <- 212.2.12.254:23)
R4#show tcp intercept  connections
Incomplete:
Client                Server                State    Create   Timeout  Mode

Established:
Client                Server                State    Create   Timeout  Mode
R4#
*Aug  3 22:15:38.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug  3 22:15:38.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
*Aug  3 22:15:39.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
R4#
*Aug  3 22:15:39.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#show tcp intercept  connections
Incomplete:
Client                Server                State    Create   Timeout  Mode
192.168.45.5:46993    212.2.12.254:23       SYNRCVD  00:00:03 00:00:01 W

Established:
Client                Server                State    Create   Timeout  Mode
R4#
*Aug  3 22:15:44.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug  3 22:15:44.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
R4#
*Aug  3 22:15:47.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
*Aug  3 22:15:47.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#
*Aug  3 22:15:52.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug  3 22:15:52.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)

A Networker Blog

How to Configure NTP with authentication

We are going to configure NTP Authentication on router R5 and R6 with router R5 being the time server.
Configure such that router R6 has a stratum level of 5. Use the password ‘time’ for your authentication.

For this step we are going to configure R5 to be our NTP master.

We are then going to configure R6 to use R5 as its authenticated time server.

First we will set the clock on R5.

This is done under the enable mode, not under the config mode. Remember that the time is entered as military time, based on a 24 hour clock.

R5#clock set 13:39:00 1 Aug 2007

Now that the clock is set we want R5 to act as the NTP master. We are told that R6 should have a stratum of 5. In order for R6 to have a stratum of 5 our master will need a stratum of 4. Anyone who gets the time off of the master will have the master’s stratum plus 1.

R5(config)#ntp master 4

Then we are going to set R6 to use R5 as its time server. We can point to any reachable IP address on R5, we suggest that you use a Loopback interface if possible since Loopbacks never flap.

R6(config)#ntp server 110.5.5.5

We do not have any authentication configured yet, but we should check to make sure our NTP is synchronized before adding it.
We can check to make sure R6 is synchronized with R5 by issuing the show ntp status command.

R6#show ntp status
Clock is synchronized, stratum 5, reference is 110.5.5.5
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is CA5B0BC7.0E24598C (13:40:23.055 UTC Wed Aug 1 2007)
clock offset is -0.6770 msec, root delay is 89.63 msec
root dispersion is 3.30 msec, peer dispersion is 2.58 msec

Now that we know our NTP is synchronizing we can go ahead and add the authentication. NTP authentication is a little different than most. For NTP authentication it is the client that authenticates the master, not the other way around. The master only need to be told the authentication-key that it will use and nothing else. We will configure the authentication-key on R5 using the specified password of ‘time’.

R5(config)#ntp authentication-key 1 md5 time

The majority of the authentication commands go on the client, R6. We need to tell R6 to authenticate and what authentication-key to use

R6(config)#ntp authenticate
R6(config)#ntp authentication-key 1 md5 time

We then need to tell R6 to only accept the server if it uses key 1 – the same key number we are specifying in the authentication-key command. This command will override the original ntp server 5.1.1.1 command.

R6(config)#ntp server 110.5.5.5 key 1

Finally on R6 we need to tell it to only trust key 1.

R6(config)#ntp trusted-key 1

Now that we have our NTP authentication configured we can check to make sure it is working by issuing the show ntp associations detail command on R6.

R6#show ntp associations detail
110.5.5.5 configured, authenticated, our_master, sane, valid, stratum 16
ref ID 127.127.7.1, time CA5B0BED.06292161 (13:41:01.024 UTC Wed Aug 1 2007)
our mode client, peer mode server, our poll intvl 128, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 376, sync dist 48.813
delay 89.68 msec, offset -4.3660 msec, dispersion 3.95
precision 2**18, version 3
org time CA5B0C47.05C2F056 (13:42:31.022 UTC Wed Aug 1 2007)
rcv time CA5B0C47.1B3444A9 (13:42:31.106 UTC Wed Aug 1 2007)
xmt time CA5B0C46.F706E1D6 (13:42:30.964 UTC Wed Aug 1 2007)
filtdelay =    89.68   89.63   89.84  118.70  114.38   93.61  110.18  108.02
filtoffset =   -4.37   -0.68   -0.85  -14.94  -12.91   -2.53    9.75   -9.48
filterror =     0.03    1.01    1.02    1.04    1.05    1.07    1.08    1.10


A Networker Blog