How do I tunnel the guest SSID back to a central location?

  • 1
  • Question
  • Updated 5 years ago
  • Answered
  • (Edited)
I have several remote sites, but would like to offer guest wireless that is tunneled back to a single location. I enabled identity based access, but understand that GRE does not do NAT traversal.

So...If I have two SSID's, one for employees that utilizes the local building LAN, how do I tunnel the guest SSID back to a central location?

I have this sneaking feeling that I'm missing something obvious.
Photo of Benjamin Lambert

Benjamin Lambert

  • 27 Posts
  • 5 Reply Likes

Posted 5 years ago

  • 1
Photo of Adam Conway

Adam Conway

  • 101 Posts
  • 55 Reply Likes
Have you tried our L2 VPN solution, this should provide a similar capability to what you want to do with the GRE tunnels.
Photo of Benjamin Lambert

Benjamin Lambert

  • 27 Posts
  • 5 Reply Likes
Aaaaaaaah, see, I knew I was missing something obvious! Yes, this looks much more like I wanted it to
Photo of Benjamin Lambert

Benjamin Lambert

  • 27 Posts
  • 5 Reply Likes
Got this working fairly easily thanks to your suggestion, and it works slick. My biggest issue was the not so obvious (but documented) need to manually make the APs either VPN clients or servers.

The other thing in the documentation that would have been nice was the ports that need to be open for the VPN traffic (UDP 500 and maybe UDP 4500). This took me a while to figure out what to publish and I sort of expected it to be in the help docs.

Anyway, as we say...working is good!

Thanks again
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Hi Benjamin,

I was able to find that we publish the ports used for L2/L3 VPN in Chapter 6--Traffic Types (as well as the ports used for all other Aerohive traffic/devices) of our Deployment Guide which can be found here. You are right though, it would be helpful if our help system mentioned the ports used for specific configuration senarios, or at least the most common ones such as VPN. I will send a note to our Technical Publications team with this suggestion.

When I ran a search of "4500" in the help system, I was able to see that we do make mention of the fact that UDP ports 500 and 4500 need to be open for VPN negotiation. However, unless you were looking at the contextual help for the "Show IKE SA" diagnostic in the HiveManager, this does seem sort of tucked away.

Show IKE Event

View the most recent events that took place during IKE phase 1 and phase 2 negotiations between a VPN client and VPN server. If the VPN peers cannot establish a tunnel, you can view the IKE events to gain insight into what the problem might be. You can see up to a maximum of 12 events.

Show IKE SA

View the cookies and creation times of SAs (security associations) established during IKE phase 1 negotiations between a VPN client and VPN server. If there is no SA, then the negotiations were either incomplete or unsuccessful. Use the Show IKE Event option to investigate and check the log messages for more details. Other VPN tunnel troubleshooting steps that you can take are to ping the VPN client from the VPN server (and vice versa), and check that any intervening firewall permits the default ISAKMP (IKE) and the NAT-Traversal ports: UDP 500 and UDP 4500.

Hope this helps
Photo of Benjamin Lambert

Benjamin Lambert

  • 27 Posts
  • 5 Reply Likes
That's good to know that it's somewhere. My suggestion would be to mention it somewhere in the "VPN Service Settings" section of help. Or even as a little blurb on the setup page itself.

Either way, thank you for listening to the suggestion and digging a little further.
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Hi Benjamin,

Sorry, i wan't specific in my response, but my request to Technical Publications was to add it to the VPN Services help page. You're right in that it is the most visible, logical location for this information.