No, it means that when you run a VPN (encrypted tunnel) you need higher specification hardware to handle the bandwidth - regardless of your choice of platform. A box that can handle 50 Mb/s of unencrypted traffic may have problems with 10 Mb/s of encrypted traffic. A lot will depend on what VPN technology you use, what level of encryption you decide upon etc.

hi,

so there is no way the server can deny a second connection with same certificate?

cya

Vayatta may config their openvpn servers differently (perhaps using tap rather than tun).

You can use any non-overlapping RFC1918 (or even public if you really want) block for the address pool, but the way OpenVPN assigns addresses (it carves /30's out of that /24) is well documented by OpenVPN:

http://openvpn.net/index.php/open-source/faq/77-server/273-qifconfig-poolq-option-use-a-30-subnet-4-private-ip-addresses-per-client-when-used-in-tun-mode.html

ok, thanks.

then I had to screw it up something …..

Hi,
start with:
http://doc.pfsense.org/index.php/OpenVPN_Site_To_Site
Regards !

@jimp:

See attached. When you add a CSC/CSO (Not sure why the tab name was changed, it's now Client Specific Overrides in the GUI) just put in the client's certificate/username and put a specific /30 net inside of the tunnel network you setup on the main OpenVPN page.

For more info on how OpenVPN assigns IPs out of that /30 (Null route, server IP, client IP, broadcast IP) see here:
http://openvpn.net/index.php/open-source/faq/77-server/273-qifconfig-poolq-option-use-a-30-subnet-4-private-ip-addresses-per-client-when-used-in-tun-mode.html

Thanks Jimp  :)

Well that would be client-specific config parameters for their certificate (search the forum for that, it's often abbreviated as CSC).

As for limiting their access, that is what the link was for. Once they're on a certain IP, you can filter their access with normal firewall rules.

To do this in 1.2.x could get messy, it would be much easier in 2.0.

Let's say you have your networks, 1, 2, HQ, and RW.

RW's OpenVPN needs routes pushed for the networks at 1, 2, and HQ
IPsec between 1 and 2 needs an IPsec phase 2 entry for 1<=>2 and RW<=>2
IPsec between 1 and HQ needs an IPsec phase 2 entry for 1<=>HQ and RW<=>HQ

You can use parallel IPsec tunnels in 1.2.x but some have had issues making that work. In 2.0 it's as easy as adding another Phase 2 entry to the IPsec tunnel.

If these are all pfSense, it would be much easier to ditch IPsec in favor of site-to-site shared key OpenVPN tunnels for the VPNs between 1, 2, and HQ. Then it would be as easy as adding the right route statements on each leg and it would all just work.

That's probably a feature of the newer openvpn version we're using in 2.0 then.

I have spent the last 2 days on this forum and openvpn forums without any progress.  I can't believe this question hasn't come up.  All I can seem to dig up is people having issues with clients accessing the LAN.  Since all of our clients are linux machines I need to be able to hit the clients from our LAN.  This was no big deal with just one Openvpn server because we could route everything containing to "10.130.0.0" through the openvpn server using our proxy.  Now that we are going to use two servers there seems to be no easy way to do this.

Does anyone know if pfsence is capable of performing this?  I want to have two openvpn servers with each one connected to different WAN's, then use openvpn load balancing to randomly select which server to connect two.  Since this is random we have no way to tell which client is connected to which server without getting on the openvpn server.  I want to be able to ssh to the clients openvpn IP from our LAN.  Any suggestions are greatly appreciated.

Thanks,
Adam

Yeah? Very sparse on details, I'll have to start guessing my way. At least, by your reply I know it's probably possible. Thank you.

If it was working fine for a year and then stopped, I would suspect one of two things:

ISP/upstream interference

Hardware

Neither of which would be rectified by resetting your OpenVPN settings.

To remove OpenVPN settings, if you really must, download a backup of your configuration file from Diagnostics > Backup/Restore, edit out the OpenVPN sections, then restore that edited backup file.

Hi,

Thanks for the tip. I had the same problem and effectively just changing the boundaries does not solve the issue.

What you must do is to convert your pem key file into a old RSA format.

Use the following command and specify the path to the key file you want to convert:

Then copy the output into your webGUI text box including the boundaries "–---BEGIN RSA PRIVATE KEY-----" / "-----END RSA PRIVATE KEY-----"