cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
349
Views
0
Helpful
3
Replies

Unstable ezVPN behaviour with 887VAG+R7-K9

The 887VAG+R7-K9 router is giving me much grief.

This time it's the unstable ezVPN tunnel. Sometimes there seems to be an endless loop where a successful tunnel build-up seems impossible. A power-cycle might help, or a erase config->replace config does the trick.. The behavior is very erratic at best!

 

I am using several 887VAG+R7 units with different mobile operators in our country. I am hesitant to put more in the field because of this particular issue. All the units connect to some sort of ASA router (either a 5505 or a 5512-X). IOS image versions differ and do not seem to make any difference on the behavior. 

This is what you see at the ASA when things go south:

Jul 13 2015 09:59:50 713131 Group = X_Tunnel_Group, Username = User160, IP = 123.234.21.34, Received unknown transaction mode attribute: 28692
Jul 13 2015 09:59:50 713131 Group = X_Tunnel_Group, Username = User160, IP = 123.234.21.34, Received unknown transaction mode attribute: 28693
Jul 13 2015 09:59:50 713131 Group = X_Tunnel_Group, Username = User160, IP = 123.234.21.34, Received unknown transaction mode attribute: 28695
Jul 13 2015 09:59:58 713904 IP = 123.234.21.34, Received encrypted packet with no matching SA, dropping
Jul 13 2015 09:59:58 713201 Group = X_Tunnel_Group, Username = User160, IP = 123.234.21.34, Duplicate Phase 2 packet detected.  Retransmitting last packet.
Jul 13 2015 10:00:09 713201 Group = X_Tunnel_Group, Username = User160, IP = 123.234.21.34, Duplicate Phase 2 packet detected.  Retransmitting last packet.
Jul 13 2015 10:00:09 713904 IP = 123.234.21.34, Received encrypted packet with no matching SA, dropping
Jul 13 2015 10:00:09 713904 IP = 123.234.21.34, Received encrypted packet with no matching SA, dropping

 

This keep looping over and over... But the connection DID work fine at first. This just randomly manifested itself! It's driving me nuts! Our vast amount of 887VA units (ADSL) or 881 units (ethernet) never exhibit this behavior on the same ASA's.

This is the configuration of the 887VAG+R7 in question:

version 15.2
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname User160
!
boot-start-marker
boot-end-marker
!
no logging buffered
no logging console
!
aaa new-model
!
aaa session-id common
memory-size iomem 10
clock timezone Paris 1 0
clock summer-time DST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
no ip source-route
!
no ip bootp server
ip domain lookup source-interface Cellular0
ip domain name vodafone.nl
ip name-server 8.8.4.4
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
chat-script hspa-R7 "" "AT!SCACT=1,1" TIMEOUT 60 "OK"
license udi pid C887VAG+7-K9 sn FCZ1906C2S2
!
controller VDSL 0
 shutdown
!
controller Cellular 0
 gsm gps mode standalone
 gsm gps nmea
!
ip ssh version 2
!
crypto isakmp keepalive 60 5 periodic
!
crypto ipsec client ezvpn HOI
 connect auto
 group X_Tunnel_Group key <omitted> 
 mode network-extension
 peer 1.2.3.4
 username User160 password User160
 xauth userid mode local
!
interface Ethernet0
 no ip address
 shutdown
!
interface ATM0
 no ip address
 shutdown
 no atm ilmi-keepalive
!
interface FastEthernet0
 no ip address
!
interface FastEthernet1
 no ip address
!
interface FastEthernet2
 no ip address
!
interface FastEthernet3
 no ip address
!
interface Cellular0
 ip address negotiated
 encapsulation slip
 dialer in-band
 dialer idle-timeout 0
 dialer string hspa-R7
 dialer-group 1
 async mode interactive
 crypto ipsec client ezvpn VRI
!
interface Vlan1
 ip address 172.16.83.206 255.255.255.248
 no autostate
 crypto ipsec client ezvpn HOI inside
!
ip forward-protocol nd
no ip http server
ip http access-class 10
ip http authentication local
ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 Cellular0
!
ip sla 1
 icmp-echo 10.40.1.161 source-interface Vlan1
 frequency 300
ip sla schedule 1 life forever start-time now
access-list 10 remark CCP_ACL Category=17
access-list 10 remark VPN subnet
access-list 10 permit 172.18.0.0 0.0.0.255
dialer-list 1 protocol ip permit
no cdp run
!
control-plane
!
line con 0
 no modem enable
line aux 0
line 3
 exec-timeout 0 0
 script dialer hspa-R7
 modem InOut
 no exec
 rxspeed 21600000
 txspeed 5760000
line 6
 modem InOut
 no exec
 transport input all
 transport output all
 stopbits 1
 speed 4800
line vty 0 4
 access-class 10 in
 privilege level 15
 transport input ssh
!
end

 

 

These things really exhibit weird and random behavior at times which I can only blame the router for. Other variables (like mobile sims or operator brand) make no difference whatsoever. Of course the configuration could be at fault, however, the fact it leads to inconsistent behavior is something that strikes me as very odd. The only thing that keeps me clinging to these units is the fact that they support ezVPN with Network Extension Mode.

 

Has anyone seen this behavior and have they found a solution for it?

 

If you could advise it would be greatly appreciated.

 

Thanks in advance! 

 

 

3 Replies 3

Abaji Rawool
Level 3
Level 3

Hi,

From the messages it looks like the VPN peers are not in sync, the Router is sending encrypted packets fro the ASA but it has no ipsec SA for the same.

Could you check if the isakmp keep-alives are applied on both sides and if you can simultaneous debugs on both sides to see why the tunnel is going down.

HTH

Abaji.

 

 

Hallo Abaji,

 

Thank you for your insight and reply!

The DPD is enabled on both ends of the tunnel. The ASA has the DPD enabled in the tunnelgroup and the 887VAG+R7 has the line "crypto isakmp keepalive 60 5 periodic". I do believe that's the correct way to enable DPD... correct me if I am mistaken.

 

I did notice the confidence interval is different between the ASA and the 887VAG+R7. One is 30 seconds (ASA) and the 887VAG+R7 has 60 seconds. Could this cause this kind of trouble? Perhaps I am making the wrong assumption that one side concludes after 30 seconds a tunnel has dropped and the other side concludes it after 60 seconds. That shouldn't be a problem, right?

 

If it was a DPD issue however, I would suspect there being a lingering SA on the ASA. When looking at the ASA active SA's I noticed one IKE peer (the failing 887VAG+R7) with the state: "AM_TM_INIT_MODECFG_V6H".  The search to this particular state lead me to another forumpost which suggests the problem might be fragment/MTU related. Which could be it.. I am not sure.

 

What I do know is that the 887VAG+R7 thinks Phase 1 is completed while the ASA doesn't. That could very well be because of fragmented packets.

You are correct. 887VAG+R7 thinks Phase 1 is completed while the ASA doesn't.

Need to check debugs on both ends.

HTH

Abaji.