Nettica offers more than just an IP address; it provides a complete network solution. This makes Nettica a unique and compelling product. It was built from the ground up to create and manage WireGuard™ networks. Why? Because there is no built-in management. There is no simple mechanism for synchronizing changing network configurations on the fly. Well, not until now.
Nettica is built on these technologies:
- WireGuard for networking
- OAuth2/OIDC for authentication
- MongoDB for the database
- Golang for the microservices and backend
- NodeJS for the front-end
- Docker for the containerization
We built our cloud using these providers:
- Amazon Web Services
- Oracle Cloud Infrastructure
- Microsoft Azure
- Google Cloud Platform
They are all connected with Nettica, of course.
Our performance cannot be beaten. You can say that’s the benefit of being in the cloud. Not only do we have solid, jitter-free bandwidth, but we’re also in the locations where companies host their websites and services, so there’s minimal additional latency. Officially we’re only going to promise reliable 100Mbps per-flow streaming, but we’re not going to be the bottleneck in your network. You’ll be throttled by your wireless connection to your router, or by your ISP, before having issues on our end.
Logs and Privacy
We are 100% open source. But we are not in any way a “no logs” company. Frankly, it’s hard to believe anyone can claim to have such a policy. In our case, we wrote the code. It has logging in it. It’s not customer-sensitive. We use it to diagnose problems and manage the service. The logs, if available, reside on your network. They are for you. It would be irresponsible not to provide them.
We also take a pragmatic approach towards privacy. We use OAuth2 to identify you and those you invite to your networks. This is not a design flaw – you want to authenticate the people accessing your network, and we provide a simple and elegant solution. Besides, it’s easy to create a disposable email address.
Our services also span all the major cloud providers. If a government wants to know an IP, our upstream providers are more than capable of assisting them with no help from us. This is something true of almost every other VPN provider as well. However, our multi-hop tunnel service enables anonymity, if this is a concern.
Private keys can be generated on the agent and never leave the device. Nettica also uses WireGuard pre-shared keys to both double encrypt the traffic, as well as secure the public keys from anyone monitoring the traffic. OAuth2 is used to validate users based on their email addresses. In our tunnel and relay services, containers are used to isolate customers. Network Policy allows you to manage the openness of your network: make it open, or lock it down.
We have a distributed, reactive architecture that is stateful and eventually consistent. It is a polling architecture, where, regularly, the Nettica Agent will securely query for configuration changes from the Nettica Service. Most of the time this returns immediately when there are no changes, but if not, it will receive the new configuration, compare it with the old configuration, and make whatever adjustments are needed.
When looking to implement our relay and tunnel services, we doubled down on this architecture. Our service hosts are Linux servers running the Nettica Agent, but in addition to polling for their Nettica VPN configuration, they also poll for their Service Host configuration. When you configure your relay or tunnel service, the Nettica Agent running on a given service host will see the update, and launch a container image with the specifics of your service. You can run this image yourself, it’s on Docker Hub.
The container provides real security and real customer isolation. I’m sorry to say most of our competition fails on this point. How can you tell a flawed architecture? When they have a big flat IP space and you’re given a random IP address out of it. Or double tunnels. What is that? We use cloud principles.
When you create a network you define the name and subnet. Every single Nettica customer can specify the same name for their network and the same subnet for their network, and it has no impact on other customers. That is real isolation.
We also provide a unified view of your assets wherever they may be. If you have devices in multiple clouds like we do, you likely also have a jumble of auto-generated subnets to deal with. We provide a single pane of glass uniting all of your assets.
A network also contains a template for creating new hosts. When a new host joins a network, it gets an IP address out of the subnet along with the rest of its configuration (DNS, etc.). It creates a network interface with this configuration and traffic flows based on it.
Because a network is a group of hosts with a similar configuration, they can all share the relay or tunnel container, which acts just like another host in the network. You can also invite friends or coworkers to join a network. This leads to a much different VPN story than the monolithic OpenVPN implementations. Networks are small, nimble, and compartmentalized. An organization should have multiple networks organized however makes sense for them. They could have dev, test, and production networks. They could have marketing, sales, and product networks. It could be regional or per project. The possibilities are endless.
We implemented DNS as a microservice in the Nettica Agent. The agent will listen on the DNS port (53) of the interface for which it has been enabled. The microservice reads the configuration of the network and creates a simple lookup table for forward and reverse DNS entries. It also registers the DNS with the host so that it receives queries. In fact, it receives all queries. It will respond authoritatively to those hosts that match the hostnames in the network. It will respond with SERVFAIL for all other queries, which causes the OS to try the next DNS server in the list.
In addition to the microservice for resolving network hosts, you can specify whatever DNS servers you want in the network configuration. This might be your internal resolvers, or maybe a global DNS provider if you’re using our tunnel service. We offer maximum flexibility and expose as much WireGuard functionality as possible.
Activating UPnP enables several functions. First, it automates the configuration of port forwarding. In addition, we query the gateway for the external IP address and update the host’s endpoint if it changes. This enables a variety of scenarios for laptops and road warriors. It also eliminates the need for a DDNS provider. UPnP is an optional feature and can be turned on individually per host. It is not necessary to use the service. While some have security concerns with UPnP, in our opinion its security concerns while justified, are overblown.
In addition to UPnP, we also provide Sync Endpoint functionality that automatically syncs your IP address if it changes. It will not, however, configure port forwarding. This feature is geared more towards customers that already have their ports configured, or use NAT traversal.
The screen grabs below are from our admin console. With Nettica you can visually see the network as you are making it.
Traditional VPNs offer only a ‘hub and spoke’ architecture, restricting remote users’ tunneling capabilities to any off-site resources by requiring validation and traffic throughput limited via a central hub.
We provide a hub-and-spoke VPN architecture on demand with our relay service. It has some advantages in terms of supporting coworkers or accessing cloud resources through a bastion. But we also offer a point-to-point method of tunneling resources across a mesh framework, so regardless of the physical location or status of a central hub, you can traverse resources with superior speed and significantly less frailty. Simple mesh-centric IP management combined with a public/private key-sharing service, as well as our DNS microservice, provides you with an elastic fabric for connecting resources wherever they may be.
WireGuard has the seal of approval of Linus Torvalds and is embedded in the latest Linux kernels. It is open-source technology, offering best-in-class cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec and is considerably more performant than OpenVPN. WireGuard is designed as a general-purpose VPN for running on embedded devices and supercomputers, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployed. It is still in active development and is regarded as the most secure as well as the fastest VPN solution in the industry. Our networks simplify what would otherwise be significant overhead in managing WireGuard VPNs, securely.
We offer users single-sign-on using OAuth2 providers including Google and Microsoft, as well as our own. This includes any multi-factor authentication enabled for your account. If Google is your identity provider, you can log in seamlessly with our service using your custom domain. We can also do this with Microsoft Entra ID-based domains for enterprise customers. If you’ve outsourced your identity management that’s fine too, so do we. We can integrate with many services through the OAuth2 and OIDC standards.
Nettica is 100% open source. We do not expect you to believe us when we say we’re secure. We just are. With 35 years of experience building software at scale, we have nothing to hide and use standards-based technologies. Our source code is available on GitHub.
Check out this brief tutorial to familiarize yourself with your new VPN service.
If you need support you can send us an email at [email protected], or for general questions we are also available via [email protected]. Of course, the easiest way is to just click the Chat button at the bottom of the page.
Thanks for giving us a look, we look forward to building a strong relationship with all our clients, so feel free to reach out anytime with feedback, information, or general support 24 hours a day, 7 days a week.
- The Nettica Team