BR200 failing to establish VPN tunnel to CVG

  • 1
  • Question
  • Updated 5 months ago
We are having issues establishing a IPSEC VPN between a BR200 and CVG . As you can see from the logs below the BR200 is failing to reach phase 2 of the VPN connection. I’ve rebooted the BR200, but this has proved unsuccessful and licencing is correct. 

Anyone go any ideas how to fix this without having to reboot the CVG? 

2017-05-09 13:58:15:Phase 1 deleted(10.99.9.38[4500]->203.89.205.101[4500])

2017-05-09 13:58:15:Phase 1 started(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 13:58:16:Phase 1 established(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 13:58:16:Xauth exchange start(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:00:17:Phase 1 deleted(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:00:17:Phase 1 started(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:00:17:Phase 1 established(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:00:17:Xauth exchange start(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:02:17:Phase 1 deleted(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:02:17:Phase 1 started(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:02:17:Phase 1 established(10.99.9.38[4500]->203.89.205.101[4500])
2017-05-09 14:02:17:Xauth exchange start(10.99.9.38[4500]->203.89.205.101[4500])




Photo of chris.prehn

chris.prehn

  • 2 Posts
  • 0 Reply Likes

Posted 1 year ago

  • 1
Photo of Sam Lynn

Sam Lynn, Moderator

  • 96 Posts
  • 12 Reply Likes
Hello Chris,

It looks like you are failing at Phase 1. There are four likely reasons why Phase 1 would fail:

1. The IP connectivity has failed between VPN client and Server.

           - Use the ping command to verify IP connectivity between the VPN client and the server.If the ping fails, you should begin to troubleshoot IP routing between the two peers. Remember, however, that ping only verifies reachability for ICMP Echo Request and Response messages.

2. The VPN server IP was mis-configured

            - If you run the command "show running-config | include gateway", you'll want to check the gateway IP address and the remote IP address. Please double check it was the VPN server IP address based on your network design.

3. The UDP 500/4500 (ISAKMP) was blocked by firewall on VPN client side;

             - If the VPN client was behind firewall, and firewall does not permit UDP port 500/4500 (ISAKMP), IKE negotiation will fail. This should be checked on the firewall of the VPN client side.

 

4. The UDP 500/4500 (ISAKMP) was NOT mapped to the VPN server by firewall on VPN server side;

              - The VPN server IP will be unreachable if it was behind the firewall. So the VPN server’s IP should be configured as the reachable IP address and the UDP500/4500 (ISAKMP) should be mapped to the VPN server by the firewall.


Hope this helps!
Photo of chris.prehn

chris.prehn

  • 2 Posts
  • 0 Reply Likes

Hi Sam

I ended up raising this with Aerohive engineering and they have identified that it is a fault with the CVG. They described it as follows, "we discovered that the CVG is ‘stuck’ and not showing any information about the VPN tunnels". I suspect that the routing table is not getting updated when you add a new device. Hopefully Aerohive can workout why and produce a fix to stop it.

Thanks for your help.

Regards

Chris

Photo of Nick M

Nick M, Employee

  • 8 Posts
  • 1 Reply Like
Chris,

By chance, can you reference the case number where you were told that?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I suspect Chris was referring to case 158868.
(Edited)
Photo of Nick M

Nick M, Employee

  • 8 Posts
  • 1 Reply Like
That's what I suspected. I was curious, as a customer referenced this post. Thanks Nick.