Last week, i had to face 4 Days breakout in one of the big Bank here in Indonesia. They had VPN Routers that had reached its capacity. What was the Impact? very-very-very high utilization in every morning, so that sometimes the routers would eventually crashed!!! and followed by the a tons of reports from the branch offices that telling us they couldn't connect to the HQ. What a great experience there.
Btw, our team agreed to use CAC feature to limit the Maximum SA in IKE Phase 1, to prevent all the negotiation flooding at the same time, especially in the Morning. Why only IKE Phase 1, because the IOS that thay had only supported on this one, they didn't want to upgrade it for some reason :(
Based on that experience, I would like to write the Configuration, that might be useful, in term of deploying a IPSec VPN. Let's just get straight to the Configuration Task Here:
- Configure SW, as a Server, to have default route to 10.14.12.254. This address should be the VIP for the VLAN 12 Segment.
- Traffic From 150.13.8.0/24 to the 150.13.7.0/24 & 10.13.4.0/24 to 150.13.7.0/24 should be encrypted
- R1 & R2 act as a terminating VPN from all branch offices, configure the Stateful IPsec VPN High Availability Enhancements to both terminating VPN routers using HSRP. R4 should peer to the 10.14.123.254 for the VPN.
Answer
hostname Rack14R1
!
track 1 interface FastEthernet0/1 line-protocol
track 2 interface FastEthernet0/0 line-protocol
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key CISCO address 0.0.0.0 no-xauth
crypto isakmp fragmentation
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 5 periodic
!
crypto ipsec transform-set TS_3DES_MD5 esp-3des
esp-md5-hmac
!
crypto ipsec profile IPSEC_PROFILE
set
transform-set TS_3DES_MD5
!
ip access-list extended ACL_VPN
permit ip
150.14.7.0 0.0.0.255 150.14.8.0 0.0.0.255
permit ip
150.14.7.0 0.0.0.255 10.14.4.0 0.0.0.255
!
crypto map CMAP 1 ipsec-isakmp
set peer
150.14.4.4
set
transform-set TS_3DES_MD5
match
address ACL_VPN
!
ipc zone default
association 1
no shutdown
protocol sctp
local-port 29281
local-ip 10.14.123.1
remote-port 29281
remote-ip 10.14.123.2
!
redundancy inter-device
scheme standby VPN_HA_OUT
security ipsec IPSEC_PROFILE
!
!
interface FastEthernet0/0
ip address
10.14.123.1 255.255.255.0
standby
delay minimum 10 reload 15
standby 1
ip 10.14.123.254
standby 1
preempt
standby 1
name VPN_HA_OUT
standby 1
track 1 decrement 10
standby 1
timers 1 3
crypto map CMAP redundancy
VPN_HA_OUT stateful
!
interface FastEthernet0/1
ip address
10.14.12.1 255.255.255.0
standby
delay minimum 10 reload 120
standby 2
ip 10.14.12.254
standby 2
preempt
standby 2
name VPN_HA_IN
standby 2
track 2 decrement 10
standby 2
timers 1 3
!
ip route 150.14.7.0 255.255.255.0 10.14.12.7
!
end
|
hostname Rack14R2
!
track 1 interface FastEthernet0/1 line-protocol
track 2 interface FastEthernet0/0 line-protocol
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key CISCO address 0.0.0.0 no-xauth
crypto isakmp fragmentation
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 3 periodic
!
crypto ipsec transform-set TS_3DES_MD5 esp-3des
esp-md5-hmac
!
crypto ipsec profile IPSEC_PROFILE
set
transform-set TS_3DES_MD5
!
ip access-list extended ACL_VPN
permit ip
150.14.7.0 0.0.0.255 150.14.8.0 0.0.0.255
permit ip
150.14.7.0 0.0.0.255 10.14.4.0 0.0.0.255
!
crypto map CMAP 1 ipsec-isakmp
set peer
150.14.4.4
set
transform-set TS_3DES_MD5
match
address ACL_VPN
!
ipc zone default
association 1
no shutdown
protocol sctp
local-port 29281
local-ip 10.14.123.2
remote-port 29281
remote-ip 10.14.123.1
!
redundancy inter-device
scheme standby VPN_HA_OUT
security ipsec IPSEC_PROFILE
!
interface FastEthernet0/0
ip address
10.14.123.2 255.255.255.0
standby
delay minimum 10 reload 15
standby 1
ip 10.14.123.254
standby 1
preempt
standby 1
name VPN_HA_OUT
standby 1
track 1 decrement 10
standby 1
timers 1 3
delay
100000
crypto map CMAP redundancy
VPN_HA_OUT stateful
!
interface FastEthernet0/1
ip address
10.14.12.2 255.255.255.0
standby
delay minimum 10 reload 120
standby 2
ip 10.14.12.254
standby 2
preempt
standby 2
name VPN_HA_IN
standby 2
track 2 decrement 10
standby 1
timers 1 3
!
!
ip route 150.14.7.0 255.255.255.0 10.14.12.7
!
end
|
R4 (Branch)
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key CISCO address 10.13.123.254 no-xauth
crypto isakmp fragmentation
crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set TS_3DES_MD5 esp-3des
esp-md5-hmac
!
crypto map CMAP local-address Loopback0
crypto map CMAP 1 ipsec-isakmp
set peer
10.13.123.254
set
transform-set TS_3DES_MD5
match
address ACL_VPN
!
ip access-list extended ACL_VPN
permit ip
10.13.4.0 0.0.0.255 150.13.7.0 0.0.0.255
permit ip
150.13.8.0 0.0.0.255 150.13.7.0 0.0.0.255
!
interface Virtual-Template34
crypto map
CMAP
!
end
|
Verification
After we applied
the statefull configuration, there were log messages appear on the Active
Standby Router, which was R1 in this Case
%CRYPTO-5-IKE_SA_HA_STATUS: IKE sa's if any, for
vip 10.14.123.254 will change from
STANDBY to ACTIVE
%CRYPTO-5-IPSEC_SA_HA_STATUS: IPSec sa's if any,
for vip 10.14.123.254 will change from
STANDBY to ACTIVE
|
We can verify the
stateful IPSec HA using the following command, show redundancy inter-device.
Rack14R1#sh redundancy inter-device
Redundancy inter-device state:
RF_INTERDEV_STATE_ACT
Scheme:
Standby
Groupname: VPN_HA_OUT Group State: Active
Peer
present: RF_INTERDEV_PEER_COMM
Security:
Type: IPSec
Profile name: IPSEC_PROFILE
State: Ready
|
Rack14R2#sh redundancy inter-device
Redundancy inter-device state:
RF_INTERDEV_STATE_STDBY
Scheme:
Standby
Groupname: VPN_HA_OUT Group State: Standby
Peer
present: RF_INTERDEV_PEER_COMM
Security:
Type: IPSec
Profile name: IPSEC_PROFILE
State: Ready
|
Let see the Crypto
Map verification on both R1 and R2
Rack14R1#show crypto map
…
Redundancy Status:
Group: VPN_HA_OUT, Type:
Stateful HA, VIP: 10.14.123.254
Replay-interval: inbound:1000
outbound:100000
Crypto Map IPv4
"FastEthernet0/0-head-0" 65536 ipsec-isakmp
Map
is a PROFILE INSTANCE.
Peer = 10.14.123.2
Extended IP access list
access-list permit sctp host
10.14.123.1 port = 29281 host 10.14.123.2 port = 29281
Current peer: 10.14.123.2
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS
(Y/N): N
Transform sets={
TS_3DES_MD5: { esp-3des
esp-md5-hmac } ,
}
Reverse Route Injection Enabled
Crypto Map IPv4
"FastEthernet0/0-head-0" 65537 ipsec-isakmp
Map
is a PROFILE INSTANCE.
Peer = 10.14.123.2
Extended IP access list
access-list permit sctp host
10.14.123.1 port = 29282 host 10.14.123.2 port = 29282
Current peer: 10.14.123.2S
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS
(Y/N): N
Transform sets={
TS_3DES_MD5: { esp-3des
esp-md5-hmac } ,
}
Reverse Route Injection Enabled
Interfaces using crypto map FastEthernet0/0-head-0:
|
Rack14R2#show crypto map
..
Redundancy Status:
Group: VPN_HA_OUT, Type:
Stateful HA, VIP: 10.14.123.254
Replay-interval: inbound:1000
outbound:100000
Crypto Map IPv4
"FastEthernet0/0-head-0" 65536 ipsec-isakmp
Map
is a PROFILE INSTANCE.
Peer = 10.14.123.1
Extended IP access list
access-list permit sctp host
10.14.123.2 port = 29281 host 10.14.123.1 port = 29281
Current peer: 10.14.123.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS
(Y/N): N
Transform sets={
TS_3DES_MD5: { esp-3des
esp-md5-hmac } ,
}
Reverse Route Injection Enabled
Crypto Map IPv4
"FastEthernet0/0-head-0" 65537 ipsec-isakmp
Map
is a PROFILE INSTANCE.
Peer = 10.14.123.1
Extended IP access list
access-list permit sctp host
10.14.123.2 port = 29282 host 10.14.123.1 port = 29282
Current peer: 10.14.123.1
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS
(Y/N): N
Transform sets={
TS_3DES_MD5: { esp-3des
esp-md5-hmac } ,
}
Reverse Route Injection Enabled
Interfaces using crypto map FastEthernet0/0-head-0:
|
Lets generate
traffic from SW2 to the SW1, the traffic will be Encrypted For sure. Initially,
R4 will create VPN tunnel with R1 as an ACTIVE and R2 as a STANDBY
Rack14R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst
src state conn-id status
10.14.123.254
150.14.4.4 QM_IDLE 1002 ACTIVE
10.14.123.2
10.14.123.1 QM_IDLE 1001 ACTIVE
|
Rack14R2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst
src state conn-id status
10.14.123.254
150.14.4.4 QM_IDLE 1002 STDBY
10.14.123.2
10.14.123.1 QM_IDLE 1001 ACTIVE
|
Rack14R4#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst
src state conn-id status
10.14.123.254
150.14.4.4 QM_IDLE 1002 ACTIVE
|
For testing purpose, I generated Telnet traffic from SW2-SW1, which
would use VPN tunnel from R4 to R1[Active]+R2[Standby] in this case. And then I
turn of the R1, which was in Active state for the IPSec VPN Sessions.
Rack14SW2#
Rack14SW2#telnet 150.14.7.7 /source-interface
loopback 0
Trying 150.14.7.7 ... Open
User Access Verification
Password:
Rack14SW1#show users
Line User Host(s) Idle Location
0 con
0 idle 00:00:10
* 98 vty 0 idle 00:00:00 150.14.8.8
Interface User Mode Idle Peer Address
Rack14SW1#
..<2 later="later" seconds="seconds">..
Rack14SW1#
|
Rack14SW2#ping 150.14.7.7 source loopback 0 rep
100000
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to
150.14.7.7, timeout is 2 seconds:
Packet sent with a source address of 150.14.8.8
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
Success rate is 97 percent (115/118), round-trip
min/avg/max = 88/131/260 ms
|
Suddenly R2 become an Active HSRP and there was a log message telling
that the IPSec traffic from SW2 Landing on the R2 interface now. R2 will
eventually request R4 to re-negotiate the IKE again
%HSRP-5-STATECHANGE: FastEthernet0/1 Grp 2 state
Standby -> Active
%HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state
Standby -> Active
%CRYPTO-5-IKE_SA_HA_STATUS: IKE sa's if any, for
vip 10.14.123.254 will change from STANDBY to ACTIVE
%CRYPTO-5-IPSEC_SA_HA_STATUS: IPSec sa's if any,
for vip 10.14.123.254 will change from STANDBY to ACTIVE
|
Rack14R2#show redundancy inter-device
Redundancy inter-device state:
RF_INTERDEV_STATE_ACT
Scheme:
Standby
Groupname: VPN_HA_OUT Group State: Active
Peer
present: RF_INTERDEV_PEER_NO_COMM
Security:
Type: IPSec
Profile name: IPSEC_PROFILE
State: Ready
|
Whoooa, what a great feature isn't it? Well, in the Production network, we also have to take a consideration about the scalability and Capacity besides the Technology itself. We have to have a contingency plan just about every single outage possibility that might or will occur in the future.
If we talked about the VPNs technology, especially in Cisco World, we might have a lot of option, you can name it, VTI, EzVPN, DMVPN, GETVPN, FlexVPN, where each of them has a specific advantage in the deployment, and it is indeed depend on how the traffic flow will work. This means that to get the real benefit from this technology, we have to involved when the company want to start their VPN Implementation, which is in Architectural or in Design Phase.
But, I'm sure some of us, will face the situation, where some organizations are already deploying their own solution from a long time, and we have to deal or stick with their technology.
The answer to deal with that kind of situation, in my oppinion, is to give them all the good possibility solution based on their existing technology, and also give them advice wheater they want to consider the future deployment.
well that is all i guess, I hope this has been informative and i'd like to thank you for your time to read the blog ;)
