WEBVTT

00:00.000 --> 00:07.000
OK, good morning, everyone.

00:07.000 --> 00:11.000
My name is Shilun Weimberg, and today I'm going to talk about proxy guard,

00:11.000 --> 00:13.000
why guard behind the reverse proxy.

00:13.000 --> 00:17.000
So, very interesting title, so let's get started.

00:17.000 --> 00:19.000
So, a bit about me.

00:19.000 --> 00:21.000
I work at Shiont for almost three years now,

00:21.000 --> 00:25.000
and Shiont is an organization with actually one main goal,

00:25.000 --> 00:29.000
is fostering collaboration between all the different research networks around the world.

00:30.000 --> 00:35.000
We have a focus on Europe, so we have a research network in Europe,

00:35.000 --> 00:42.000
and we provide services to national research organizations and universities.

00:42.000 --> 00:45.000
For example, Edgero, you might all know it, it's here too,

00:45.000 --> 00:50.000
if you can log in if you're still a student or you've worked for research organization.

00:50.000 --> 00:53.000
But mainly this talk is about edgvpn,

00:53.000 --> 00:56.000
which is also a service that Shiont provides,

00:57.000 --> 01:02.000
and it's co-developed by other research networks.

01:02.000 --> 01:07.000
So, I mainly work at edgvpn at Shiont,

01:07.000 --> 01:12.000
and I put on the Linux Penguin in there because I am mostly using Linux,

01:12.000 --> 01:16.000
even though I'm presenting this on a MacBook, it's quite funny,

01:16.000 --> 01:21.000
but in my day-to-day job, I write software for Linux,

01:21.000 --> 01:25.000
so this talk will be quite Linux focused.

01:25.000 --> 01:32.000
So a bit about edgvpn, edgvpn as an instance is a VPN for research organizations,

01:32.000 --> 01:35.000
so it can be used by a university,

01:35.000 --> 01:39.000
as an alternative to commercial software,

01:39.000 --> 01:43.000
so this Cisco or the 14th.

01:43.000 --> 01:46.000
And it's free and open source, so you can host it yourself,

01:46.000 --> 01:49.000
you don't have to be in university, you can run it at home,

01:49.000 --> 01:53.000
and it's pretty much a layer on top of existing VPN protocols,

01:53.000 --> 01:56.000
so I run on the slide, open VPN and wireguards,

01:56.000 --> 01:58.000
so wireguards only since the latest version,

01:58.000 --> 02:03.000
but that version is already currently almost 3 years already.

02:03.000 --> 02:06.000
So it started as open VPN,

02:06.000 --> 02:10.000
an open VPN has UDP and TCP out of the box,

02:10.000 --> 02:14.000
which is pretty nice because UDP is nice and fast,

02:14.000 --> 02:16.000
but on some networks UDP can be blocked,

02:16.000 --> 02:19.000
and then you have TCP as a fallback.

02:19.000 --> 02:23.000
And we made wireguards integrated into edgvpn,

02:23.000 --> 02:27.000
but then it only has UDP because the wireguards project

02:27.000 --> 02:30.000
only supports UDP out of the box.

02:30.000 --> 02:32.000
So yeah, why is this a problem?

02:32.000 --> 02:34.000
I already explained a bit, UDP can be blocked,

02:34.000 --> 02:38.000
there's still quite a lot of networks that block UDP traffic,

02:38.000 --> 02:40.000
and even if they don't block it,

02:40.000 --> 02:43.000
they might be anti-U issues,

02:43.000 --> 02:47.000
either due to configuration errors in the network,

02:48.000 --> 02:51.000
or they intentionally try to block two large packets.

02:51.000 --> 02:55.000
And this, for TCP, this all works pretty well,

02:55.000 --> 02:59.000
but for UDP in practice, you see quite a lot of problems.

02:59.000 --> 03:03.000
Think about hotels or public cafes.

03:03.000 --> 03:07.000
There's quite a lot of problems with UDP traffic.

03:07.000 --> 03:11.000
You can get around in a bit by setting your wireguards

03:11.000 --> 03:14.000
to 443 or 53 for DNS.

03:15.000 --> 03:20.000
And 443 because of quick, so if you've seen in the last presentation,

03:20.000 --> 03:22.000
if quick gets more and more popular,

03:22.000 --> 03:25.000
then maybe 443 starts working quite well,

03:25.000 --> 03:27.000
but currently there's still quite a lot of networks

03:27.000 --> 03:30.000
where UDP is playing on broken.

03:30.000 --> 03:33.000
So we need to have some kind of fallback in wireguards,

03:33.000 --> 03:35.000
and how do we want to do that?

03:35.000 --> 03:40.000
Well, wireguard is a really slim and mean protocol.

03:40.000 --> 03:44.000
It's 4,000 lines of code according to the white paper.

03:44.000 --> 03:48.000
Maybe nowadays, it's a bit more or less,

03:48.000 --> 03:50.000
depending on how you count.

03:50.000 --> 03:52.000
But if you compare that for example to OpenVPN,

03:52.000 --> 03:56.000
the open source component of OpenVPN is 70,000 lines of code,

03:56.000 --> 03:59.000
but that's excluding the cryptographic libraries.

03:59.000 --> 04:02.000
So if you count OpenSSL into that, you get a lot more.

04:02.000 --> 04:06.000
So OpenVPN also has more features due to that,

04:06.000 --> 04:09.000
so it has TCP support, and yeah, for wireguard, that's missing.

04:10.000 --> 04:12.000
And they actually documented on the website,

04:12.000 --> 04:15.000
and they say transforming wireguards UDP packets into TCP,

04:15.000 --> 04:18.000
is the job of an upper layer of application.

04:18.000 --> 04:22.000
So this is the aim of the stock is creating this tool,

04:22.000 --> 04:25.000
and I would explain a bit why I did not just use another tool

04:25.000 --> 04:27.000
that was already made.

04:29.000 --> 04:34.000
So finding a tool, well, there are actually quite a lot of projects

04:34.000 --> 04:37.000
that tunnel UDP over TCP,

04:37.000 --> 04:40.000
and they just do this by taking the UDP packet,

04:40.000 --> 04:43.000
and then converting it to a TCP socket,

04:43.000 --> 04:46.000
with like a custom header in front.

04:47.000 --> 04:50.000
But some of them only had a client implementation,

04:50.000 --> 04:52.000
and some only a server implementation.

04:52.000 --> 04:56.000
I wanted both, still that were some projects that still had this.

04:56.000 --> 04:59.000
They were either written in a different programming language,

04:59.000 --> 05:02.000
so for HTTP and itself, we prefer to go,

05:02.000 --> 05:05.000
because we were writing our clients now and go.

05:05.000 --> 05:07.000
And if we had an implementation in go,

05:07.000 --> 05:09.000
we could use that as a library,

05:09.000 --> 05:12.000
and also on the server side, we already have some go component,

05:12.000 --> 05:15.000
so that it would fit nicely in our packaging as well.

05:17.000 --> 05:19.000
And what we also would like to have

05:19.000 --> 05:22.000
is run wireguard behind the reverse proxy.

05:22.000 --> 05:26.000
Well, this might sound a bit complicated or a bit why,

05:26.000 --> 05:29.000
but that's due to poor sharing.

05:29.000 --> 05:32.000
So in HTTP and you have a reverse proxy for the API,

05:32.000 --> 05:34.000
and for the web interface,

05:34.000 --> 05:38.000
and this can then run on port 443 and 80 on your reverse proxy.

05:38.000 --> 05:41.000
And it might be nice to have an HTTP and server

05:41.000 --> 05:43.000
that only has these ports open.

05:43.000 --> 05:46.000
So you can have everything in your reverse proxy,

05:46.000 --> 05:50.000
and it would be like one configuration with everything in it,

05:50.000 --> 05:52.000
and this would be really nice.

05:52.000 --> 05:56.000
If you could solve all of these use cases into one tool,

05:56.000 --> 05:58.000
and if you run it behind the reverse proxy,

05:58.000 --> 06:00.000
you also get TLS for free.

06:00.000 --> 06:02.000
So it's a bit more obfuscation.

06:02.000 --> 06:05.000
So if there's networks that do some more packet inspection,

06:05.000 --> 06:07.000
to check if it's actually TLS traffic,

06:07.000 --> 06:09.000
and not just normal TCP,

06:09.000 --> 06:12.000
you might even have more luck with it too.

06:14.000 --> 06:16.000
So that's how proxy got started.

06:16.000 --> 06:19.000
So the first version in go immediately,

06:19.000 --> 06:21.000
I had some go experience,

06:21.000 --> 06:23.000
so it was not that tricky.

06:23.000 --> 06:25.000
And even the first implementation was really easy,

06:25.000 --> 06:28.000
because it was just setting up a UDP socket,

06:28.000 --> 06:30.000
and that's in go.

06:30.000 --> 06:32.000
You just have the standard library,

06:32.000 --> 06:34.000
you have a function to do that.

06:34.000 --> 06:37.000
And then you just simply,

06:37.000 --> 06:40.000
well, you receive packets over the UDP socket,

06:40.000 --> 06:42.000
and you send it over a TCP socket,

06:42.000 --> 06:46.000
and you do have a client part and a server part.

06:46.000 --> 06:49.000
So yeah, you do need to have two components.

06:49.000 --> 06:53.000
And the first part was without a reverse proxy,

06:53.000 --> 06:55.000
so it was just a simple socket.

06:55.000 --> 06:57.000
It did nothing with reverse proxies.

06:58.000 --> 07:00.000
And then there wasn't a question I had,

07:00.000 --> 07:02.000
and how to deal with cut off packets.

07:02.000 --> 07:05.000
So first, I pretty much just took the packet itself

07:05.000 --> 07:07.000
and dumped it over a new socket,

07:07.000 --> 07:09.000
but with TCP, you can have fragmentation,

07:09.000 --> 07:12.000
and then the packets get split up.

07:12.000 --> 07:14.000
And the other hand on the server side,

07:14.000 --> 07:17.000
you have to reassemble it into one whole packet again,

07:17.000 --> 07:19.000
because you need to forward the whole wide

07:19.000 --> 07:20.000
packet to the other hand,

07:20.000 --> 07:22.000
and not just the tiny bit.

07:22.000 --> 07:24.000
So I looked a bit at other tools,

07:25.000 --> 07:27.000
and that was this tool by Movat,

07:27.000 --> 07:30.000
and they also implemented UDP over TCP,

07:30.000 --> 07:34.000
and they had the idea of using just a simple length header

07:34.000 --> 07:36.000
in front of the packet.

07:36.000 --> 07:39.000
So each overhead for each packet would be two bytes,

07:39.000 --> 07:44.000
because that's the total maximum length of a packet in UDP.

07:44.000 --> 07:47.000
So what we pretty much do is in this tool,

07:47.000 --> 07:49.000
in the first version we made,

07:49.000 --> 07:51.000
is we have these four components,

07:51.000 --> 07:55.000
and we got a wire guard server on client and server,

07:55.000 --> 07:58.000
and we have a proxy of client and proxy of server.

07:58.000 --> 08:01.000
So this wire guard client and wire guard server

08:01.000 --> 08:05.000
is just the totally unmodified wire guard project,

08:05.000 --> 08:08.000
deployed on the Linux machine,

08:08.000 --> 08:12.000
and the proxy guard then is the tool that I made,

08:12.000 --> 08:15.000
which is just a simple go binary,

08:15.000 --> 08:18.000
and you would then have to set up wire guard

08:18.000 --> 08:21.000
that it would connect to proxy guard client, local host.

08:21.000 --> 08:25.000
So if you would look at the wire guard show in your terminal,

08:25.000 --> 08:29.000
it would show that the endpoint is just your local host,

08:29.000 --> 08:31.000
proxy guard.

08:31.000 --> 08:35.000
And then you have to make sure that proxy guard on the server

08:35.000 --> 08:37.000
is sensitive wire guard on the server,

08:37.000 --> 08:39.000
and you get traffic pack.

08:39.000 --> 08:43.000
And it's just the whole data stream of UDP packets,

08:43.000 --> 08:46.000
so there on the arrow on the left it gets UDP packets,

08:46.000 --> 08:49.000
and it converts it to TCP packets,

08:49.000 --> 08:51.000
by figuring out the length of the packets,

08:51.000 --> 08:54.000
and then adding that as a header in form of it.

08:54.000 --> 08:57.000
And then on the other end, on the proxy guard server,

08:57.000 --> 09:00.000
we can look at this length and then get the packet out of that,

09:00.000 --> 09:05.000
because that's many different packets next to each other.

09:05.000 --> 09:09.000
So pretty much the server is the reverse of the client,

09:09.000 --> 09:12.000
so the client converts UDP to TCP,

09:12.000 --> 09:15.000
and then back again.

09:15.000 --> 09:20.000
So yeah, you get a TCP sequence of the length and the packet,

09:20.000 --> 09:23.000
and you get that send back to the client,

09:23.000 --> 09:26.000
and send back to the wire guard client again.

09:26.000 --> 09:31.000
So it's not actually that tricky or innovative.

09:31.000 --> 09:33.000
So checking the requirements,

09:33.000 --> 09:35.000
we have a really simple implementation,

09:35.000 --> 09:37.000
so I really like this, because well,

09:37.000 --> 09:39.000
I didn't have to use any order 2,

09:39.000 --> 09:42.000
I could easily maintain this myself.

09:42.000 --> 09:44.000
I may already have a really simple client and server.

09:44.000 --> 09:47.000
I think it was like 300 lines also,

09:47.000 --> 09:49.000
it was not that much.

09:49.000 --> 09:51.000
And we have a go implementation,

09:51.000 --> 09:55.000
meaning I could use it in our HTTP client,

09:55.000 --> 10:00.000
without going through hoops of using other languages,

10:00.000 --> 10:03.000
for infrontient interface.

10:03.000 --> 10:05.000
So what we do not have yet,

10:05.000 --> 10:08.000
though, is running it behind the reverse proxy,

10:08.000 --> 10:12.000
to do port sharing, or have any TLS yet.

10:12.000 --> 10:16.000
So let's take a look how we can do that.

10:16.000 --> 10:22.000
So reverse proxy is like a web focus tool.

10:22.000 --> 10:29.000
So you need some kind of web protocol to proxy your traffic.

10:29.000 --> 10:31.000
So what did you be used?

10:31.000 --> 10:34.000
Well, my immediate thought was web sockets,

10:35.000 --> 10:39.000
and actually I did implement this in a branch and get.

10:39.000 --> 10:43.000
But I soon figured out that web sockets,

10:43.000 --> 10:46.000
yes, I used a library for it, and everything just worked.

10:46.000 --> 10:49.000
But it was quite complex, and debugging it,

10:49.000 --> 10:51.000
and figuring out how it exactly works,

10:51.000 --> 10:53.000
and for me was quite a mystery,

10:53.000 --> 10:56.000
and another expert on web sockets.

10:56.000 --> 10:59.000
And I figured out why would we even need web sockets.

10:59.000 --> 11:03.000
We can just use the same exact methodology

11:03.000 --> 11:07.000
that web sockets used, which I will explain on the next slide.

11:07.000 --> 11:11.000
But do not use this complex packet format for our use case,

11:11.000 --> 11:14.000
because it did not make much sense.

11:14.000 --> 11:20.000
I guess web sockets is great, but it just does way more than we need.

11:20.000 --> 11:24.000
So yeah, fine, let's do our own protocol.

11:24.000 --> 11:28.000
So let's reuse this handshake of web sockets,

11:28.000 --> 11:32.000
and keep the packet format the same as the our initial version.

11:32.000 --> 11:36.000
So we have the sequence of packets with a length and value.

11:36.000 --> 11:40.000
I guess you might say there's now 15 competing standards,

11:40.000 --> 11:44.000
as the XKCD says, but I would argue that they're still 14.

11:44.000 --> 11:49.000
We just have this one more standard that's very specific to our use case,

11:49.000 --> 11:51.000
which I still kind of like.

11:51.000 --> 11:56.000
It just makes it much more simpler for us to do our own thing.

11:56.000 --> 12:01.000
But also the thing about the handshake of web sockets

12:01.000 --> 12:06.000
is that there's a lot of different TCP release

12:06.000 --> 12:11.000
that actually do the same approach, and they also have their own protocol-ish.

12:11.000 --> 12:15.000
So I think it's pretty fine for our use case.

12:15.000 --> 12:17.000
So how would that work?

12:17.000 --> 12:20.000
In web sockets, you do a connection upgrade.

12:20.000 --> 12:24.000
You might have seen it on the previous presentation too.

12:24.000 --> 12:28.000
So you would send a get request with a connection upgrade,

12:28.000 --> 12:33.000
and then the upgrade header is pretty much the name of your protocol.

12:33.000 --> 12:36.000
I call it UOTLV-slash-1.

12:36.000 --> 12:41.000
It's UDP over TCP-length value version one.

12:41.000 --> 12:43.000
So if we ever want to increment the version,

12:43.000 --> 12:48.000
we can do that and then support it on both the client and server side.

12:48.000 --> 12:53.000
And what's cool about this is that if you have your own name for your protocol,

12:53.000 --> 12:59.000
you can set it up with, for example, Apache to only tunnel that specific protocol

12:59.000 --> 13:05.000
to proxy guard and ignore all the other bogus values.

13:05.000 --> 13:09.000
So in essence, it sends this handshake,

13:09.000 --> 13:14.000
so this gets requests to the reverse proxy by the proxy.

13:14.000 --> 13:18.000
And then the reverse proxy sends this to the proxy.

13:19.000 --> 13:23.000
And we can then use this HTTP connection that has been set up

13:23.000 --> 13:27.000
to use the underlying TCP connection.

13:27.000 --> 13:31.000
And we use this TCP connection just in this exact same way

13:31.000 --> 13:36.000
that we have shown in the first implementation of proxy guard,

13:36.000 --> 13:39.000
where we tunnel the UDP packets.

13:39.000 --> 13:45.000
So it's just that the new version to a sport of reverse proxy use case

13:45.000 --> 13:52.000
has just won HTTP requests and response again for switching protocols.

13:52.000 --> 13:55.000
Which made it actually pretty easy.

13:55.000 --> 13:59.000
And the programming language had a nice interface for this.

13:59.000 --> 14:04.000
So we just had to make a tiny HTTP server and a tiny HTTP client,

14:04.000 --> 14:06.000
but it's not a lot of code.

14:06.000 --> 14:08.000
It was not that tricky.

14:08.000 --> 14:13.000
It was just that I didn't know about connection upgrades before.

14:13.000 --> 14:17.000
I thought Websock and like specific to them.

14:17.000 --> 14:23.000
So it was kind of nice seeing that we could use the same approach.

14:23.000 --> 14:26.000
So I prepared a little demo.

14:26.000 --> 14:29.000
I do will not do it live because well VPNs and network.

14:29.000 --> 14:32.000
I do not trust it with that live.

14:32.000 --> 14:38.000
But yeah, so I have a small white guard conflict here.

14:38.000 --> 14:42.000
It's just an example of how a white guard conflict you do like.

14:42.000 --> 14:44.000
With proxy guard integration.

14:44.000 --> 14:49.000
So important to know is that in proxy guard you need to set the white guard endpoint to local host

14:49.000 --> 14:52.000
because that's your local host proxy guard.

14:52.000 --> 14:58.000
And then proxy guard takes care of actually sending it over the internet to the proxy guard server.

14:58.000 --> 15:01.000
This VPN profile is a full tunnel one.

15:01.000 --> 15:06.000
So which is important to demo because that's actually the most tricky to implement.

15:06.000 --> 15:10.000
Because you then could have a routing loop.

15:10.000 --> 15:13.000
Because white guard has a kill switch.

15:13.000 --> 15:19.000
So if you enable white guard, it would only sort of.

15:19.000 --> 15:22.000
It would not tunnel.

15:22.000 --> 15:28.000
Yeah, so with white guard, it's in the sense that if you enable white guard,

15:28.000 --> 15:34.000
it would only make packets go over the internet that are already encrypted by white guard.

15:34.000 --> 15:38.000
And in this case, well, we want to send it to proxy guard.

15:38.000 --> 15:42.000
And proxy guard still has to send it over the internet.

15:42.000 --> 15:45.000
And we do not want that white guard blocks proxy guard.

15:45.000 --> 15:49.000
So we need some kind of way of saying, hey, proxy guard.

15:49.000 --> 15:53.000
Make sure that you can still send packets.

15:53.000 --> 15:58.000
And we do this with a mark, FW mark of 51820.

15:58.000 --> 16:02.000
And this value, we also configure in proxy guard saying,

16:03.000 --> 16:07.000
the packets that coming out of proxy guard should not be blocked by white guard.

16:07.000 --> 16:11.000
They have like the same mark of the packets.

16:11.000 --> 16:13.000
Yeah, as white guard itself.

16:13.000 --> 16:16.000
And then you need to set a listen port for white guard.

16:16.000 --> 16:20.000
And they have the endpoints for proxy guard itself.

16:20.000 --> 16:23.000
So we have this white guard config.

16:23.000 --> 16:25.000
We have proxy guard on the client.

16:25.000 --> 16:27.000
So we set that up with the same FW mark.

16:27.000 --> 16:30.000
So that's a Linux specific feature.

16:31.000 --> 16:33.000
We have proxy guard on the server.

16:33.000 --> 16:36.000
We start that.

16:36.000 --> 16:40.000
So, and here I will show the reverse proxy config.

16:40.000 --> 16:43.000
So that's the same proxy pass match.

16:43.000 --> 16:45.000
So everything to this proxy guard.

16:45.000 --> 16:47.000
First I'm example.org.

16:47.000 --> 16:50.000
This is the whole HTTP path.

16:50.000 --> 16:54.000
Tunnel that to proxy that to the proxy guard local host.

16:54.000 --> 16:58.000
That I just started.

16:58.000 --> 17:00.000
So that's how it works in Apache.

17:00.000 --> 17:09.000
And you could also set this up with NGNX or Cadi or anything that would support proxy passes.

17:09.000 --> 17:14.000
And then I just say do white guard quick up to bring white guard up.

17:14.000 --> 17:16.000
And you can see here in WG show.

17:16.000 --> 17:20.000
It has connected to proxy guard local host.

17:20.000 --> 17:25.000
And I can ping the internet.

17:25.000 --> 17:28.000
So it doesn't work that much different from white guard.

17:28.000 --> 17:31.000
It's only that you have two more components to worry about.

17:31.000 --> 17:35.000
And also yeah, routing can get quite tricky.

17:35.000 --> 17:40.000
The problem with this approach that I showed on the demo is that it's quite manual.

17:40.000 --> 17:44.000
Like you have to set up a lot of different components.

17:44.000 --> 17:47.000
And we wanted to have good client implementation.

17:47.000 --> 17:50.000
So it could just work with one press on the bottom.

17:50.000 --> 17:53.000
So for edge VPN it's just an all protocol.

17:53.000 --> 17:58.000
So here in the edge VPN client you see white guard proxy guard.

17:58.000 --> 18:04.000
But we also made a fork of a Windows developer that he made a fork of white guard on Windows.

18:04.000 --> 18:06.000
Red would also support proxy guard.

18:06.000 --> 18:11.000
Red would say the proxy endpoint which is the one you've configured in your reverse proxy.

18:11.000 --> 18:14.000
And you could just put up a tunnel.

18:14.000 --> 18:19.000
And this would be a new key in the white guard config.

18:19.000 --> 18:21.000
So some challenges.

18:21.000 --> 18:25.000
I explained that the initial implementation was actually easy.

18:25.000 --> 18:30.000
But it's just everything apart from that is just quite tricky.

18:30.000 --> 18:34.000
The whole client implementation you have to support every OS.

18:34.000 --> 18:37.000
You have to support mobile devices.

18:37.000 --> 18:40.000
That can get quite tricky.

18:40.000 --> 18:43.000
And also I'm only like a Linux dev myself.

18:43.000 --> 18:47.000
So I do not have experience on all the platforms.

18:47.000 --> 18:51.000
So I'll testing that was quite tricky.

18:51.000 --> 18:53.000
I could do some more performance testing and improvements.

18:53.000 --> 18:57.000
I didn't even speak about performance in this presentation yet.

18:57.000 --> 19:00.000
No doubt it could be better but it's a really simple tool.

19:00.000 --> 19:05.000
So maybe not that much more room for improvement.

19:05.000 --> 19:07.000
There's yeah roaming and routing issues.

19:07.000 --> 19:09.000
So if your phone goes to sleep.

19:09.000 --> 19:14.000
We have an issue on Android where the proxy guard connection currently doesn't recover.

19:14.000 --> 19:17.000
That's something I have to investigate.

19:17.000 --> 19:22.000
And macOS iOS that's platform that I want to support.

19:22.000 --> 19:25.000
But I didn't really actively test on it yet.

19:25.000 --> 19:28.000
I'm also working on a Linux demon.

19:28.000 --> 19:30.000
That automatically sets this up.

19:30.000 --> 19:34.000
So it would wait for a wide-rout interface to be brought up.

19:34.000 --> 19:38.000
And it would dynamically get all the wide-rout parameters and set up proxy guard.

19:38.000 --> 19:41.000
And it would automatically restart proxy guard when you're flowing.

19:41.000 --> 19:43.000
We cover it from sleep.

19:43.000 --> 19:45.000
And when you're roaming that works.

19:45.000 --> 19:49.000
So you can immediately use proxy guard again.

19:49.000 --> 19:51.000
Yeah, so that was it.

19:51.000 --> 19:54.000
In the nutshell, the home pages and code work.

19:54.000 --> 19:56.000
So it's on our HTTP and handle.

19:56.000 --> 20:01.000
But you can totally use it separate from HTTP and it's just a simple go binary.

20:01.000 --> 20:05.000
And if you want to learn more about wide-rout, we're not an official wide-rout project.

20:05.000 --> 20:07.000
But they have a stand here at first time.

20:07.000 --> 20:08.000
I learned about yesterday.

20:08.000 --> 20:10.000
I'm going to do more presentation.

20:10.000 --> 20:13.000
If you want to get funding for open source.

20:13.000 --> 20:16.000
So HTTP has received funding before from NLNet.

20:16.000 --> 20:19.000
They're also at first time, and they have also cool stickers.

20:19.000 --> 20:20.000
So make sure to go there.

20:20.000 --> 20:24.000
And if you want to learn more about Giant or talk to me in the afternoon here,

20:24.000 --> 20:26.000
we also have a stand.

20:26.000 --> 20:28.000
So yeah.

20:28.000 --> 20:30.000
Thank you for listening.

20:31.000 --> 20:33.000
Thank you.

20:37.000 --> 20:38.000
Yeah.

20:38.000 --> 20:39.000
Hang on.

20:42.000 --> 20:46.000
By putting the packet length in your own packet,

20:46.000 --> 20:50.000
I was thinking that means it's not going to work with

20:50.000 --> 20:53.000
with jumbo packets.

20:53.000 --> 20:54.000
But I don't think there's a use case.

20:54.000 --> 20:56.000
Use that with jumbo packets, right?

20:56.000 --> 20:57.000
No.

20:57.000 --> 20:58.000
Yeah.

20:58.000 --> 20:59.000
Yeah.

20:59.000 --> 21:00.000
So it's fine.

21:00.000 --> 21:01.000
Okay.

21:01.000 --> 21:04.000
Thanks for your question.

21:04.000 --> 21:06.000
One more.

21:06.000 --> 21:09.000
As soon as you convert into HTTP to TCP,

21:09.000 --> 21:11.000
so when you establish TCP session,

21:11.000 --> 21:14.000
did you have a problem with time-weight sockets?

21:14.000 --> 21:17.000
Because as I guess you have many, many UDP clients,

21:17.000 --> 21:20.000
which connect and sometimes there are the same clients,

21:20.000 --> 21:24.000
which connect quickly, but you draw up the same.

21:24.000 --> 21:26.000
Sorry, come here.

21:27.000 --> 21:29.000
I mean, sometimes there are clients,

21:29.000 --> 21:31.000
which reconnects very quickly,

21:31.000 --> 21:34.000
but they're really finished in session,

21:34.000 --> 21:36.000
but they still use themselves.

21:36.000 --> 21:37.000
All right.

21:37.000 --> 21:38.000
Do you mean that the client is going?

21:38.000 --> 21:39.000
Sometimes.

21:39.000 --> 21:43.000
You can't know the time-weight time-out in line,

21:43.000 --> 21:44.000
please.

21:44.000 --> 21:45.000
All right.

21:45.000 --> 21:46.000
Yeah.

21:46.000 --> 21:47.000
Yeah.

21:47.000 --> 21:48.000
It's a TCP is also tricky,

21:48.000 --> 21:50.000
but we also implemented time-outs.

21:50.000 --> 21:51.000
So if a client is gone,

21:51.000 --> 21:55.000
it would cut off that client after a while.

21:55.000 --> 21:57.000
So yeah, that is implemented.

21:57.000 --> 21:58.000
Yeah.

21:58.000 --> 21:59.000
If that was your question,

21:59.000 --> 22:00.000
but...

22:00.000 --> 22:03.000
I mean, it's just how you keep in time-weight.

22:03.000 --> 22:04.000
Yeah.

22:04.000 --> 22:05.000
Yeah.

22:05.000 --> 22:06.000
Out of that it takes time, you mean.

22:06.000 --> 22:07.000
Yeah.

22:07.000 --> 22:08.000
To set up.

22:08.000 --> 22:09.000
Yeah.

22:09.000 --> 22:10.000
Cool.

22:10.000 --> 22:11.000
Thank you very much.

22:11.000 --> 22:13.000
Thank you.