Wireless Access

Good Morning Community!

My apologies in advance, I am rather new to Aruba products, as well as more advanced networking in general.

I am having an issue with a site-to-site VPN that I just cannot figure out.

We have two sites, one using a 650 controller, and one using a 620 controller.  The VPN between the sites is connecting, but we are experiencing a lot of delay/loss with connections between the sites.

If I run a ping from our linux server on one end to the controller on the other end of the VPN (pinging the local address of the controller), I am noticing that I consistantly get gaps in the icmp sequence of about 20 packets or so, and the ping will then continue from there.  This will occur roughly every 30 packets, so we end up with ~40% packet loss.  It does not matter which direction I go, and if I run a ping in both directions at the same time, both freeze at the same time.

During these gaps in ping, all traffic across the site-to-site tunnel freezes as well.  Essentially, we run an ssh connection across the tunnel to our application.  During these gaps, the application will freeze as well.  When the ping resumes, the application resumes as well, and does "catch up", processing the keystrokes made by the user.

We do have a few other paired sites running a similar configuration (with the exception that these other sites are running 620 controllers on both ends... we had to install a 650 in the one site because of the number of AP's they have), and I have compared the VPN settings, and as far as I can tell, they are configured the same.

We do also have a pp2p vpn configured for remote access to each site, and users connecting remotely do not experience any issues, only connections made across the site-to-site tunnel.

Now that I have verified that the configuration is the same as other working sites, I was hoping for some troubleshooting advice to see if I can isolate what is happening to the tunnel, and hopefully resolve the issue.

I should also mention that the sites used to run with Cisco 1811 routers, and did not have any issues with their tunnel.  We recently switched to the Aruba controllers as they wanted to add wireless.

(rtr001-siteA) #show crypto map

Crypto Map "GLOBAL-MAP" 10000 ipsec-isakmp
Crypto Map Template"default-dynamicmap" 10000
         IKE Version: 1
         lifetime: [300 - 86400] seconds, no volume limit
         PFS (Y/N): N
         Transform sets={ default-transform, default-aes }
Crypto Map "GLOBAL-IKEV2-MAP" 10000 ipsec-isakmp
Crypto Map Template"default-rap-ipsecmap" 10001
         IKE Version: 2
         IKEv2 Policy: 10006
         lifetime: [300 - 86400] seconds, no volume limit
         PFS (Y/N): N
         Transform sets={ default-rap-transform }

(rtr001-siteA) #show crypto-local ipsec-map

Crypto Map Template"siteA--siteB" 100
         IKE Version: 2
         IKEv2 Policy: 10006
         lifetime: [300 - 86400] seconds, no volume limit
         PFS (Y/N): Y (Use the 1024-bit Diffie Hellman prime modulus group
         Transform sets={ default-1st-ikev2-transform }
         Peer gateway: 206.xxx.xxx.xxx
         Interface: VLAN 252
         Source network: 10.aa.aa.0/255.255.255.0
         Destination network: 10.bb.bb.0/255.255.255.0
         Pre-Connect (Y/N): Y
         Tunnel Trusted (Y/N): Y
         Forced NAT-T (Y/N): Y

Any help / troubleshooting tips / advice would be greatly appreciated.

Thanks

Bryan W

Please open a TAC case so that they can rule out a configuration issue..

eightender,

I hope you found a solution after nearly a year since your post.  Your description sounds very familiar to a situation I was troubleshooting.  I found by watching the head-end (or responder side) that during the "freezes" as you put it, the IPSec tunnel was actually being dropped and completely re-initiated by the remote side (initiator).  The roughly 20 seconds of up-time I saw, which you also described, seemed to correspond to the default dead-peer detection (DPD) timer of 22 seconds.  It was then positively determined that the remote side's firewall was actively denying inbound DPD udp 4500 messages originated by the head-end.  I ended up doing the following on hundreds of remote Aruba controllers.

netdestination vpn.servers
  host 207.x.x.x
!
ip access-list session gateway.port
  any any svc-dhcp permit
  alias vpn.servers localip udp 4500 permit
!
interface gigabitethernet 1/5
        ip access-group gateway.port session
!

The above config allowed the DPD messages inbound to the port physically connected to the sites' ISP device (DSL modem, etc.)  Note also the allowance of dhcp in case the vlan interface is set to get its address from the ISP device dynamically.  The second line of the ACL can be applied to any such configuration by using the destination keyword "localip" instead of having to know the actual interface IP.

Bryan C.

Thanks so much for the reply.  Actually, to this point, we had not found a solution.  We had several sites set up prior to the one I posted about, which did not have any issues.  We also set up several sites with tunnels since, also with no issues.  We use(d) the same tunnel config, and same acl rules on all of our controllers, so we chalked it up as "one of those things", and firewall never even crossed my mind.  We just figured out a way around the issue for the site and moved on.

Fast forward to this week, and we ended up with another site with the same issue.  While looking for ideas, I came across my own old post (and noticed your suggestion), so I gave it a whirl... and am happy to report that it fixed the issue for both sites.

I read your suggestion, and applied the same concept to our controllers, although I just added an ACL rule to our ACL we apply to the uplink port, instead of setting up a destination etc.

I added the following to our ACL:

host <peer IP> any svc-natt permit 

since applying the change, I've been happily pinging a server on the other side of the tunnel for about a half hour now, with no loss, and the site is reporting that their connections to the other site are also stable.

From one Bryan to another (even spelt the right way :) ) thanks for taking the time to reply to such an old post... You've made my day!

Cheers

Bryan W.