Enterprise WireGuard® with Cohesive VPN Client

Enterprise WireGuard® with Cohesive VPN Client

by | Jun 28, 2022 | AWS, Azure, Connectivity, Security, Tutorials, VNS3 Features

Cohesive Networks VNS3 6.0 - Clientpacks Page

VNS3 6.0 Beta3 will be available in cloud marketplaces or upon request this week (contactme@www.cohesive.net).  In our last post we showed how easy it is to connect your native WireGuard® clients to VNS3 6.0.  In this post we show you how to use the Cohesive VPN Client to achieve the same goals like connecting to data centers or cloud VPCs/VNETs, and managing your own WireGuard® network connecting multiple people and devices.  In addition, we will show an overview of using our enterprise capabilities like dynamic route updates, easy tunneling of all traffic with local subnet exceptions, and OIDC integration so you can authenticate your vpn users with Google Authentication, Okta, Auth0 and more.

The screen shots throughout show three windows; upper left the Cohesive VPN client, bottom left a command line from the same Mac, and to the right the cloud-based VNS3 server.

VNS3 Network Platform has the concept of “clientpacks” – basically the credentials needed to connect a machine or a person to the network via a VPN client.  Historically “clientpacks” have been “openvpn” by default.  Starting in 6.0 clientpacks are WireGuard by default. In a future release we will support a dual stack with both “ovpn” and “wg” connections simultaneously, and a goal of IPsec clients as well.

In the picture above and those below we show the “Clientpacks” page. From this you can perform key administrative functions like disabling addresses, re-generating credentials, updating pre-shared keys, and getting access URLs for secure and easy distribution of VPN credentials.

 

Access URL

Cohesive Networks VNS3 6.0 - Clientpack Download
Cohesive Networks VNS3 6.0 - Clientpack Access URL

Above shows the results of choosing “Access URL” and displaying its result. This is a secure, one-time, timed URL allowing users to copy/paste the clientpack, download it for import, or use via a QR code on mobile devices.

It has all the necessary information to make a connection using the Cohesive VPN Client – with or without PSKs.

The commented lines are used by CNVPN CLI and GUI for additional enterprise support; failover, dynamic route updates, and OIDC authentication.

Copy/paste the clientpack into the Cohesive client via the “Paste” option, and choose Save.

 

Connect

Cohesive Networks VNS3 6.0 - Clientpack Paste into CNVPN
Cohesive Networks VNS3 6.0 - CNVPN Connect

Next choose “Connect” from the Cohesive Client’s “Actions” menu –  and the VPN connection is created.  The VNS3 Clientpacks page then shows the status as “connected”.

Below shows access to the VPN network by successfully pinging the VNS3 controller’s VPN address.  (By default, this connection can access other addresses on the VPN. If that’s not desired it is easily changed via the Firewall page.)  

Cohesive Networks VNS3 6.0 - CNVPN Connect
Cohesive Networks VNS3 6.0 - CNVPN Ping

You can use the Action menu on the VNS3 Clientpacks page to perform administrative operations.   For example, if you select “Disable” on the connection, the client is dropped from the VPN.  

Similar operations can be performed to re-new or re-secure a connection by adding a PSK or re-generating keys (both of which require the clientpack to be redistributed to the user or device).  As expected, when you enable a PSK for the connection, the user is unable to access the network.  With the credential re-deployed with the appropriate clientpack containing the PSK, they are back on the net!

To see some of those operations in action, take a look at our previous post.  Cohesive’s target is to provide organizations the ability to deploy their own enterprise VPN infrastructure.  This could be managed by Cohesive via our SecurePass offering, or self-managed.  Regardless, our initial focus for 6.0 is managed, enterprise WireGuard.

Dynamic Route Updates

One of our key enterprise features is dynamic route updates.  For “people vpns” you can usually just tunnel all traffic through the VPN – making the VPN adapter the default gateway.  However, for IoT and machine2machine vpns, dynamic routing is a critical capability.  You allow the device to have its own local gateway but when routes arrive dynamically, the traffic begins to follow that path.  If the route is removed from the network, the default gateway is used.

In the example below the configuration is changed to have “RoutePolling = True”, and on the VNS3 controller a route to 55.55.55.55 has been advertised through the VPN.  In the terminal window route display there is not yet a specific route to that public IP.

Once re-connected, the route to 55.55.55.55 through the VPN is visible on the client as a result of the dynamic route updating.

If that route is disabled or removed from the VPN network, then it is removed from the client.

Cohesive Networks VNS3 6.0 - CNVPN Route Polling
Cohesive Networks VNS3 6.0 - CNVPN Route Advertisement

Tunnel All Traffic

Tunneling all traffic through the VPN to the Internet is a snap with the Cohesive VPN Client.

Set the client parameter “TunnelAllTraffic” to “True” AND make sure you have enabled firewall directives on the VNS3 Server to send all VPN traffic out to the Internet.

VNS3 Free edition comes with a default set of rules in a group called “VPN2Internet.  Go to the Groups view on the Firewall page and enable these rules.

This will direct all traffic from your VPN client to the Internet, getting its address translated to the Public IP of the VNS3 controller.

What if you still want to be able to access local network resources like a printer or file server?  In that case, use the “LocalRoutes” option to enter a comma delimited list of the network CIDRs you want to exempt from the VPN so they can be reached locally.

Now that all traffic is being tunneled, from the command line the public IP 8.8.8.8 can be successfully pinged.  To “prove” this traffic is going into the VPN we show it via our Network Sniffer.

Cohesive Networks VNS3 6.0 - Firewall VPN2Internet
Cohesive Networks VNS3 6.0 - VPN2Internet Success

VPN User Authentication

So far the examples have just used WireGuard protocol with unique keys and pre-shared key (PSK) for the connections.  What about more specific user authentication?  For WireGuard in VNS3 6.0 we use OIDC (Open ID Connect), and will add LDAP support in future.  (Our dual stack offering in future will allow simultaneous use of OpenVPN and WireGuard clients, with your choice of LDAP/AD or OIDC).

With OIDC support you create a VPN users and/or admins application in your OIDC provider and then configure VNS3 integration.

Cohesive Networks VNS3 6.0 - OIDC VPN Users

Once the OIDC configuration has been saved you can login. In this case we are using our Google Apps login.  When “Connect” is chosen, a login screen pops up in the default browser.

Cohesive Networks VNS3 6.0 - VPN Users Google Identity

Upon entering the correct password the login panel indicates success and the VPN client connects!

Cohesive Networks VNS3 6.0 - VPN Users OIDC Success

Next up we will show using the Cohesive CNVPN CLI on a Linux machine.  For cloud overlay networks and over-the-top cloud networking, the CLI is a powerful way to bring your enterprise feature set to your cloud and multi-cloud deployments. 

(“WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.)

The Enterprise and WireGuard

The Enterprise and WireGuard

by | Apr 28, 2022 | Connectivity, Network Architecture, Network Edge Plugins, Security

WireGuard® at its core is a lightweight, low code, VPN tunneling protocol that optimizes for speed, security and ease of configuration. However, extended business functions needed for enterprise usage are left out of its code base by design. This non-opinionated approach allows third parties to develop novel methods that best fit enterprise needs and styles.

Examples of Enterprise needs are:

  • Key (re)generation and distribution for both human users and machine-to-machine networks
  • RESTful API for integration to in-house systems and external services
  • Uniform access to encrypted tunneling via regional or global clusters
  • Dynamic routing so devices on the WireGuard network learn about network paths as they come and go
  • Failover support allowing clients to migrate servers in the event of maintenance or outages
  • Integration to security platforms (Firewalls, WAFs, IDS/IPS)
  • Integration to other “tunneled” paths (IPsec, GRE, VXLAN, cloud direct connects, etc..)
  • Integration to “legacy” monitoring tools like SNMP
  • Integration to “modern” monitoring tools like Datadog and Sumologic
  • Integration to legacy authentication (Active Directory)
  • Integration to modern authentication (OAuth / OpenID, MFA, etc..)
  • AND more!

Cohesive is working to make the WireGuard protocol a first order citizen in our VNS3 Network Platform with a focus on many of these extended capabilities.

Enterprises will need methods to securely store and distribute keys to human and machines. Authenticated REST APIs allow automation frameworks to tag and place keys where needed in a distributed computing environment. Self-service web portals give end users access to allocated keys for their various devices. Administrators and intrusion detection systems need the ability to revoke keys when compromise occurs.

Not all tunneling systems and their keys are the same. Many companies employ encrypted overlay networks, in cloud and between their compute nodes in order to satisfy regulatory requirements and gain network visibility. For automated machine-to-machine communications, public/private key pairs are all that is required, whereas with “people VPN” scenarios added authentication factors are needed.

In the dynamic world of cloud networking and remote work, private networks are now fluid, meaning that network address ranges are added and removed, as new networks and subnets come on line or are decommissioned. In order for systems to communicate they need dynamic route updates providing up-to-date paths through interconnected transit networks.

These encrypted tunneling systems are used to take the enterprise, its customer and partners to, through, and across clouds. This requires the WireGuard feature called “Allowed IPs” that acts as both ACL and route directives to be integrated. In Enterprise WireGuard use-cases, the “Allowed IPs” don’t come from a configuration file, they will be dynamically and seamlessly integrated to the broader systems routing and ACL policies. communications in the enterprise. Companies need the ability to filter and direct traffic at ingress and egress points in cloud networks.

WireGuard is fast becoming an essential operating system and developer tool, and Cohesive Networks believes it’s on its way to being an essential building block for creating robust, enterprise-ready network solutions.

“WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.

WireGuard: A Quick Overview

WireGuard: A Quick Overview

by | Apr 7, 2022 | Connectivity, Networking Fundamentals, Security, VPN

Image courtesy of wireguard.com.

WireGuard® is a new communication protocol that implements encrypted virtual private networks (VPN). It endeavors to provide network agility, advanced security, performance, and configuration simplicity. Back in 2017 Jason A. Donenfeld, a security researcher and Linux kernel developer, was looking for a stealthy traffic tunneling solution for use in penetration testing jobs. In an interview on the Security. Cryptography. Whatever. podcast, Donenfeld explains that while he was “familiar with OpenVPN and IPSec” he was well aware of the bugs these solutions carried with them. Thus, he set out to create something new for himself that would not suffer from historical technical debt.

IPSec, one of the major VPN options available today, was born in 1992 with the Internet Engineering Task Force’s formation of the IP Security Working group, and was standardized in 1995 under RFC-1825 and RFC-1827. IPSec has always required a tremendous amount of configuration unique to the hardware and software environments it will then connect. The encryption, key exchange, and authentication algorithms that it supports are overly broad, in order to support legacy equipment. The key exchange mechanism can be prone to rekeying issues, causing stability problems. This is not to say that IPSec should be avoided, but to point to the non-triviality of its implementation. If you consider using IPSec as a vehicle for remote worker VPN connections (“people VPN” or “road warrior VPN”), there are security concerns as simple as an “aggressive mode” sending a hash of pre-shared keys in plain text.

Another option, OpenVPN, was initially released in 2001 by James Yonan. It uses Secure Socket Layer (SSL) and Transport Layer Security (TLS) to provide encryption. OpenVPN is currently the most widely used VPN protocol on the planet, to the extent that some might consider it the backbone of modern online security. Along with trusted encryption, OpenVPN also supports a wide range of algorithms for encryption and authentication, hashing, and key derivation, making it highly adaptable to different deployments. It also uses certificates for identification and encryption and it can operate on UDP or TCP.

This brings us back to the steady emergence of WireGuard. In January of 2020 Linus Torvalds merged David Miller’s “net-next” tree into the Linux kernel, bringing WireGuard into the mainline Linux kernel tree. WireGuard was written to be efficient and easily readable; it is comprised of around 4,000 lines of code, which is much fewer lines of code than OpenVPN relies on. Among other benefits, this smaller size makes WireGuard auditable in an afternoon (or so) and the condensed code significantly reduces the attack surface. The goal is to keep WireGuard slimmed down to its basic operational function; a simplified and performant VPN. It is left to third parties to extend it to meet various functional business requirements.

While IPSec and OpenVPN provide a plethora of algorithmic options, WireGuard limits the need for user choice and customization in favor of fast, modern cryptographic primitives that don’t rely on hardware accelerators. This greatly removes the possibility of user miscalculation and thus insecure or improper deployments. Many connectivity vulnerabilities are caused by the combination of primitives, not always the primitives themselves. WireGuard endeavors to combine known, secure, and performant primitives, and allows you to negotiate protocol versions to easily address future vulnerabilities.

WireGuard operates much like OpenSSH in terms of public and private keys. Peers identify themselves with a unique public keys which are is used to establish their IP inside of the tunnel. WireGuard calls this concept “cryptokey routing”. This simplification of tunnel configuration is a major advantage of WireGuard. Performance is another major factor of WireGuard’s appeal. OpenVPN adds about 20% data overhead while IPSec adds around 10%, but WireGuard uses a mere 4% more data than an unencrypted connection. Most tests even show WireGuard performing around twice as fast as OpenVPN, with WireGuard operating near to or close to line speed. Another key factor to the speed of connectivity is where WireGuard operates in the operating system. On Linux, WireGuard operates in kernel space, where packets are processed at a much faster rate. However, on Windows this is not the case, so the WireGuard group has developed a very simple and minimal TUN driver, Wintun, for the Windows kernel that shuttles packets to the Windows User Space. We can probably expect WireGuardNT (LINK) to move into the Windows kernel space in the future.

Back to the cryptokey routing table. The “cryptokey routing” concept developed by WireGuard allows changes to external source IPs to be picked up and propagated quickly and efficiency. Whether you are a roaming client that is switching between cellular and wifi, or a client that needs to ‘fail over’ to a backup server, the cryptokey routing table gets updated in mere seconds with the new IPs of the tunnel. In comparison, OpenVPN can take 30 seconds to reestablish new IP connections, which is only slightly slower than the time it takes IPSec connections using BGP routing to reestablish similar connections. The WireGuard protocol provides additional security in that it does not respond to packets from non peers nor unauthenticated packets, leaving WireGuard mostly invisible to non-peers.

In conclusion, it appears WireGuard aims to keep its code base small, be easy to implement and audit, all while having blazingly fast performance using state-of-the-art cryptography.

“WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.

News Roundup: Week of Feb 21, 2022

News Roundup: Week of Feb 21, 2022

by | Feb 24, 2022 | Connectivity, Network Architecture, News, Public Clouds, Security

U.S. Cyber Officials Issue Official Warning Against Potential Russian Cyber Attacks

During a call this Monday, FBI and DHS cyber officials urged government agencies “to look out for signs of Russian activity on their networks” as a result of the evolving Ukraine crisis. According to Yahoo: “federal officials also urged those on the call to dramatically lower their threshold for reporting suspicious activity.” Citing “an uptick in Russian scanning of U.S. law enforcement networks” as well as “in Russian disinformation and misinformation about Ukraine,” cyber officials urge increased care and caution with links and communications as the crisis progresses.

IBM Opens Cyber Security Hub in India

IBM recently announced the opening of their first IBM Security Command Center in the Asia Pacific region. The center hopes to provide a cybersecurity incident response plan for enterprise customers with deployments in the region, as well as “a fully immersive, interactive, and experiential learning facility.” IBM plans to use simulations and experiential training to help enterprises protect themselves from cyberattacks. IBM promises that by co-locating this training center with their X-Force Command Center, IBM’s Security Operations Center, both live practice and training for cyber security precautions will benefit immensely.

Microsoft Brings Cloud Security to GCP

Yesterday Microsoft announced the release of Microsoft Defender for Cloud for Google Cloud Platform, making Microsoft the first major cloud provider to offer security solutions in all major cloud platforms. The offering from Microsoft boasts Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) across both containers and servers. According to the release, GCP deployments of Microsoft Defender for Cloud will come “with out-of-box recommendations that allow you to configure GCP environments in line with key security standards like the Center for Internet Security (CIS).” Microsoft is also emphasizing the necessity of Zero Trust Management and event log management in cloud environments with two more ‘upgraded’ cloud security offerings.

News Roundup: Week of Feb 21, 2022

News Roundup: Week of Dec 26, 2021

by | Dec 30, 2021 | Connectivity, Network Architecture, News, Public Clouds, Security

Could Continuing AWS Outages Give Rise to Distributed Cloud Deployments?

Widespread disruption of high-use internet services was recently experienced as a result of the third AWS outage in the span of a month. AWS reported this latest disruption was caused by “a power outage at a data center in Northern Virginia” which saw giants like Hulu and Slack offline for about two and a half hours. A recent article from The Washington Post suggests that having a cloud deployment with a singular, critical point of failure creates opportunities for widespread outages, in a world where distributed cloud deployments can offer you some protection from these outages. As “the cloud’s increasing intricacy and demands” continue to increase, and companies continue to migrate and develop in the cloud, the potential for outages caused by the “over-centralization” of infrastructure into heavily-used AWS regions also increases.

Azure App Service Insecurity Exposing Source Code Since 2017

A recently discovered insecurity in the Azure App Service has “exposed the source code of applications written in PHP, Python, Ruby, and Node” and has been prevalent since September 2017. SC Magazine purports that this security flaw was first widely reported to the public by The Wiz on Oct. 7, 2021, and Microsoft has since updated it’s security recommendations document and mitigated the default behavior that caused this issue. Further research suggests that this vulnerability was likely not a well-kept secret and would have been widely exploited during the purported four year window of this vulnerability. We recommend double-checking your deployments against these new recommendations to ensure that your source code isn’t vulnerable.

Security Attacks Likely to Continue to Increase in 2022

2020 and 2021 have been marred by an increase in the commonality and sophistication of security attacks on companies as we all navigate the uncharted waters of remote work, and address the new connectivity and security concerns that have surfaced as a result of this necessary transition. A recent article from Bloomberg law suggest that some of the most damaging attacks have targeted backbone systems and solutions, such as the Microsoft Exchange software attacks that affected many companies in 2021. Alarmingly, many of the “exploits used in the first quarter of 2021 are still being used today” which only serves to create added pressure on both the solutions providers and companies that build critical systems upon such backbones solutions. These attacks are complemented by more ‘traditional’ phishing attacks, “which remains one of the highest-volume types of vulnerabilities” across all business sectors. Having proper security procedures and communication channels in place is more important than ever, and the criticality of such considerations will only increase as we move into 2022.

JEDI Becomes JWCC With Decision Target of Q3 2022

In the wake of four years of legal challenges and congressional inquiries, The JEDI contract has been replaced with a new framework, the Joint Warfighter Cloud Compatibility (JWCC), “from which to deliver commercial cloud services to Defense personnel.” The Pentagon “issued formal solicitations for JWCC” to AWS, Microsoft, Google, and Oracle, effectively leveling the playing field for the biggest US cloud providers. According to Nextgov “The Pentagon plans to make JWCC awards in the third quarter of fiscal 2022” which could bring some interesting infrastructure developments from these cloud providers.
IPSec with VNS3: Part I

IPSec with VNS3: Part I

by | Aug 24, 2021 | Connectivity, Network Architecture, Network Edge Plugins, Networking Fundamentals, Security, VNS3 Features

Internet Protocol Security (IPSec) is used to encrypt communications between two computers over the internet. Usually it is done between between security gateways to allow two networks to communicate securely. On the data center side this will be done for the most part on physical boxes manufactured by the likes of Cisco, Juniper, Fortinet and others. In the public cloud it is virtualized. Cohesive Networks VNS3 is one such device that allows you to easily configure these secure connections into your cloud private network. Whether you are running a hybrid cloud, are an ISV that needs to connect to customer sites or are implementing a multi cloud strategy VNS3 can provide a stable, secure and simple solution.

VNS3 can manage as many IPSec connections as you need, the only limit is the underlying instance resources. You can scale your VNS3 instance with the number of connections. It supports both policy and route based connections and supports a wide range of algorithms, hashes and Diffie-Hellman groups. In short, VNS3 can connect to just about anything out there. It’s highly configurable design lets you match exactly what it is communicating with. This all makes VNS3 a very stable solution.

Setting up VNS3 is a breeze. You can launch it out of your cloud vendor’s marketplace and pay by the hour, or contact Cohesive Networks for longer term billing. VNS3 should be placed into a public subnet. Once launched you will need to either in AWS, turn off source destination checking, or in Azure, enable IP Forwarding on its network interface. In AWS you should attach an Elastic IP (EIP) to it or in Azure a Public IP Address. Once it is up you can manage it via its web interface. You will need to open up TCP port 8000 in your security group. Then open a browser and go to:

      https://:8000
      The default admin username is: vnscubed

In AWS the default password is the instance id, in Azure the default password will be the virtual machine name followed by a hyphen then the private ip (ex. MyVNS3-10.0.0.1)

Once you have logged in you should change the admin and api passwords.

The IPSec configuration page can be found under the Connections section on the left hand side contextual menu. From there you will want to click on the “New Endpoint” button and will see the IPSec configuration form.

Now it is just a matter of filling in the parameters for the endpoint you will communicate with. Typically you and the other party will agree upon a set of algorithms, hashes and dh groups as well as NAT-T or native IPSec and IKEv1 or IKEV2. While VNS3 does a good job of auto discovery it is best to make sure that both sides are explicitly the same. We provide a simple syntax for VNS3. An example might look like:

phase1=aes256-sha2_256-dh14
phase2=aes256-sha2_256
pfsgroup=dh14
phase1-lifetime=3600s
phase2-lifetime=28800s
dpdaction=restart
dpddelay=30s
dpdtimeout=90s

VNS3 simplifies this process by putting all of your configuration on a single page.

If you are creating a policy based IPSec connection you will next need to create individual tunnels for your connection. This is done after the creation of the initial endpoint. After the endpoint is created you can create a “New tunnel” from the action drop down to the right of your endpoint. This will be your local subnet and then the subnet on the other side of the connection that you will be communicating with.

With route based IPSec we support both Virtual Tunnel Interface (VTI) and over GRE, useful for sending multicast packets. If you are utilizing a VTI route based IPSec VPN you next want to set up a “New eBGP Peer” from the action drop down.

Your IPSec configuration should now show as connected.

In the next parts in this blog series we will dive into the tools we provide to troubleshoot a faulty connection, interesting things you can do with our firewall to transform the tunnel traffic, and some plugins we use to solve common problems.