I am looking into what site-to-site VPN appliances are out there today people are using. I know some of the hardware appliances people are using but what about Virtual Appliances?
I have started to do some research but am not finding what I’m looking for. Some I am aware of are OpenVPN and pfSense but as far as I know they do not have dedicated support available.
Is anyone using a VM appliance for site-to-site VPN Connectivity? If so would you have any recommendations on solutions available with support? This solution will solely be for a backup site-to-site VPN connection.
Meraki is on the list of options but do not have any experience with their MX Security product line.
What are speed and reliability requirements? And also how good is VM infrastructure on both sides?
Basically, if you have VMware with vMotion on both sides, don’t need to push more than 50Mbps of traffic and need high reliability - just use VM-based solution (could be as simple and Linux with OpenSwan, could be more specialized solution).
Or if you need 10Gbps throughput between sites but you don’t care that much about reliability - get 2 hardware firewalls.
Since you are looking for backup solution, you probably don’t need to double-up on hardware. And if you want vendor support, just buy whatever your budget allows, Meraki, Cisco, Juniper and many other brands - all can do the job, as it is quite simple.
In some cases, with a hardware appliance such as an ASA or MX or others, you get crypto acceleration in the hardware. Whereas, in VMs, you want get such.
The meraki MX is very very easy to set up. Especially with other MX appliances. It takes most of the work out of l2l tunnels.
Won’t pretty much any business-class router do site-to-site VPNs at >= 2 Mbps? Your current WAN router might already support this feature. Are you concerned about your primary connection failing or your primary router failing?
If you are considering Meraki why not just a pair of regular Cisco IOS routers and a DMVPN? I mean sure you can do it in a VM, but why the extra layer of complexity?
Using it for OpenVPN site-to-site is easy. Also using it for a few IPsec site-to-site VPNs for “cloud” vendors who wanted us to purchase a dedicated ASA.
Configuration can easily backed up as a text file and you can upgrade the OS with a one-line command. You can install yourself or use the OVA they provide.
Personally I wouldnt allow the unknown network to terminate in my inside vmware cluster who is also handling sensitive data - that is just wrong.
But even if you would setup a dedicated hardware cluster (with its own storage etc) and only use for “external use” then you have the performance issue.
VM:s are great for redundancy and to reuse hardware (like you can squeeze 10 VM’s who each wants 10% cpu into a single hardware and by that save some room, hardware, storage, power and cooling) but they suck at performance.
Using the baremetal directly for the software appliance will always give it better performance and less overhead then going through a VM layer.
Best is of course to use dedicated hardware (as in ASIC/FPGA stuff) made to crunch those packets for you with minimal latency and jitter (which also gives higher throughput and better performance).
Also speaking about redundancy, with a VM solution the VM layer itself must function otherwise you will have downtime for your functionality. Using dedicated hardware (without VM layer) you have less things that can go poop and cause you downtime (VMware or whatever you choose to use must update too which gives that not only the vpn product itself have downtimes but also the VM layer which your vpn product runs within will cause downtimes).
crypto acceleration in the hardware. Whereas, in VMs, you want get such.
I just did a quick test on an old machine and dd if=/dev/zero bs=1M count=1000 | ssh 127.0.0.1 'dd of=/dev/null' gets about 800Mb/s throughput. This is the worst case scenario since it uses the chacha20-poly1305 cipher which has no hardware acceleration.
How has your experience with Meraki been with dynamic routing protocols? I have read they don’t support OSPF unless they are in a passive mode which doesn’t seem like it would be ideal.
We are concerned more about having a reliable backup solution with minimal overhead. Cisco ASA’s will take longer to configure and get working. I am really the only guy out of a few that can dive into Cisco and configure / troubleshoot. Ideally the solution would be easier for someone to jump in and understand how it works.
Thanks for the reply. I have a couple points I would like to make regarding what you mentioned.
Currently we are using VM appliances to terminate the backup site-to-site VPNs. I understand the security risk you mentioned but I don’t see how that is any less secure than running the same exact image on a physical server vs a VM given the same network information (IP’s, VLANs, etc).
I completely agree running a dedicated bare metal server vs. a VM performance will be better. With our ~ 2Mbps throughput requirement I don’t see performance being an issue at this point.
Regarding redundancy - I understand the VMware environment / layer needs to function for this to work. If the VMware environment is not working then we have bigger issues to deal with than a backup site-to-site VPN appliance.
Have you used modern virtualization hardware? Because unless you’re significantly oversubscribed you can get very solid performance out of a VM.
Also the comment on security is kind of ridiculous unless OP is running a single flat network. VM environments support VLAN segmentation and border controls you know.
Currently all sites have ASA’s handling NAT, Firewall, and Internet failover. MPLS is primary between sites with a VM running a Linux-based VPN appliance as the secondary WAN link.
Utilizing the existing ASA’s is an option but we are looking for other options at this point. One reason to use them would be to utilize existing infrastructure.
Several reasons to look elsewhere would be I will likely be the only one configuring / supporting the solution. ASA’s don’t support GRE which would lead us to use static routing everywhere to make this solution work.
