Whole House VPN setup

[RMerlin]

I'm sure most VPN providers have the same opinion that ISPs have why does anyone need a 1 Gig connection with a superfast VPN connection?

Providing that kind of bandwidth AND CPU power (encrypting/decrypting 1 Gbps of traffic is VERY CPU intensive) would also be very expensive for the providers themselves.

 

[joegreat]

Providing that kind of bandwidth AND CPU power (encrypting/decrypting 1 Gbps of traffic is VERY CPU intensive) would also be very expensive for the providers themselves.

There are VPN providers (like Prefect-Privacy) with up to 3 GBit connectivity per location: I wonder how big their server farm is...

 

[sfx2000]

Providing that kind of bandwidth AND CPU power (encrypting/decrypting 1 Gbps of traffic is VERY CPU intensive) would also be very expensive for the providers themselves.

Things are getting better there - Xeon-D can be quite fast, and there are some ARMv8 server oriented chips that do OpenSSL processing very quickly and will little CPU overhead - the control plane runs on the CPU, but the data plane is running on the cypto blocks..

 

[MichaelCG]

I'm sure most VPN providers have the same opinion that ISPs have why does anyone need a 1 Gig connection with a superfast VPN connection? Once the demand is there probably some VPN provider will use their ability to provide very fast VPN connections as a selling point.

I agree that anything over 100Mbps "today" is mostly overkill....however I am one of the lucky ones with 1Gbps Internet. I previously had Time Warner 300/20 service which was again...overkill. The biggest perk of having Google Fiber? The lower latency. I rarely ever use over 25Mbps of my Internet connection except when downloading patches/updates...and even then it may only be 80-100Mbps for a few minutes. But the fact that my latency to my office went down from 110ms to 20ms was HUGE for my daily activities.

As I get through my discovery process and start looking at testing, I will report back my speeds....eventually. Again, if I can get 100Mbps speeds for general use, I will be more than happy. I am waaaaay more concerned about latency than speed. High latency is what kills user experience. I will take a 20Mbps 30ms connection over a 100Mbps 130ms connection any day.

 

[RMerlin]

Things are getting better there - Xeon-D can be quite fast, and there are some ARMv8 server oriented chips that do OpenSSL processing very quickly and will little CPU overhead - the control plane runs on the CPU, but the data plane is running on the cypto blocks..

Imagine trying to feed 5-10 clients off that same server at such a speed. It might be realistic for the end-user, but more difficult for the server endpoint where multiple clients are connected at the same time.

Sure, there's a 22-core Xeon model available. How much would a VPN provider need to charge to recover their investment tho?

 

[sfx2000]

Sure, there's a 22-core Xeon model available. How much would a VPN provider need to charge to recover their investment tho?

Hehe...

It's safe to assume that commercial providers are running on dedicated HW, and not on regular off the shelf servers - enterprise/carrier grade VPN concentrators are custom silicon (think Cisco AnyConnect or Juniper SSL/VPN as an example here).

 

[zentec]

Can anyone recommend a good tutorial that can walk you through on creating a whole house VPN setup. Given that our Congress has just voted to allow ISPs to sell all your browsing habits, its time to fight back.

Also any suggestions on wireless routers that work well with a VPN setup.
Thanks, Nathan

I am certain this could be done on something like OpenWRT, but I am not convinced that running OpenVPN on your router will produce satisfactory results. Nevertheless, airvpn.org has plenty of info on doing just that.

My setup uses two virtual machines on an I7 box that does a whole bunch of things in the house. One VM connects to an airvpn endpoint in Chicago, the other to an airvpn endpoint in Amsterdam. The VMs are on VLANs, one a subnet of the private network so printers can still be accessed, the other off on its own network isolated. I get 60 megabits on the Chicago VPN, 12 on the Amsterdam.

My need to do this stems from some work that I do, but now that the intentions of ISPs and marketers is known, I use it more and more just for casual internet use. To the gentleman that said the app layer betrays privacy, he is very correct. If you do not employ script blocking and tools to thwart third-party shenanigans, the VPN efforts are for naught. And even then, with canvas profiling, even browser plugins to protect privacy are becoming less effective.

A VPN is going to be one tool among many to protect privacy.

 

[MichaelCG]

Hehe...

It's safe to assume that commercial providers are running on dedicated HW, and not on regular off the shelf servers - enterprise/carrier grade VPN concentrators are custom silicon (think Cisco AnyConnect or Juniper SSL/VPN as an example here).

Juniper (which is now PulseSecure) can run on dedicated hardware, but they mostly recommend deployment on Virtual now. Most x86 hardware is plenty fast enough these days...and most enterprises can just scale up how many systems are in the service cluster as needed to meet demands.

Very few commercial/enterprise deployments could care less about top speed of a single client. They are much more interested in stability and overall speed as the user density rises.

 

[sfx2000]

Probably a good reason why Intel J1900/J1800's are popular with many of the OpenVPN crowd - they're not the stoutest processors (compared to other x86), but they're clocked fairly fast at 2.4/2.53 GHz respectively on turbo clocks - which definitely helps with the userland/kernel jumps...

Going with Airmont - Braswell does offer AES-NI, which is always appreciated over Silvermont on Baytrail-D (which doesn't have AES-NI) - with OVPN, J1800 still wins over N3700 at high bandwidths - depends on the configs, but generally...

I stand corrected...

Interesting - standing up a new homeserver - the previous was a Dell i3050 (J1800), new one is NUC5PGYH (N3700) - these are similar enough units - the J1800 is a dual core silvermont, the N3700 is a quad airmont.... N3700 does bring AES-NI to the table

The J1800 is a tad bit faster in single thread (max clock 2.56GHz) compared to the N3700, which tops out at 2.4GHz.

Some numbers... for me on a 150/10 connection - the N3700 it should be a good fit for nearly wireline speed with OpenVPN if I choose to use it for VPN connectivity.

@kvic - look at the GCM numbers for the AESNI machine - 256 vs. 128...

This is all OpenSSL 1.0.2g

AES - Intel N3700 - Braswell

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-gcm     124969.99k   235895.98k   323049.81k   358767.96k   369295.36k
aes-256-gcm     113344.15k   207811.56k   274003.88k   300459.35k   307882.67k
aes-128-cbc     212729.40k   320635.07k   385178.71k   403926.02k   410654.04k
aes-256-cbc     177599.88k   244110.42k   282888.90k   292633.26k   296684.20k
sha256           17730.61k    44260.10k    82627.07k   106331.95k   115649.19k
sha512           11987.83k    48096.98k    80705.28k   117660.67k   136014.51k

No AES - Intel J1800 - Baytrail-D

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-gcm      37137.44k    41850.05k   139827.89k   156105.05k   160423.94k
aes-256-gcm      28099.84k    31054.23k   107106.39k   119669.64k   122478.59k
aes-128-cbc      46401.63k    50329.15k    52033.41k    52124.67k    52500.03k
aes-256-cbc      34166.85k    36263.32k    36823.13k    37030.23k    37109.76k
sha256           18637.95k    45983.65k    87052.37k   112866.99k   123660.97k
sha512           12205.10k    48632.09k    84452.61k   124687.02k   145129.47k

AES - Intel N3700

gnutls-cli --benchmark-ciphers
Checking cipher-MAC combinations, payload size: 16384
        SALSA20-256-SHA1 139.40 MB/sec
        AES-128-CBC-SHA1 153.69 MB/sec
        AES-128-CBC-SHA256 86.37 MB/sec
             AES-128-GCM 0.30 GB/sec
       CHACHA20-POLY1305 0.22 GB/sec

Checking MAC algorithms, payload size: 16384
            SHA1 0.24 GB/sec
          SHA256 106.85 MB/sec
          SHA512 117.10 MB/sec

Checking ciphers, payload size: 16384
                3DES-CBC 13.02 MB/sec
             AES-128-CBC 0.41 GB/sec
             ARCFOUR-128 184.24 MB/sec
             SALSA20-256 0.33 GB/sec
           
No AES - Intel J1800

gnutls-cli --benchmark-ciphers
Checking cipher-MAC combinations, payload size: 16384
        SALSA20-256-SHA1 149.21 MB/sec
        AES-128-CBC-SHA1 43.62 MB/sec
        AES-128-CBC-SHA256 36.13 MB/sec
             AES-128-GCM 41.24 MB/sec
       CHACHA20-POLY1305 0.23 GB/sec

Checking MAC algorithms, payload size: 16384
            SHA1 0.26 GB/sec
          SHA256 114.26 MB/sec
          SHA512 124.21 MB/sec

Checking ciphers, payload size: 16384
                3DES-CBC 13.49 MB/sec
             AES-128-CBC 52.33 MB/sec
             ARCFOUR-128 197.15 MB/sec
             SALSA20-256 0.35 GB/sec

 

[kvic]

@kvic - look at the GCM numbers for the AESNI machine - 256 vs. 128...

1) Weird...GCM is slower than comparable CBC on your AESNI machine. I got quite the opposite relative performance on i5 Sandy Bridge:

More details here: Quick Benchmark CBC vs GCM

2) J1800's performance of 128 & 256 AES+CBC only on par if not worse than Cortex-A9 @ 1.4GHz (i.e. RT-AC88U). I think people shall no longer recommend J1800/J1900 for pfSense build. Overall performance on such HW is likely not as good as tailor-made firmware on RT-AC88U...

 

[sfx2000]

1) Weird...GCM is slower than comparable CBC on your AESNI machine. I got quite the opposite relative performance on i5 Sandy Bridge:

More details here: Quick Benchmark CBC vs GCM

Your Core-i5 numbers seem to be off for a 2.7GHz SNB, esp the aes-128-cbc and aes-256-cbc values

how are are you running? should be "openssl speed -evp <cipher mode>"

In any event - SHA is not accelerated by AES-NI, whereas GCM is - so my conclusion would be as follows - if both ends support GCM, and more importantly, support AES acceleration, then by all means, use GCM

Celeron 1037U (IvyBridge, 2 cores, 2 threads - 1.8GHz)

No AES - Intel 1037U (big cores, low power - IvyBridge)

aes-128-gcm      55538.44k    63789.50k   201876.38k   220349.44k   225894.40k
aes-256-gcm      42510.78k    47149.55k   155853.74k   171946.67k   176248.15k
aes-128-cbc     157385.09k   179165.99k   183619.50k   186146.47k   186933.25k
aes-256-cbc     116930.84k   129919.51k   132131.33k   133703.34k   134113.96k
sha256           24903.27k    63643.31k   120950.44k   156428.97k   171024.38k
sha512           17044.49k    68922.05k   121715.71k   184331.95k   217240.92k

gnutls-cli --benchmark-ciphers
Checking cipher-MAC combinations, payload size: 16384
        SALSA20-256-SHA1 168.88 MB/sec
        AES-128-CBC-SHA1 126.41 MB/sec
        AES-128-CBC-SHA256 90.64 MB/sec
             AES-128-GCM 101.67 MB/sec
       CHACHA20-POLY1305 0.22 GB/sec

Checking MAC algorithms, payload size: 16384
            SHA1 0.38 GB/sec
          SHA256 172.12 MB/sec
          SHA512 0.21 GB/sec

Checking ciphers, payload size: 16384
                3DES-CBC 12.83 MB/sec
             AES-128-CBC 186.97 MB/sec
             ARCFOUR-128 0.21 GB/sec
             SALSA20-256 0.30 GB/sec

 

[kvic]

how are are you running? should be "openssl speed -evp <cipher mode>"

yes. also openssl version and compiler options are included in the linked article from my previous post (pls read before ask obvious questions

I don't see much inconsistency in relative performance of CBC vs GCM given your new 1037U (no built-in AESNI) data.

Going back to N3700 (with built-in AESNI), GCM performs worse mostly than CBC across the board of different packet sizes. Perhaps something wrong in your OpenSSL build. Or I think it says something about the low-cost N3700 itself...

 

[sfx2000]

yes. also openssl version and compiler options are included in the linked article from my previous post (pls read before ask obvious questions

I don't see much inconsistency in relative performance of CBC vs GCM given your new 1037U (no built-in AESNI) data.

Going back to N3700 (with built-in AESNI), GCM performs worse mostly than CBC across the board of different packet sizes. Perhaps something wrong in your OpenSSL build. Or I think it says something about the low-cost N3700 itself...

It's not a "new" 1037U - it's a box that I've kept around for close to three years now...

Go back and look at the numbers for N3700 - it's matching your numbers for the i5...

aes-128-gcm     124969.99k   235895.98k   323049.81k   358767.96k   369295.36k
aes-256-gcm     113344.15k   207811.56k   274003.88k   300459.35k   307882.67k
aes-128-cbc     212729.40k   320635.07k   385178.71k   403926.02k   410654.04k
aes-256-cbc     177599.88k   244110.42k   282888.90k   292633.26k   296684.20k

The fact that the N3700 can do AES-128-GCM at over 300Mb/Sec is pretty impressive for a low end chip - pretty much matches your Core-i5 Sandy Bridge - which is a great chip in and of itself...

FWIW - J1800 (without AES_NI) does about 40Mb/Sec - this is a good argument against considering J1900, as OpenVPN is single threaded, and for VPN purposes, there are better choices... the older 1037U does bump things up there a bit, to over 100Mb/Sec - but it doesn't compare well to the N3700...

See my numbers, and you'll likely conclude the same...​

Anyways - let's take this off thread as we're very much off-topic, but it's a good chat...

Getting back on topic - having a small Intel box that supports AES-NI can do good things - and again, GCM is a better choice than aes-128-cbc-sha512 in any event... if both end-points support it.

 

[sfx2000]

Getting back on topic - having a small Intel box that supports AES-NI can do good things - and again, GCM is a better choice than aes-128-cbc-sha512 in any event... if both end-points support it.

And that's all good - and this is why sometimes - for a VPN GW - it doesn't have to be the same as the primary GW - on the the clients, just point the GW to the persistent VPN server inside your LAN - the VPN server does not have to run on the primary GW itself... don't have to complicate things with VLAN's or other things..

(just like IPv6 tunnels, it's the same thing)

Keep it simple, keep it secure - and sometimes, one has to stick-shift the clients...

 

[sfx2000]

Imagine trying to feed 5-10 clients off that same server at such a speed. It might be realistic for the end-user, but more difficult for the server endpoint where multiple clients are connected at the same time.

Sure, there's a 22-core Xeon model available. How much would a VPN provider need to charge to recover their investment tho?

Interesting stuff... QuickAssist is pretty cool - from the server side, it's a non-brainer as we just put some bandwidth out there - the cost for the client at the moment might be a bit high - a standalone QAT card can run up to $800USD, but from the server side, it's pretty cheap - and Xeon-D has this built in rather than a add-in...

From a service provider view - the add-in cards might be a good revenue generator, as they are cheaper than the higher end Xeons, and scale well.

https://www.servethehome.com/intel-quickassist-at-40gbe-speeds-ipsec-vpn-testing/

 

[sfx2000]

And why do I bring this up - Intel is starting to jump into the HomeGW field - first at the carrier provided level, and then eventually perhaps even to the off-the-shelf customer level - and these chips are pretty darn fast...

QNAP has announced the TGX-150 device, which is likely the off-the-shelf component - we have to wait and see if it actually ships, but considering their experience at networking and intel, it should be a very good performer...

(if you look closely - over on the left hand side is their intel based SBC - which I'm very, very interested in)

 

[coxhaus]

VPN is a nice idea but I don't think it will help you using a US local ISP. VPN is mainly for keeping the middle man out not the end point ISP. The US local ISP has access to all information at the end point where traffic is decrypted.

 

[Iclark31]

Good luck on finding a router that will give you at least 100Mbps on a VPN connection. Up until Comcast increased my provisioned speed from 75/10 to 150/20 I was running my VPN client on a VPN accelerator which has a 1.8 Ghz Atom processor and normally getting download speeds of 70- 75 on the VPN connection.

After the speed increase the best the VPN accelerator can do is 65 Mbps. Running a VPN client app on my PC with 2.8Ghz I7 processor I can get 170 Mbps download speeds. I have changed all the VPN settings, tried various servers and even experimented with other VPN providers and my conclusion is that the increased bandwidth from Comcast just over loads what the processor in the VPN accelerator can do. As another point of reference running the VPN on AC1900P with 1.4 Ghz processor can only download using the VPN at 55 Mbps.

If you want throughput from your 1 gig connection to be 100Mbps you are going to need a box with a very powerful processor. Whether it needs to be a quad core I7 or not I can't tell you for sure but my older PC with a 1.6Ghz I5 processor running the VPN client can only get a download speed of 50 Mbps.

I found this service, privacyhero.com which works with your existing router and gives 90mbps.

 

[CaptainSTX]

Report back on how it works when you get it in mid December.

Also would be interested in knowing what settings/ routing are required on the router to integrate the VPN appliance into your network

 

[Iclark31]

Report back on how it works when you get it in mid December.

Also would be interested in knowing what settings/ routing are required on the router to integrate the VPN appliance into your network

Yeah, will give some more info then. The main reason I'm looking into this is that they say it works with any existing router by plugging in and restarting the router.