14 ms·
WireGuard: next generation in-kernel modern VPN
- Aissen 10y agoPaper: https://www.wireguard.io/papers/wireguard.pdf https://www.wireguard.io/papers/wireguard.pdf
- zx2c4 10y agoWow, I launched this 10 minutes ago and somebody already put it on Hacker News. Spectacular! I'm the author of this and would be happy to answer any questions you have.
- Aissen 10y agoYes, guilty as charged. Ever since I saw you presentation in Paris in last September, I was dying for wireguard to come out. I'm curious what will be your strategy with regard to working or not with upstream Linux ?
- zx2c4 10y agoOh cool you came to the kernel recipes talk. Much has progressed since then. I wrote an email on LKML and netdev today to David Miller, the network subsystem maintainer. It's not ready for a [PATCH] set now, but it is ready to get initial feedback from them, so that I can start to get things ready for upstreaming. So: that's on the roadmap and a primary objective!
- loeg 10y agoWould you mind dual-licensing under a more permissive license (BSD or MIT) so the work can be included in the BSD family of operating systems as well as Linux?
- zx2c4 10y agoI answered this question elsewhere. The answer is that - probably, why not? I need to think about it for more than a few seconds. But the only reason I chose GPLv2 is because that's what Linux uses. I'll quit being lazy and think more carefully about licenses, and hopefully we'll wind up with something good for the BSDs.
- loeg 10y agoThanks for considering it! For what it's worth, there is dual BSD/GPL precedent in various places in Linux (e.g., most of the drm GPU drivers, NTB, etc).
- pdimitar 10y agoI am not a lawyer but in my eyes having a BSD/MIT license will also save you from a corporation "adopting" your technology and sue you afterwards for infringing a super vague patent of theirs... or something along the lines. If your work is in the public domain, then at least the corporations would have much harder time hijacking and wall-garden it, and the chances of them simply giving up are higher. Or so I hope. I've read a good chunk of your website. GREAT WORK! Do not give up, you're doing next-level work. =)
- gcb0 10y agois this really a thing?
- pdimitar 10y agoAs I pointed out, I am not a lawyer. I have however read news vaguely similar to what I described, many times through the years. It really makes me fearful that in the end you're vulnerable just for publishing your work... I do hope I am very naively wrong. But history hasn't given us much comfort in this area so far.
- loeg 10y agoYeah, you're not a lawyer. This is nonsensical gibberish.
- runejuhl 10y agoFor those of you who're interested, the mail to LKML can be found here: https://lkml.org/lkml/2016/6/28/629 https://lkml.org/lkml/2016/6/28/629
- ciokan 10y agoCan I bind it to external ip addresses and give a certain user an outgoing (or even private ips that I can then forward) address I chose? Don't know if my question makes sense but I'm interested in routing a certain user to a certain ip every time he/she connects.
- zx2c4 10y agoWireGuard as a simple associations between public keys and each public keys list of allowed IPs. Within this structure, it seems like you should be able to do what you want.
- ZoFreX 10y agoWhere has the code for the nuts and bolts of the crypto come from (e.g. everything in the "crypto" folder)?
- zx2c4 10y agoChaPoly is based on Martin Willi's implementation, but heavily modified. Blake2s is essentially their reference code. Curve25519 is based on Adam Langley's donna.
- clinta 10y agoThanks for being here, I have a few questions. Does the server get a separate wg interface for every client that connects? Or does it do something like multipoint GRE interfaces with next hop addresses in the arp table? Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? Also is it in the scope of this project for peers to discover each other for direct communication, like a Phase3 DMVPN?
- zx2c4 10y ago> Does the server get a separate wg interface for every client that connects? No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. > Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? It uses a 1-RTT ECDH key agreement based on the Noise Protocol Framework, with identity hiding, perfect forward secrecy, and so forth. So, it does what you hoped it does. :) > Phase3 DMVPN I'm not familiar with this, but I'll read up on it. Just found a large cisco document describing it. I suspect that "automatic discovery" wouldn't be very much to my taste, but I'll read up on it before dismissing it wholesale.
- clinta 10y agoThe idea of Phase3 is that you have multiple node routers connected to a VPN hub. Think branch offices. When one node starts to talk to another node, the Hub initially facilitates the traffic, but it sends a NHRP(Next Hop Resolution Protocol) packet to the nodes telling them the public IPs of eachother, the nodes then negotiate their own VPN tunnel and start communicating directly without passing all traffic through the hub. If I understand wireguard correctly it seems NHRP could be run using wiregard for transport, but it would cool if a separate NHRP daemon wasn't required, especially since wiregard is already tracking the mapping of internal to public IPs.
- 10y ago
- nickpsecurity 10y agoDon't have time for a detailed review. However, I like that you're working to replace IPsec with something simpler, easier to use, and with flexible deployment. Crypto algorithms look better than most VPN's I see as well. Good work on all that. Just remember to aid others' verification efforts later on by keeping it modular, minimal shared state, simple constructions in code, and so on. Whatever passes through a decent static analysis tool. Also, one of easiest, formal methods is Design by Contract which can be emulated with asserts for pre- and post-conditions plus main invariants. Quite useful to encode operating assumptions in there. Such can also be used for automating test-case generation, fuzzing, dynamic analysis, and covert channel analysis. Oh yeah, definitely do a covert channel analysis on anything that gets near the keys to plug any leaks.
- zx2c4 10y ago> Just remember to aid others' verification efforts later on by keeping it modular, minimal shared state, simple constructions in code, and so on. Whatever passes through a decent static analysis tool. Yes this absolutely is the goal. I'm trying to keep the codebase as small and clear as possible. > Design by Contract Working out the precise pre and post conditions of every state would indeed be worthwhile. For all state transitions of the protocol, I've worked out by hand every possible combination and accounted it for it. I should publicize this work (i.e. type up my handwritten notes), and then let others join building on top of it.
- nickpsecurity 10y ago"Working out the precise pre and post conditions of every state would indeed be worthwhile. For all state transitions of the protocol, I've worked out by hand every possible combination and accounted it for it. I should publicize this work (i.e. type up my handwritten notes), and then let others join building on top of it." That's actually... great. It's exactly what high-assurance security did in kernels and VPN's. I'm impressed. You should definitely write that up and share it for peer review. Also, since you've done it, the next step is to review each one to make sure security properties are maintained or it fails fast, safe, and loud. :)
- piffey 10y agoHey! Knew I recognized that username. You also make pass which I've been using since you released that too. Definitely going to give this a run. Thanks for more useful tools!
- marios 10y agoFirst of all, congratulations on launching ! This looks interesting and I will be sure to check it out when I get the chance. I see from the examples on the site that it's IPv4 everywhre. Is there IPv6 support ? If not, is it on the roadmap ?
- zx2c4 10y agoIPv6 definitely is supported. I should add some examples. Every place you see an IPv4 address an IPv6 one can go. They can even be mixed and matched. There's full support and it works quite well. Thanks for the documentation suggestion.
- teacup50 10y agoAny chance of switching to a non-GPLv2 license? Broad adoption would be far more likely.
- unethical_ban 10y agoWhat's wrong with GPL2 for adoption?
- teacup50 10y agoOpen source projects that are not GPL'd cannot adopt the code; it's meant to be linked into the kernel, and so distribution will trigger the viral licensing clause covering the entirety of the kernel. For example, there are a myriad of products based on BSD; everything from pfSense at the low-end, the Juniper routers at the high-end. If the goal is to make money by licensing the code for non-GPLv2 use, then the GPL might make sense, if you're unconcerned about limiting market adoption by precluding integration by non-GPL products.
- nickysielicki 10y agoWhat capabilities does this provide over IKEv2 with certificates and MOBIKE for roaming? One disadvantage off the bat is that every operating system from OSX to Windows 7 to Linux to *BSD already has support for IKEv2 and MOBIKE caked in.
- RRRA 10y agoNice work, but I'm wondering why does it have to be in kernel? Couldn't it still be fast and written in a safer than C language considering the security context? (Or we'll still need to get grsec in there... :) Cheers!
- microcolonel 10y agoI suspect it has to be in kernel for efficiency reasons. Because applications access network devices through kernel interfaces; the kernel has to context switch and copy data to and from the userspace VPN process; This can be quite slow. On a microkernel system, the standard way of connecting to the network stack might be through direct shared memory; and on such a system you could manage to run the VPN in userspace at essentially no cost. However, on Linux, most of the network stack is in the kernel; the ABI for interacting with network hardware is stable. So while in theory you could write an efficient userspace VPN, it would require you to modify or at very least recompile your applications.
- JohnGrin 10y agoThanks for information! ExpressVPN is pretty good. I checked it at free vpn check service https://2ip.io/privacy/ https://2ip.io/privacy/ and it shows a high level of efficiency.
- rkeene2 10y agoHow does WireGuard deal with private keys on smartcards or other HSMs ?
- Retr0spectrum 10y agoCan someone explain why being in-kernel is considered a feature?
- zx2c4 10y agoSpeed, simplicity. It's not possible to do highspeed crypto from userspace while still integrating with the usual networking stack. Tun devices result in copies and context switches which makes things quite slow. This also adds quite a bit of simplicity. But sure, I agree, it's scary. But not nearly as scary as the obscenely huge xfrm/ipsec layer in the kernel. Or the dozens of other kernel tunneling deivces available. And I dare even say it's not as scary as most userspace VPN solutions like OpenVPN which are massive code bases. WireGuard, in contrast, aims to be quite minimal in its codebase, so that it can be audited by an individual. I didn't make the title of this HN post, unfortunately. But do note: there _will_ be userspace implementations of WireGuard. It's most certainly not tied to the kernel. It's just that the OP saw me present at a kernel conf about it. :P
- nickpsecurity 10y agoIt's faster. Performance usually matters more than security for most "security" products. ;) Having extra code in kernel is usually just asking for it. Here's one done closer to high-assurance principles that I'm sure the WireGuard scheme could be ported to: http://genode-labs.com/publications/mikro-sina-2005.pdf http://genode-labs.com/publications/mikro-sina-2005.pdf Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.
- zx2c4 10y agoWe'll actually be producing a Rust implementation for userspace. It'd be interesting to see that work ported back to kernelspace. Cool suggestions.
- ksec 10y agoI know asking for MIT / BSD or Apache 2 may be a little bit of stretch. But any chance of LGPL? Or would we need a conplete reimplementation for BSD?
- zx2c4 10y agoI don't really have any problem re-licensing it less restrictively, I don't think. I'll have to think about it for more than 10 seconds I suppose. But I put "GPLv2" there without much thought simply because that's what Linux uses. But you make a good point about the BSDs.
- nickpsecurity 10y agoRemember interoperability in mixed-OS environments. You won't get uptake or contributions from Microsoft, etc. if they have to re-license their kernel in GPL v2. Getting all links encrypted by default might be a worthy enough goal for a BSD license that proprietary will mooch off of. We all benefit in such situations. Especially given how often they muck up VPN's when they code them on their own. ;)
- PeCaN 10y agoAs a hardcore BSD user, GPLv2 is perfectly fine with the BSDs. They all ship with GPLv2 software by default. FreeBSD doesn't like GPLv3, but OpenBSD and DragonFlyBSD don't have a problem with it. I don't know about NetBSD off the top of my head. IMO this seems like something that should be GPL and I think you needn't change it.
- bulatb 10y agoWhat happens if a client gets assigned a new IP that isn't in the server's whitelist? How do they connect?
- zx2c4 10y agoEndpoint IPs are learned based on successfully authenticated/decrypted packets. The Endpoint= entry in the config is just the location of an initial server endpoint. Inner tunnel IPs are fixed in the config, and it's up to things that build ontop of WireGuard to manage this however fits best.
- nikolay 10y agoIs there a way to connect from macOS to the VPN?
- zx2c4 10y agoAs mentioned in the roadmap and the cross-platform page, we're working on a cross-platform userspace client, so Mac and Windows users can use it too. It's in the works!
- nikolay 10y agoThank you!
- x0ra 10y agoSo what's the point ? Linux is a niche market. Mac & Windows will be the vast majority of your users and won't enjoy your killer kernel-based feature...
- cakoose 10y agoThis comment was marked 'dead', but I think it was a useful question (though maybe a little aggressive in its wording): > So what's the point ? Linux is a niche market. Mac & Windows will be the vast majority of your users and won't enjoy your killer kernel-based feature... Even when Windows/Mac are the vast majority of clients, each client only needs to process its own traffic. The VPN gateway is more likely the bottleneck, since it needs to process everyone's traffic. There are many organizations that would have no problem running Linux on the VPN gateway and could reap the benefits. Also, the Linux in-kernel implementation is just the first(?) thing being released. WireGuard is a VPN protocol and its killer feature is good security that's simple enough to implement in 4000 lines of code. This simplicity makes it easier for someone to write a Windows/Mac kernel driver.
- x0ra 10y ago4kloc is rather unimpressive if you delegate everything to already existing libraries.
- 10y ago
- throwanem 10y agoLooks awesome! I can't wait to play with it when it hits 1.0. In advance of that, I'm curious: What's the tl;dr: on how this compares to Tinc? In particular, I'm wondering what WireGuard's mobile story looks like, especially in comparison with Tinc's (which is pretty rudimentary as far as I can tell), and about the extent of effort that's likely to be involved in ongoing configuration management.
- zx2c4 10y agoFaster, more secure, and works quite well with mobile thanks to built-in roaming.
- wargame 10y agoIs it possible to use TCP-only?
- zx2c4 10y agoWireGuard is UDP only. For TCP or SSL tunneling, look at a million other things that already do this.
- cakoose 10y ago(I don't know much about networking.) What are the advantages of doing UDP instead of IP? It seems like, all else being equal, doing IP has the advantage of working with UDP and TCP out of the box.
- amluto 10y agoA couple questions: How do you deal with MTU? OpenVPN's handing is particularly bad [1]? Is the whole protocol in-kernel or just the data plane? For admins who want to provision large number of clients, do you ever plan to implement some kind of certificate hierarchy? [1] https://community.openvpn.net/openvpn/ticket/375 https://community.openvpn.net/openvpn/ticket/375
- zx2c4 10y ago> How do you deal with MTU? OpenVPN's handing is particularly bad [1]? MTU is dealt with the same way as other kernel space tunneling devices. > Is the whole protocol in-kernel or just the data plane? All of it, which is why there's so much emphasis on simplicity. > For admins who want to provision large number of clients, do you ever plan to implement some kind of certificate hierarchy? Rather, the goal is to make the kernel interface very simple and minimal, so that admins can then glue ontop whatever situation they want. This could be certificates, or pigeons, but the important thing is that it's a layer ontop (in userspace), and not intimately bound to the core.
- clinta 10y agoAre there currently methods where unknown public keys are passed to a userspace application to be verified? Or is this something that will be implemented in the future?
- tw04 10y agoWhy would I want this over softether?
- hueving 10y agoWhy is this in the kernel? It seems to me like a failed separation of concerns compared to running this in userspace. There shouldnt be anything magical requiring this level of coupling.
- tptacek 10y agoSevere performance impact. Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread: Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. In a serious VPN deployment, if you lose code execution on the VPN server, whether the attacker took the kernel or just a userland process is somewhat far down the list of concerns you have to deal with. A better first concern is "how many machines inside the VPN did the attacker just get code execution on because they can now make direct TCP connections to all our internal services". From that vantage point, I'm a little less concerned about whether my VPN server is at CPL0, and a lot more concerned with things like "how complex is this code and how straightforward is it to audit".
- derefr 10y agoI'm guessing the parent wasn't really considering the kernel/userland distinction in terms of security (for, after all, a daemon running as root in userland isn't all that different from running in the kernel in terms of attack surface; the real security boundary lies between privileged/unprivileged in userland, not between kernel and userland.) Rather, I expect what the parent wanted to assert was that a novel malformed packet to a badly written VPN shouldn't bring down the entire VPN gateway machine, but rather just the VPN daemon itself, which can then be brought back up by init(8). Or, to put it another way—even though the Linux kernel is monolithic, it can still pay to treat it as a microkernel and isolate fault-prone code outside of it. This was one of the original big benefits of running e.g. the NTFS-3G in FUSE, when that support was experimental: the NTFS-3G driver did crash—often!—and your OS stayed up. The—usually external—drive would just get unmounted, and have to be fsck(8)ed. Now, the argument you used also kind of answers this: in full deployments, we've got dedicated VPN gateways on either side of the connection, so if the VPN process crashes, the whole machine may as well have crashed, since it's not doing much of anything else anyway. That's probably true for most networks, but I could think of one exception: a VPN gateway serving multiple customer sites. You'd really rather that one VPN "receiver" process crash on that host (like one webserver instance serving one request) than that the whole machine crash.
- amq 10y agoPerformance comparison would be welcome, especially on low-end hardware. For example, I'm getting 12 Mbps with OpenVPN BF-CBC on AR9341, I wonder what could WireGuard achieve.
- zx2c4 10y agoI think I have this board laying around actually. A friend is working on OpenWRT packages so some benchmarking on there should be around the corner.
- naasking 10y agoSeems like an interesting project. How does it compare to zerotier: https://www.zerotier.com/ https://www.zerotier.com/
- tptacek 10y agoSimilar cryptographic building blocks. WireGuard has an emphasis on no-negotiation, which it inherits from Noise, which is Trevor Perrin's well-regarded crypto protocol construction kit. As an application, WireGuard is _way_ simpler than ZeroTier; it's something you would build the remaining 90% of ZeroTier on top of.
- nickpsecurity 10y agoI was going to ask that myself but ZeroTier provided a hint. It seems to be aiming for more than a simple, IPsec replacement. It will have more features and complexity no matter what. Also, Jason already speced out the WireGuard protocol plus intends a Rust port. Will significantly increase code-level security over ZeroTier. Both need strong, peer review at protocol and implementation levels, though. As always with these things.
- api 10y agoDesigner/developer of ZeroTier here. :) Yes, our goals are much broader than VPN. You can think of ZeroTier as a virtual smart switch built on a P2P network; a "smart switch for Earth." We want to totally abstract away the physical network. A lot of ZT's complexity over WireGuard is about working around the underlying network (NAT-t, dual-stack support, dealing with timeouts and path failures, relay fallback, peer location and roaming, redundancy, etc.) as well as smart switch features and robustness against DOS attacks and similar things. Nevertheless ZT's core code really isn't that big. The core protocol implementation is 23,000 lines of C++ code. This includes many very long comments documenting the protocol, etc., so total lines of actual code is probably more like 18-20k. It's comparable to an embedded TCP stack. WireGuard does have some things in common with ZeroTier, such as the use of cryptography to identify endpoints and eliminate the hard-coding of endpoint addresses. This is one of many ways that IMHO cryptography actually simplifies networking. I really like the WireGuard design in general and I think it has a somewhat different use case from ZeroTier, namely fast long-lived provisioned links across WANs and insecure LANs. You could use ZT for that but this being in-kernel makes it likely faster. In any case I hate IPSec (over-engineered mess, terribly hard to configure) so any alternative to that is welcome. (Edit: there are things you can do to speed up user-mode networking like zero-copy data paths, etc., so it's not guaranteed that this would always be faster. But that's another topic.)
- maxhou 10y agoDoes the protocol implement any kind of negotiation (ciphers, ...) ? if not, how would you handle future type of attacks against the then hardwired constructions ? I fully agreed that being in-kernel is the right choice for performance, but the chosen constructs excludes the possibility of using any type of existing crypto hardware accelerator that shines in the IPSEC use-case (cache cold data == no cache flush overhead, fully async processing of packets with DMA chaining). Time to start lobbying SOC vendors :)
- zx2c4 10y agoThe cipher suite is part of the Noise preamble, so all operations are crytographically bound to the cipher suite to prevent against related-algo attacks. WireGuard itself has no plans for cipher agility, something that is considered an anti-feature. If these ciphers are ever considered problematic, we'll change them and release a new version (with an incremented preamble), and the new set of ciphers will be similarly non-configurable. Fortunately AVX2-accelerated (and soon AVX512-accelerated) ChaPoly is super fast in pretty much all hardware.
- teddyh 10y agoNote: This project, despite having the text of the GPL 2 in a file named “COPYING”, is not actually licenced under GPL 2. The actual copyright statement found in source files is “Copyright 2015-2016 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.”. It does not reference the GPL. This means, legally, that nobody can do anything with it. If the author actually meant to licence it under the GPL 2, he should read and follow the instructions in the GPL itself, more specifically the section at the end titled “How to Apply These Terms to Your New Programs”.
- icebraining 10y agoThat may technically be true, but if the author was to sue anyone based on that argument, this project itself would be in violation of copyright law, since all the code seems to be distributed only as a Linux kernel module (with all files #including kernel headers and such) and so it actually has to be distributed under the GPLv2.
- teddyh 10y agoThis is true, but I imagine that no company will actually use or distribute this project in any way, since it is actually illegal (however technically) for them to do so until this issue is resolved.
- asymmetric 10y agoJust wanted to point out that the author is also behind the excellent password manager pass: https://www.passwordstore.org/ https://www.passwordstore.org/. Congratulations.
- ronnier 10y agoThat's a very nice tool, but I dislike how it leaks information via the visible directory structure and filenames.
- eximius 10y agoPlease let me know if this has already been posted. Is there any worry that someon might perform a DoS attack against a client by replaying a valid packet from the target from different hosts so that the other servers cannot correctly route to the real IP of the target? This is based solely off of the description on the homepage and it might not be possible due to implementation details I'm unaware of.
- zx2c4 10y agoReplay attacks don't work because of the nonce, so that's handled successfully. But an attacker with an active man in the middle position might change the outer (unencrypted) src IP of a packet. However, that src will need to be able to produce authentic replies; otherwise the session will quickly be deemed invalid, so that mitigates any potential very oddball amplification attacks you could dream up. And regardless, an attacker with this kind of active man in the middle can already drop packets at will, so this isn't a vulnerability.
- dmitrygr 10y ago""Encrypt entire IP packet using peer ABCDEFGH's public key."" Really? 1. RSA & ECC are both too slow for this to be performant 2. Padding??? Certainly you meant "encrypt using a negotiated symmetric key". And earlier you meant to say "negotiate symmetric key with peer"
- zx2c4 10y agoYour concern (1) is valid, but fortunately that's an over-simplification in the casual introduction part of documentation, which I'll fix. Sorry about that. This should read more like, "Encrypt entire IP packet using the symmetric session associated with peer ABCDEFGH." Thanks for pointing this out. As for (2), WireGuard indeed does padding; see the protocol page or the paper for details.
- dmitrygr 10y agoMy concern is alleviated Thanks!
- wmf 10y agoI'm surprised to see that ChaCha-Poly is faster than hardware-accelerated AES-GCM. Any ideas why?
- maffblaster 10y agoNice work! Exciting!!
- vonnyfly 10y agoDo you have try this in China internet? As we know, China has a more complicated network. UDP packets have a large loss. If it could work better than ocserv, this vpn will be a milestone.
- alainchabat 10y agosame question here
- Anonionman 10y agoIt would be useful to have option to connect to VPN server trough SOCKS/HTTP proxy like you can do with OpenVPN, and it is useful for traffic obfuscation and combining VPN with Tor/I2P. Another thing that I like is XOR patch for OpenVPN (https://github.com/clayface/openvpn_xorpatch https://github.com/clayface/openvpn_xorpatch), that can be very useful in hiding you are connecting to VPN.
- lawnchair_larry 10y agoYou don't want this in the kernel.
- iT5rCb8x 10y agoThis looks like an amazing project, congratulations. I've been longing for something like that for quite some time. I fully agree with your analysis of the VPN protocols & implementations landscape. Since this is a security-critical project, do you mind filling a CII Best Practices questionnaire? https://bestpractices.coreinfrastructure.org/ https://bestpractices.coreinfrastructure.org/
- felixding 10y agoDoes it work against Deep Packet Inspection? I live in China, most popular VPN protocols can't pass through the great firewall. Sorry for my English.