Site-Site VPN between Cisco ISR 4331 and Cisco RV340. Connection lasts only 5 seconds.

[varunoberoi]

I am trying to setup a site-site vpn connection between two branch offices. I have a cisco ISR 4331 in main office and a Cisco RV340 in my branch office.

The connection between keeps cycling between UP and Down. It stays UP for maximum 5 seconds and then goes down again. 30 seconds later the connection is retried automatically and goes UP again and repeats infinitely.

IPSec profile in RV340 is:

All VPN commands run in ISR 4331 at Main Office:

!------------- Common-S2S VPN Config --------

crypto ikev2 proposal local-vpn-proposal
encryption aes-cbc-128
integrity sha1
group 2
exit

crypto ipsec transform-set local-vpn-TransformSet esp-aes
mode tunnel
exit

crypto ikev2 policy local-vpn-policy
proposal local-vpn-proposal
match address local <Main-Office-IP>
exit

access-list 121 permit ip 10.1.0.0 0.0.15.255 10.2.0.0 0.0.15.255
access-list 121 permit esp host <Branch-Office-IP> host <Main-Office-IP>
access-list 121 permit udp host <Branch-Office-IP> eq isakmp host <Main-Office-IP>
access-list 121 permit udp host <Branch-Office-IP> eq non500-isakmp host <Main-Office-IP>

crypto ikev2 keyring hansi-vpn-keyring
peer <Branch-Office-IP>
address <Branch-Office-IP>
pre-shared-key <Shared_KEY>
exit
exit

crypto ikev2 profile hansi-vpn-profile
match address local <Main-Office-IP>
match identity remote address <Branch-Office-IP> 255.255.255.255
authentication remote pre-share
authentication local pre-share
lifetime 28800
dpd 10 5 on-demand
keyring local hansi-vpn-keyring
exit

crypto ipsec profile hansi-vpn-IPsecProfile
set transform-set local-vpn-TransformSet
set ikev2-profile hansi-vpn-profile
set security-association lifetime seconds 28800
exit

int tunnel 11
ip address 169.254.1.1 255.255.255.255
tunnel mode ipsec ipv4
ip tcp adjust-mss 1350
tunnel source <Main-Office-IP>
tunnel destination <Branch-Office-IP>
tunnel protection ipsec profile hansi-vpn-IPsecProfile
exit

! ------------------------------------------------------------------------------
! Static routes

ip route 10.2.0.0 255.255.240.0 Tunnel 11

[Rob Ingram]

@varunoberoi 

You've got Perfect Forward Secrecy (PFS) enabled on the RV340, but it does not appear to be configured on the ISR4331.

Disable PFS on the RV340 or enable PFS on the ISR4331 and try again (Shut/no shut the tunnel interfaces).

DH group 2 is weak, consider something stronger for IKE Phase 1 (SA_INIT)

You've not provided the full RV340 configuration, I assume it's a Route Based VPN (with a tunnel interface)?

If that doesn't work enable ikev2 debugs on the ISR4331 and provide the output here for review.

[varunoberoi]

Sorry could not reply quicker. Just got caught up at work.

I tried disabling PFS in RV340 but the connection broke again after about 10 seconds.

I enabled it again, changed the DH group to 14 as 2 and 14 are the only options available in RV340. I also changed commands in ISR 4331 to match. The settings are as below. Connection still breaks in 5-10 seconds.

I also have another S2S VPN to Azure from the ISR 4331 and a S2S VPN from RV340 as well.

The int br output in ISR:

debug crypto ikev2 output is attached.

This is my complete RV340 settings:

ISR 4331 commands:

[Rob Ingram · Accepted solution]

@varunoberoi 

You've configured the ISR as a Route Based VPN (with a tunnel interface) but the RV340 is a Policy Based VPN (with a crypto map).

No idea if the RV340 supports tunnel interfaces, so perhaps change the ISR to a Policy Based VPN. Just ensure the crypto map ACL on the ISR is the exact mirror of the RV340.

[varunoberoi]

One question:

Even if the problem is about the route based and policy based mismatch. Shouldn't that affect just the routing part of the VPN? Can it also cause connection breakage?

[Rob Ingram]

@varunoberoi 

No, the tunnel interface will send the proxy ID as 0.0.0.0/0.0.0.0, whereas the Policy Based VPN on the RV340 will be sending a proxy ID as the local/remote networks (10.1.0.0 and 10.2.0.0), so will mismatch.

[varunoberoi]

First off, thanks for all the help. Some progress at last but I'm still making some mistake.

I am running these commands on the ISR to setup Policy Based VPN. I made no changes in the RV340.

I now have a stable VPN connection between them. But the the crypto session status is "UP-IDLE" and doesn't change. Also, I cannot ping the RV340 from the ISR.

It might be a routing issue but I configured routing on ISR. RV340 support static routing and I have added a similar route in that. Screenshot below:

These are the commands I am running on the ISR.

!-----------Create an access list------------
access-list 102 permit ip 10.1.0.0 0.0.15.255 10.2.0.0 0.0.15.255
access-list 102 permit esp host 112.133.241.9 host 117.242.47.19
access-list 102 permit udp host 112.133.241.9 eq isakmp host 117.242.47.19
access-list 102 permit udp host 112.133.241.9 eq non500-isakmp host 117.242.47.19

!-----------Create a IKEV2 Proposal------------
crypto ikev2 proposal local-vpn-proposal
encryption aes-cbc-256
integrity sha1
group 14
exit

!-----------Create a transform-set------------
crypto ipsec transform-set local-vpn-transformset esp-aes 256 esp-sha-hmac
mode tunnel
exit

crypto ikev2 policy local-vpn-policy
proposal local-vpn-proposal
match address local 117.242.47.19
exit

!-----------Create Pre-Shared key------------
crypto ikev2 keyring hansi-vpn-keyring
peer 112.133.241.9
address 112.133.241.9
pre-shared-key <SHARED_KEY>
exit
exit

!---------- Create Ikev2 profile-------------
crypto ikev2 profile hansi-vpn-profile
match address local 117.242.47.19
match identity remote address 112.133.241.9 255.255.255.255
authentication remote pre-share
authentication local pre-share
lifetime 28800
dpd 10 5 on-demand
keyring local hansi-vpn-keyring
exit

!-----------Create a crypto map------------
crypto map hansi-vpn-crypto-map 100 ipsec-isakmp
set transform-set local-vpn-transformset
set ikev2-profile hansi-vpn-profile
set peer 112.133.241.9
set pfs group14
set security-association lifetime seconds 28800
match address 102
exit

!-----------Apply crypto map to interface------------
int Dialer1
crypto map hansi-vpn-crypto-map
exit

!----- Configure IP Routing-----
ip route 10.2.0.0 255.255.240.0 Dialer1

  

[Rob Ingram]

@varunoberoi 

Edit ACL 102 and remove lines 2,3 and 4.

Shut down the tunnel interface, you aren't going to be using it.

If the VPN is established, run the command "show crypto ikev2 sa" and "show crypto ipsec sa" after you've generated the traffic.

You don't need specific routes for the remote networks, you just need a default route out of the outside interface on both devices.

If you've got NAT enabled, ensure traffic between the VPN networks is excluded.

[varunoberoi]

The tunnel is from another S2S with Azure. I have deleted it completely for now. 

After deleting the Azure VPN (Along with the tunnel) and removing lines 2,3 & 4 from ACL the session status is "UP-ACTIVE" in ISR and "UP" in RV340. But I still cannot ping anything between the two.

Debug log is attached.

Out from  "show crypto ikev2 sa" and "show crypto ipsec sa" is below:

OrionHisar#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA

Tunnel-id Local Remote fvrf/ivrf Status
1 117.242.47.19/500 112.133.241.9/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/491 sec

IPv6 Crypto IKEv2 SA

OrionHisar#show crypto ipsec sa

interface: Dialer1
Crypto map tag: hansi-vpn-crypto-map, local addr 117.242.47.19

protected vrf: (none)
local ident (addr/mask/prot/port): (10.1.0.0/255.255.240.0/0/0)
remote ident (addr/mask/prot/port): (10.2.0.0/255.255.240.0/0/0)
current_peer 112.133.241.9 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 117.242.47.19, remote crypto endpt.: 112.133.241.9
plaintext mtu 1422, path mtu 1492, ip mtu 1492, ip mtu idb Dialer1
current outbound spi: 0xC97BF8DC(3380345052)
PFS (Y/N): N, DH group: none

inbound esp sas:
spi: 0x29886D55(696806741)
transform: esp-256-aes esp-sha-hmac ,
--More--
*Jul 8 10:55:28.235: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed sta in use settings ={Tunnel, }
conn id: 2003, flow_id: ESG:3, sibling_flags FFFFFFFF80000048, crypto map: hansi-vpn-crypto-map
sa timing: remaining key lifetime (k/sec): (4608000/28297)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

inbound ah sas:

inbound pcp sas:
--More--
*Jul 8 10:55:30.251: %LINK-3-UPDOWN: Interface GigabitEthernet0/0/0, changed st p
outbound esp sas:
spi: 0xC97BF8DC(3380345052)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2004, flow_id: ESG:4, sibling_flags FFFFFFFF80000048, crypto map: hansi-vpn-crypto-map
sa timing: remaining key lifetime (k/sec): (4608000/28297)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)

outbound ah sas:

outbound pcp sas:

[Rob Ingram]

@varunoberoi 

So I can see you've ESP SAs, so the tunnel has been established....but the encap|decap counters have not increased. Usually this is a NAT or routing issue, check/confirm your NAT.

[varunoberoi]

Hmm.. I run these commands when creating a WAN and DHCP for clients:

! NAT settings - Forwarding internet traffic from DHCP clients to WAN

interface GigabitEthernet 0/0/1
ip nat inside
exit

interface dialer 1
ip nat outside
exit

ip nat inside source list 1 interface dialer 1 overload
access-list 1 permit 10.1.0.0 0.0.15.255
exit

The output for show ip nat translations is:

OrionHisar#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 117.242.47.19:5064 10.1.0.2:60809 52.231.157.226:443 52.231.157.226:443
tcp 117.242.47.19:5069 10.1.0.2:63495 54.169.61.200:443 54.169.61.200:443
tcp 117.242.47.19:5093 10.1.0.2:55155 192.168.1.73:554 192.168.1.73:554
tcp 117.242.47.19:5100 10.1.0.2:55131 192.168.1.73:554 192.168.1.73:554
tcp 117.242.47.19:5095 10.1.0.2:55034 52.239.161.42:443 52.239.161.42:443
tcp 117.242.47.19:5092 10.1.0.2:55148 192.168.1.86:554 192.168.1.86:554
udp 117.242.47.19:5152 10.1.0.2:54802 8.8.8.8:53 8.8.8.8:53
tcp 117.242.47.19:5094 10.1.0.2:55165 192.168.1.87:554 192.168.1.87:554
tcp 117.242.47.19:5099 10.1.0.2:55125 192.168.1.86:554 192.168.1.86:554
udp 117.242.47.19:5153 10.1.0.2:58933 8.8.8.8:53 8.8.8.8:53
tcp 117.242.47.19:5065 10.1.0.2:63480 13.67.116.10:443 13.67.116.10:443
tcp 117.242.47.19:5089 10.1.0.2:55129 192.168.1.91:554 192.168.1.91:554
tcp 117.242.47.19:5101 10.1.0.2:55151 192.168.1.91:554 192.168.1.91:554
tcp 117.242.47.19:5088 10.1.0.2:55178 192.168.1.86:554 192.168.1.86:554
tcp 117.242.47.19:5062 10.1.0.2:55136 192.168.1.88:554 192.168.1.88:554
icmp 117.242.47.19:1 10.1.0.2:1 10.2.0.1:1 10.2.0.1:1
tcp 117.242.47.19:5096 10.1.0.2:55035 52.239.161.42:443 52.239.161.42:443
tcp 117.242.47.19:5098 10.1.0.2:55119 192.168.1.87:554 192.168.1.87:554
tcp 117.242.47.19:5091 10.1.0.2:55143 192.168.1.87:554 192.168.1.87:554
tcp 117.242.47.19:5090 10.1.0.2:55159 192.168.1.88:554 192.168.1.88:554
tcp 117.242.47.19:5068 10.1.0.2:60449 13.76.243.239:443 13.76.243.239:443
icmp 117.242.47.19:3 10.1.0.2:1 10.2.0.6:1 10.2.0.6:3
Total number of translations: 22

What commands will I need to run?

[Rob Ingram]

@varunoberoi 

All your traffic egressing the wan interface is natted behind the interface, so you need to deny traffic in your NAT list. Example:

access-list 1 deny 10.1.0.0 0.0.15.255 10.2.0.0 0.0.15.255access-list 1 permit 10.1.0.0 0.0.15.255
exit

Ensure the deny rule is above the permit rule, this way any traffic between those defined networks will not be translated and will be routed. Any traffic not matching the first NAt rule will hit the 2nd NAT rule and will be translated.

You may need something similar on the other router.

[varunoberoi]

Yup, that was it. Got it to work. Thanks!

[balaji.bandi]

What are the Logs show when the connection disconnect or VPN terminated.

i would first compare the config.