And I'm going to present you OpenQuery PM. These are various slides, but Erica is hardly contributing this product. She's not entirely out there.

And I'm going to be giving them the web pages to see. And I will start this talk with the story that led to the OpenQuery PM server. And then I will talk about the server itself and give a different idea for future plans and what we can do.

I will talk about the server because this is what I work on and I know better. And so let me start with the story. A few years ago, I was working in a company that had a task to develop a VPN service between two routers.

And two routers in a way to interconnect different networks. And that was a typical VPN system. For example, we can have something like this where you have a LAN connected to another LAN to your address. Or we also want to handle end users so an end user can connect to his phone.

And of course, when we're talking about VPN, I'm assuming it's secure again. So no one on the internet can install the connection in between. So all over this talk, I'll be assuming I have to talk about secure VPN service. So for this deployment, we have full requirements.

One was to have a very simple setup for end users when they were at home. There were employees made from a low company that didn't know about VPN. It just wanted to connect. So we wanted a really simple setup. In addition, we wanted a standard-based solution.

We didn't want to invent our own cryptography. We didn't want to use someone else's custom protocol. We just wanted to use something that is standard today. Approved by EF or other. Some other requirements was that we wanted

administrator to be able to see on the router who was connected on every moment. And not only that, we also wanted administrator to be able to disconnect or ban users. For example, when he detects an abnormal connection from someone directly. And to make the long story short,

invent, we used an open VPN-based solution with a lot, really many custom scripts to achieve what we wanted to achieve. I was not very happy with the end solution.

And I want to try to explain to you why. Because we set these requirements and we wanted a simple setup for users, for example. However, with open VPN, we needed really a complex configuration file to be downloaded by the user. And the user had also to select within TCP and Unity.

In a way that was not really understandable. I mean, as a user, I want to connect with VPN. I don't care if it uses TCP or UDP. I just want it to work. Automatically detect what is best for my setup. So our next requirement was to rely on a standard-based solution.

It was not also covered by open VPN. Because although open VPN works TLS for the kickstands, everything else after the kickstand was a custom new protocol. Maybe it's secure, but I don't know. And the other thing is that the administrator

had no overview of who is connected on the system. He was connecting. And in order to get an overview of who is connected, at any moment we had to use a lot of custom scripts to keep track who is connected, who is disconnecting, and removing from the list.

I thought this was a bad requirement in software, although we could work around it. And the last one, it was simply not possible to disconnect users from the work already connected. A few years later, I talked to some other administrator

and told me that they managed to achieve this by inserting hardware rules because it will block a user who they want to block. But I thought that this was really a hack rather than a solution. You just put a firewall in there, and you block the user who is already connected so you can have this connection.

It didn't align to my days. Anyway, this was in the past. I quit this job. I had another job at the university. And I received this email. You don't have to read it. It was from David Woodhouse. And he was asking me to add an adjustment to no TLS that I was working on.

And that adjustment was to add Datagram TLS support for a early draft version of the standard. I was wondering why it was that. And that was because David was working on OpenConnect client, which is a Cisco AnyConnect compatible client

that is based on TLS and Datagram TLS. I checked further on AnyConnect on Cisco's protocol, and it was appropriately VPNed implementation, but it was based on standard protocols. And how it was on a high level? It was a VPNed channel. It was established over an HTTP session.

We started an HTTP session. You did authentication, and then you basically connect. And you were connected to VPN. And optionally, after you connected to the VPN using TCP and HTTPS, you could initiate a UDP channel. And the UDP channel was secure

using Datagram TLS, a pre-draft version. So we also had, as I mentioned, David was working on a global source component, OpenConnect. And because Cisco AnyConnect protocol is a property, everything I will talk about will be about

the OpenConnect protocol, which is the protocol that the open source client talks about. It's compatible, but it's a protocol that we know. OK, that was the moment I realized that we had a standards compliant VPN, and I started to remember my old project. I tried to use OpenConnect client,

and let's say the command line client looks like that. So you write OpenConnect, the server you want to connect, you get us your username, you enter your username, you get us your password, and you're connected. So that was also the moment I realized we had a very simple user setup client.

OK, it was command line, but today we have network manager plugins, we have Windows clients, we have OpenConnect, we have an Android client, and it's pretty much all the same. So from the initial requirement,

we had already fulfilled the two. There was no server side, so I decided to write the server side, and I said, OK, since I'm going to write the server side, let's make it better than any existing solution.

So I wanted to isolate the user between themselves. So if there is a bug in the server, no user will be able to see the package of another user. Or if there is also to operate on the least possible privilege, so that if there is a bug of the handling code for the client, you will not be able to, let's say, escalate

and get control of the main system. So I'm going to talk about the server mode now. The project started in 2013, and today we interoperate with both OpenConnect and any connect clients,

and it's developed primarily on Linux and exported later to BSD systems by other players. And, OK, since I'm the main author for the server, I would like to share it to you more, so I will just describe some features we have for the server. It supports partial authentication using file, BAM, or radiance.

And you can authenticate using certificates from Kerberos. Kerberos authentication is interesting because you can achieve single sign-on if you use Kerberos as your corporate authentication system. You can achieve single sign-on in the sense of collecting it,

and then you already have a ticket going to any other server name, You can set resource limits per client, or per groups of clients, using cgroups, or limit the bandwidth. With cgroups you can limit also the CPU time, but some groups of users update.

Something that is often not considered, but it's quite important today, is that the more CPUs you have in your system, the more clients you can serve. And that's particularly interesting when we have systems today with ARM,

ARM servers that have 128 CPUs or something like this. And, of course, you support compression using LZDS, it's a very old algorithm. It's supported by NCOMEC. And LZ4, it's a pretty modern algorithm. Of course, TLS 1.2, that'll be TLS 1.2.

And online user management. So, in addition, I mentioned before that I wanted to make it quite safe for the users, to isolate the rest of the system. And the way I isolated the server process

from the main system was using second. So, there is a filter limiting the number of systems that the working process can operate, isolating users from the main system. And also, all authentication is handled on a separate security module, which is a separate process.

And the user side is still communicating with the process.authentic. So, this also covers the user-authentic isolation and least-prevalence requirements that I set for the server. And now I'm going to describe you the control tool

that is used to administer the server. It's called OC control. You run it, and you end up in a page like this. If you type here, you get some commands. It's pretty much disconnect the user, reload the server, show the status of the server.

So, all the users were connected to a particular user, and so on. And that's from a known version of the server. Now there are a few more commands, but these are the important ones. And, for example, let's say this is the user's command. You connect to the server, the administrator,

and you see who is connected, the user name, the group they belong to, the IP they're connected from, the real IP, the VPN IP, the device, how long they're connected, and more information. And you can get... Okay, and this completes the requirement for user overview.

But I have the original set. And another command is the show user. In this particular example, we show the user VPN test command. We show an ID that is unique. This says here, user name,

what is the state, what is the user agent, who he used to connect, it's the open connect client, how much data he has transferred, how much bandwidth, the average bandwidth, and more information, such as the configuration of the DNS language.

And the other requirement was to be able to disconnect a user, to ban a user. There is a command to disconnect a user, and you can disconnect not only user name, but also an ID, which is a specific instance of the user, completing the requirement for user disconnection and loading.

So, pretty much, the original project that was given to me ten years ago, it was completed, pretty recently. The requirements were completed with this server. And, yeah,

when historic finish is, the question is what happens afterwards. We have some future plans for the server, and the open connect program, we would like to extend and simplify the open connect protocol, if possible, and make it independent of Cisco,

because they are not very cooperative. We would like to drop the legacy, grant datagram TLS 1.0 support, and we would like to use all the latest systems others. We would like to publish and standardize the protocol itself, not just based on the standard protocols,

but the protocol itself, how you connect, how you authenticate, is pretty much custom. And we would like to work on improving performance by using an internal TLS and datagram TLS stack. Facebook has already sent some kernel patches on introducing an internal TLS stack,

and we are experimenting with utilizing it, because we noticed it improves the performance a lot in this particular scenario, more than they used to in the fail detection. So, that pretty much completes my talk.

These are the websites for the client, the first one, and for the server, the second one. And if you have any questions, you can ask them now, or you can visit our website. Thank you, Nikos. Raise your hand if you want to ask a question.

Just a quick question. I'm wondering why you included an entirely new server, rather than adding some functionality to the system. Yeah, that's quite the question,

but the thing was that the protocol that opened VPN was implemented was fixed, so if you have to change the protocol, you have to change most of the code base, and also the isolation thing that I wanted to put on the server was not present there, so adding it would be pretty much a normal structure to separate components,

so it was much easier to rewrite everything, rather than start from open VPN. Any more questions? The example that you showed had IPv4 addresses.

Will it tell on IPv6 as well? Yes. Hi there. How about the performance of it? How many concurrent users can it have on a typical server?

What is the use case you have for this? The last release version can scale up to a thousand users. That's the limitation of the select code that we use, but now we are developing a new version that is about to be released. We have lifted the limitation.

So the only limitation is the number of two devices that Linux can support, and I think that's around 20,000 to the power of 15,000. I've never used this many devices. Any more questions?

It depends on how the algorithm negotiated. Maybe if both the client and the server have...

Actually, I cannot tell you the number. It depends on the server. You can see on the bottom, it's totally different. Now we see it. But it's less than I've said. That sounds like a good example. Do you recommend to use it in production,

or like trace our open VPN? There are commercial providers using Open Connect. You can buy Open Connect, say connections, commercial. These are VPN servers all over the world. So I know it's already being used commercially.

And if your requirement is not to scale over 1,000 users, you can use the current version. It's a good server. I mean, we get bugs. Most people use it.

I believe it's production-ready. How hard is it to add another algorithm?

Another algorithm? In what sense? A KRS algorithm. Yes, another algorithm. It uses TLS. So everything is supported by TLS.

In particular, it uses no TLS on the backend. So every algorithm is supported by no TLS. It will be there. So that's pretty much all. If you have the algorithm using no TLS, you are going to put it on server.

I saw in the documentation that it's possible to offload the SSL input to load balancer. So my question is basically, how much of the resources for files are for the SSL encryption?

And how much for the service? So if you do the SSL service on the load balancer, is that automatically scaled? Or is it not that interesting? The biggest cost thing now is the context facing between data space and music space. Because it's a complex space.

It's a bundle with every second. I believe everything is in that space. So even if you switch to load balancer, the coping from music space to music space remains. You are not done. You are not done. No, not at all.

You are not done yet.

You talked about the closed source software. But there is also software that integrates with the server. But the next line is in the story.

So how much can you do when configuring users?

Let's say you want to have some users connecting only having access to parts of the network and other users can have access to different resources. So can you do something like the product I'm giving you is PEWS Secure by Juniper.

So you can have groups of people only having access to one network or another network. Yes, and you can customize what kind of routes you send to each user. In the new version we are also experimenting with sending fire routes.

So when a user connects, it firewalls him. It doesn't only send him these routes that you can see this part of the network. But it prevents him from using a firewall to anywhere else. This is pretty much experiment, I don't know. But this is the idea of what I'm going to get. So you can customize the user of a group of users.

More questions? Thank you, Nikos.