Manual basic PepVPN setup tutorial?

#1

Sorry for these basic questions - just giving PepVPN a try for the first time.

I’m looking at this guide:

Under the “Configure on each SpeedFusion peer -” section, it doesn’t seem to mention using the Pre-Shared key under the graphic.

[quote] Name the Profile - This IDs the VPN
Enter the Remote ID of the remote Peplink Balance unit. The Remote ID is the Local ID of the other endpoint.
Enter the WAN IP/DDNS Host Name of Remote peer.[/quote]

If the preshared key wasn’t entered, is the only thing used for authentication the RemoteID? Or the RemoteID plus the VPN connection “name”? Is the VPN connection name used for authentication? Can someone give me a quick explanation of how the authentication handshake works so I can hopefully get a grasp of it.

For my first try, I have fusionhub solo in the cloud and one peplink br1 mini, only.

On the fusionhub solo, I take it I enter the remoteID of the peplink BR1, that was setup on the peplink BR1 when I first clicked the PepVPN tab, and then both devices have to have the exact same pepVPN connecton name to connect, is that correct?

For security, should both the pepVPN connection name and the LocalID of both the fusionhub solo and the BR1 mini be as long as possible and random?

Is there brute force protection built into pepVPN? How does it work?

When I setup the fusionhub solo, I was a bit shocked to see ~10,000 failed login attempts on the ssh port 22 when I setup a cloud instance before installing fusionhub. I wouldn’t want those brute forcing the pepVPN connection…

If I enter a preshared key, do I just generate a random string as long as possible (how long is permitted maximum) and enter the same key (?) on both the fusionhub solo and the br1 mini? Are there any considerations when generating the preshared key?

#2

Not basic at all.These are good questions that most don’t think about.

The preshared key is not needed to authenticate two devices only the
PepVPN Local ID is needed (at both ends). This ID (or the device serial number) is used to authenticate each device to the other (as part of the handshake process) and then once authentication is complete the 256bit AES tunnel is created (if you have enabled encryption in either profile) and all subsequent traffic is encrypted.

If you want to encrypt the handshake process too then entering a preshared key will achieve this - adding a layer of security.

Yes, arguably you should use a long PepVPN ID. It can be up to 254 characters long (no spaces). In practice though I would suggest that anything over 14 characters tends to be quite a challenge to brute force, especially if you mix case and add numbers.

On the Fusionhub profile you would enter the Local PepVPN ID of the BR1, and vice versa at the BR1 end. The name of the profile itself can be different / anything its used to describe the profile in the UI not as part of the authentication process.

For sure you don’t want the PepVPN IDs to be silly short (<8 characters) and you don’t want them to be simple. When I deliver peplink training on this, I tend to recommend checking the PepVPN IDs used against these brute force guide tools: https://howsecureismypassword.net/ http://passfault.com/

hsimp is about brute force guessing, passfault takes into consideration pattern matching and other approaches to password cracking take a look at what they think about some perhaps more obvious PepVPN IDs.
image

The last one, with its extra length case changes, special characters and numbers is pretty challenging to brute force yet easy to remember which is useful if you’re managing this manually. When InControl2 is used for SpeedFusion Management I’ve seen it use long complex ids and preshared keys automatically.

I’m not convinced there is active protection against brute forcing PepVPN currently - @Steve would likely be able to confirm that for us (and I’m sure he’ll correct any of my response here as needed too), however as there are no generally available software clients for PepVPN and as I understand it the proprietary PepVPN is quite heavily modified from IPSEC (of which it is a distant relation) there are technical hurdles there in building a tool to do it in the first place which would need to be overcome before any brute force attacks could commence.

Yeah, since hosting services IP blocks are well known, the moment you bring any virtual appliance online with port 22 open you’re going to get smashed. Obviously changing the ports for typical services makes things harder to find and I can’t think of a good reason to have the CLI/SSH console enabled on a Fusionhub anyway. PepVPN is non standard though which does make it less likely to be scanned for and targeted by the bad guys.

Yes nice and long (i expect its limited to 254 characters buy haven’t tested this), random with a mix of case and character type and you’ll be fine.

6 Likes
#3

Thanks Martin for a nice and detailed answer but I would want to touch on a few things relating to security:

  1. You can consider local ID as “username” except that we don’t use it like username, so to avoid confusion we never called it that way. As long as it is unique enough for you, any length should be fine. Also don’t forget that the local ID would be part of the identification of your connection on the PepVPN Status page, it is especially important if you allow multiple remote ID to connect to the same PepVPN profile, so having a very long local ID may make identifying between different remote connection difficult.
  2. We strongly advise users to put in the pre-share key (and as long as you feel comfortable) since it will be the “password” and would increase the security of the handshake process and as a result the data channels created would be much more secure as well.
  3. We do have some form of brute force attack protection by limiting only a max number of concurrent handshake connections to be created. Other than that it is as good as how secured our router is built to be :wink:
2 Likes
#4

Thanks very much for the excellent explanation.

To be sure I got it, if I have
Device
LocalID=Apple123
RemoteID=Orange456

Fusionhub
LocalID=Orange456
RemoteID=Apple123

for some bad guy to try and brute force either pepvpn, he would need to get both Apple123 and Orange456 at the same time to brute force in, is that correct?

(will use preshared key of course too but wanted to make sure I have the basics understood 100%)