* WireGuard with obfuscation support @ 2021-09-26 12:09 el3xyz 2021-09-27 0:53 ` Nico Schottelius 2021-09-27 16:21 ` Jason A. Donenfeld 0 siblings, 2 replies; 15+ messages in thread From: el3xyz @ 2021-09-26 12:09 UTC (permalink / raw) To: wireguard Hey all, I guess this topic is, at the very least, not new, but there is still no solution. In the country where I live internet censorship increases year after year and more network operators start blocking WG. With that being done I'm stuck to ShadowSocks which is slower and less secure on desktops then WG. That said I decided to implement obfuscation for WG at least for my own use and kindly asking for code review and possible improvements: https://github.com/el3xyz/wireguard-linux-compat To my understanding there are several ways WG is detected by DPI * Port 51820 (easily fixed) * 4-byte message tag * Fixed message lengths * MAC2 which is all zeroes, unless cookie message is received (high load scenario) To make detection more difficult two things are being done * handshake initiation, response and cookie messages are padded with random sized garbage * Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions). I have tools and Linux driver working already so anyone interested can try this out. Cheers ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-26 12:09 WireGuard with obfuscation support el3xyz @ 2021-09-27 0:53 ` Nico Schottelius 2021-09-27 7:11 ` Bruno Wolff III 2021-09-27 16:21 ` Jason A. Donenfeld 1 sibling, 1 reply; 15+ messages in thread From: Nico Schottelius @ 2021-09-27 0:53 UTC (permalink / raw) To: el3xyz; +Cc: wireguard Hey, el3xyz <el3xyz@protonmail.com> writes: > [...] > To make detection more difficult two things are being done > * handshake initiation, response and cookie messages are padded with random sized garbage > * Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions). > [...] I did not have a look at the code itself, but travelling around the world, I appreciate the direction a lot. While from a safety perspective this does not anything, it can add a lot to the usability / being able to use wireguard at all. I'd appreciate if wireguard upstream would take this in, maybe even supporting multiple / dynamic listen ports. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 0:53 ` Nico Schottelius @ 2021-09-27 7:11 ` Bruno Wolff III 2021-09-27 7:34 ` Roman Mamedov 2021-09-27 7:44 ` Nico Schottelius 0 siblings, 2 replies; 15+ messages in thread From: Bruno Wolff III @ 2021-09-27 7:11 UTC (permalink / raw) To: Nico Schottelius; +Cc: el3xyz, wireguard On Mon, Sep 27, 2021 at 09:53:08 +0900, Nico Schottelius <nico.schottelius@ungleich.ch> wrote: > >I'd appreciate if wireguard upstream would take this in, maybe even >supporting multiple / dynamic listen ports. The problem is mostly orthogonal to Wireguard. There isn't going to be a one size fits all solution for hiding traffic. Failures in hiding traffic are potentially very bad for individuals. As such general solutions are not something you can recommend universally to people, as amateurs are not going to be able to make good decisions about the risks and some may get themselves tortured and killed. This may not be something the developers for Wireguard want to be responsible for. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 7:11 ` Bruno Wolff III @ 2021-09-27 7:34 ` Roman Mamedov 2021-09-27 9:14 ` Bruno Wolff III 2021-09-27 7:44 ` Nico Schottelius 1 sibling, 1 reply; 15+ messages in thread From: Roman Mamedov @ 2021-09-27 7:34 UTC (permalink / raw) To: Bruno Wolff III; +Cc: Nico Schottelius, el3xyz, wireguard On Mon, 27 Sep 2021 02:11:30 -0500 Bruno Wolff III <bruno@wolff.to> wrote: > On Mon, Sep 27, 2021 at 09:53:08 +0900, > Nico Schottelius <nico.schottelius@ungleich.ch> wrote: > > > >I'd appreciate if wireguard upstream would take this in, maybe even > >supporting multiple / dynamic listen ports. > > The problem is mostly orthogonal to Wireguard. There isn't going to be a > one size fits all solution for hiding traffic. Failures in hiding traffic > are potentially very bad for individuals. As such general solutions are > not something you can recommend universally to people, as amateurs are > not going to be able to make good decisions about the risks and some may > get themselves tortured and killed. > > This may not be something the developers for Wireguard want to be > responsible for. No need to make DPI's job especially easy either. Don't over-estimate the resources available to DPIs, if there aren't easy ways to block, it might be almost as good as unblockable. And it is far from all cases that hiding traffic would result in bad consequences. Just hiding it enough so it evades the dumb automated filter, many people will thank you. As far as I understand right now WireGuard is very vulnerable to being blocked, due to the fixed 4 bytes at the beginning(?) of each packet. At least that needs to be randomized/encrypted. Just make the entire packet look like random noise - that's the sign of good crypto, right? It is even somewhat surprising as to why that's not the case already. -- With respect, Roman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 7:34 ` Roman Mamedov @ 2021-09-27 9:14 ` Bruno Wolff III 2021-09-27 9:36 ` Roman Mamedov 0 siblings, 1 reply; 15+ messages in thread From: Bruno Wolff III @ 2021-09-27 9:14 UTC (permalink / raw) To: Roman Mamedov; +Cc: Nico Schottelius, el3xyz, wireguard On Mon, Sep 27, 2021 at 12:34:39 +0500, Roman Mamedov <rm@romanrm.net> wrote: >On Mon, 27 Sep 2021 02:11:30 -0500 > >Don't over-estimate the resources available to DPIs, if there aren't easy >ways to block, it might be almost as good as unblockable. > >And it is far from all cases that hiding traffic would result in bad >consequences. Just hiding it enough so it evades the dumb automated filter, >many people will thank you. If someone is having their Wireguard traffic blogged, there is a good chance that they will be negative consequences to trying to evade the block. Just getting detected will often be enough to trigger these consequences, even if the traffic is getting through. This isn't a simple problem. The assumption is that someone is seeing your network traffic and blocking it. They are still going to see it even if you disguise it. So you are going to need to disquise it as something that whoever is watching isn't going to care about. That is going to vary a lot depending on who is watching. You may also need to hide who you are communicating with. In some cases that will be even more important. There are going to be a number of ways to detect Wireguard traffic and it is pretty unlikely that the bar for detection can be raised enough to be relevant with a few simple changes to the protocol. This suggest that Wireguard is not the correct place to be doing these things. As suggested in another followup, this fits a lot closer to tor's mission and that would probably be a better place to look for help. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 9:14 ` Bruno Wolff III @ 2021-09-27 9:36 ` Roman Mamedov 2021-09-27 10:21 ` Bruno Wolff III 0 siblings, 1 reply; 15+ messages in thread From: Roman Mamedov @ 2021-09-27 9:36 UTC (permalink / raw) To: Bruno Wolff III; +Cc: Nico Schottelius, el3xyz, wireguard On Mon, 27 Sep 2021 04:14:35 -0500 Bruno Wolff III <bruno@wolff.to> wrote: > This isn't a simple problem. The assumption is that someone is seeing > your network traffic and blocking it. The assumption is that there's an appliance at the ISP which has a DROP rule for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules to process as well, so it can't spend "too much" time on specifically WG. > They are still going to see it even if you disguise it. With obfuscation there would be UDP packets of random junk, and it would be a much harder job to come up with a rule to drop those without affecting anything else. > So you are going to need to disquise it as something that whoever is > watching isn't going to care about. That is going to vary a lot depending on > who is watching. You may also need to hide who you are communicating with. > In some cases that will be even more important. You are going full-on "Enemy of the state" movie. The reality is most often a lot simpler and more benign. > There are going to be a number of ways to detect Wireguard traffic and > it is pretty unlikely that the bar for detection can be raised enough to > be relevant with a few simple changes to the protocol. That's not a justification for not trying at all. -- With respect, Roman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 9:36 ` Roman Mamedov @ 2021-09-27 10:21 ` Bruno Wolff III 2021-09-27 13:01 ` Konstantin Ryabitsev 2021-09-27 15:28 ` StarBrilliant 0 siblings, 2 replies; 15+ messages in thread From: Bruno Wolff III @ 2021-09-27 10:21 UTC (permalink / raw) To: Roman Mamedov; +Cc: Nico Schottelius, el3xyz, wireguard On Mon, Sep 27, 2021 at 14:36:28 +0500, Roman Mamedov <rm@romanrm.net> wrote: >On Mon, 27 Sep 2021 04:14:35 -0500 >Bruno Wolff III <bruno@wolff.to> wrote: > >> This isn't a simple problem. The assumption is that someone is seeing >> your network traffic and blocking it. > >The assumption is that there's an appliance at the ISP which has a DROP rule >for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules >to process as well, so it can't spend "too much" time on specifically WG. > >> They are still going to see it even if you disguise it. > >With obfuscation there would be UDP packets of random junk, and it would be a >much harder job to come up with a rule to drop those without affecting >anything else. If your ISP is blocking your Wireguard traffic call them up and complain. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 10:21 ` Bruno Wolff III @ 2021-09-27 13:01 ` Konstantin Ryabitsev 2021-09-27 13:48 ` Lonnie Abelbeck 2021-09-27 15:28 ` StarBrilliant 1 sibling, 1 reply; 15+ messages in thread From: Konstantin Ryabitsev @ 2021-09-27 13:01 UTC (permalink / raw) To: Bruno Wolff III; +Cc: Roman Mamedov, Nico Schottelius, el3xyz, wireguard On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote: > > With obfuscation there would be UDP packets of random junk, and it would be a > > much harder job to come up with a rule to drop those without affecting > > anything else. > > If your ISP is blocking your Wireguard traffic call them up and complain. There have been times when I found myself briefly at a location that didn't allow wireguard traffic, like an airport or a public library. Complaining wouldn't have been a useful course of action to take, since I needed a solution at that particular time and place. -K ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 13:01 ` Konstantin Ryabitsev @ 2021-09-27 13:48 ` Lonnie Abelbeck 0 siblings, 0 replies; 15+ messages in thread From: Lonnie Abelbeck @ 2021-09-27 13:48 UTC (permalink / raw) To: Konstantin Ryabitsev; +Cc: WireGuard mailing list > On Sep 27, 2021, at 8:01 AM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote: > > On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote: >>> With obfuscation there would be UDP packets of random junk, and it would be a >>> much harder job to come up with a rule to drop those without affecting >>> anything else. >> >> If your ISP is blocking your Wireguard traffic call them up and complain. > > There have been times when I found myself briefly at a location that didn't > allow wireguard traffic, like an airport or a public library. Complaining > wouldn't have been a useful course of action to take, since I needed a > solution at that particular time and place. Public hotspots may just be blocking UDP/51820, not DPI. Some time ago Jason posted an iptables REDIRECT workaround at your WG "server" endpoint [1] I have found typically either 443 or 4500 will work if 51820 is blocked. Lonnie [1] https://lists.zx2c4.com/pipermail/wireguard/2018-November/003503.html ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 10:21 ` Bruno Wolff III 2021-09-27 13:01 ` Konstantin Ryabitsev @ 2021-09-27 15:28 ` StarBrilliant 2021-09-27 15:59 ` Nico Schottelius 1 sibling, 1 reply; 15+ messages in thread From: StarBrilliant @ 2021-09-27 15:28 UTC (permalink / raw) To: wireguard On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote: > If your ISP is blocking your Wireguard traffic call them up and complain. All ISPs in China is blocking Wireguard traffic. If you call any of them up, you will end up in jail. There was a case where one user sued their ISP for blocking Google, and got prosecuted until disappear in public. I believe the original poster is located in China rather than other countries, because the word “Shadowsocks” was mentioned, which is the only operable proxy software there -- its obfuscation is strong, but is slow and never cryptographically proved safe. I would highly recommend you to test Wireguard on a virtual host in China to experience how the DPI is carried out, or to run a VPN service for Chinese users. The DPI system tries to create evidences to fool the user into believing it to be a network congestion, rather than an interference. The traffic will get interrupted after a few days, with increased packet loss rate each day. After a certain number of days, all packets will get dropped. For any of you who is curious: The DPI system uses a statistical model, which means you get a higher chance of blocking if the source ASN is from a data center rather ran residential Internet; or if your size / timing / number of packets also match the characteristics of web browsing in addition to the usual Wireguard pattern. The sensitivity can even be tuned so the interference becomes stronger during June, August, and October. It is so unfortunate this situation affects 1/5 of the world population. The Chinese users used to be too optimistic about Wireguard. Developing an obfuscation plugin framework is not sufficient to fight against it, but there aren't too much that one can do. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 15:28 ` StarBrilliant @ 2021-09-27 15:59 ` Nico Schottelius 2021-09-27 16:37 ` StarBrilliant 0 siblings, 1 reply; 15+ messages in thread From: Nico Schottelius @ 2021-09-27 15:59 UTC (permalink / raw) To: StarBrilliant; +Cc: wireguard StarBrilliant <coder@poorlab.com> writes: > On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote: >> If your ISP is blocking your Wireguard traffic call them up and complain. > > All ISPs in China is blocking Wireguard traffic. If you call any of > them up, you will end up in jail. There was a case where one user sued > their ISP for blocking Google, and got prosecuted until disappear in > public. > [...] Thanks a lot for the detailed explanation. While we have become a bit off-topic (more of the why then the how) in regards to wireguard, I think above explanation is important. Wireguard's purpose is to be a secure VPN tunnel and I personally would love if we can add "reliable" to its feature list. However that would need more advanced support, like obfuscation is providing. I'm not saying obfuscation is the only method, but compared to a DPI with statistical analysis, I think we are pretty far away from being reliable in hostile networks. Maybe extending wireguard with obfuscation is out of scope of this project, but then it might be an idea to wrap the wireguard traffic into other protocols. I'm not sure how much wireguard depends on the IP/UDP layers, but assuming it only uses it for payload, maybe it makes sense to wrap wireguard into HTTP, HTTPS, SMTP (+TLS), IMAP(S) or even DNS (slow). I am aware that there is a variety of tools out there that handle some of the tunnel ideas. Given that all of these approaches are actually rather trivial to implement, is there any easy way to grab the outgoing wireguard packets without the need of creating n artifical local UDP endpoints? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 15:59 ` Nico Schottelius @ 2021-09-27 16:37 ` StarBrilliant 0 siblings, 0 replies; 15+ messages in thread From: StarBrilliant @ 2021-09-27 16:37 UTC (permalink / raw) To: Nico Schottelius; +Cc: wireguard On Mon, Sep 27, 2021, at 15:59, Nico Schottelius wrote: > > StarBrilliant <coder@poorlab.com> writes: > > > On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote: > >> If your ISP is blocking your Wireguard traffic call them up and complain. > > > > All ISPs in China is blocking Wireguard traffic. If you call any of > > them up, you will end up in jail. There was a case where one user sued > > their ISP for blocking Google, and got prosecuted until disappear in > > public. > > [...] > > I'm not sure how much wireguard depends on the IP/UDP layers, but > assuming it only uses it for payload, maybe it makes sense to > wrap wireguard into HTTP, HTTPS, SMTP (+TLS), IMAP(S) or even DNS > (slow). I am aware that there is a variety of tools out there that > handle some of the tunnel ideas. > > Given that all of these approaches are actually rather trivial to > implement, is there any easy way to grab the outgoing wireguard packets > without the need of creating n artifical local UDP endpoints? > For your first question: There have been multiple success stories for pluggable obfuscation layers: One from Tor Project, another from V2Ray. They proved even if any single obfuscation is not mature, as long as new obfuscation plugins emerge way way faster than their statistical model training speed, this cat-and-mouse game can win. So no worries about this question. For the second question: This is very important because current Wireguard has huge pain with obfuscation plugins. * Firstly, Wireguard cannot bind to localhost only. Using iptables to restrict access does not avoid port number wasting. * Second, Wireguard can't use Unix socket for transport -- there are only 65535 UDP ports, it is not economic to waste a dozen of them just for connecting to an obfuscation plugin located at localhost. * Last but not least, Wireguard relies on certain end-to-end features: If the a fragmented IP packet arrives, which is a feature that some obfuscation plugin relies on, Wireguard's kernel implementation will behave strangely. Also Wireguard needs to know the endpoint IP address to perform roaming. Previously we prefer to patch the Go version because the above three issues are almost impossible to solve in kernel space. But the Wireguard upstream is going to deprecate the Go version on Linux platforms, which would not be a good news for the obfuscation world. If Wireguard supports listening onto a Unix socket and plugin protocols like “HAProxy protocol”, or “Tor FTE protocol” or “Shadowsocks SIP003 protocol” (not sure which can work with UDP), then obfuscation plugins can happily work with Wireguard. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 7:11 ` Bruno Wolff III 2021-09-27 7:34 ` Roman Mamedov @ 2021-09-27 7:44 ` Nico Schottelius 2021-09-27 8:17 ` Fredrik Strömberg 1 sibling, 1 reply; 15+ messages in thread From: Nico Schottelius @ 2021-09-27 7:44 UTC (permalink / raw) To: Bruno Wolff III; +Cc: Nico Schottelius, el3xyz, wireguard Bruno, thanks for raising 2 very important points: Bruno Wolff III <bruno@wolff.to> writes: > On Mon, Sep 27, 2021 at 09:53:08 +0900, > Nico Schottelius <nico.schottelius@ungleich.ch> wrote: >> >>I'd appreciate if wireguard upstream would take this in, maybe even >>supporting multiple / dynamic listen ports. > > The problem is mostly orthogonal to Wireguard. There isn't going to be > a one size fits all solution for hiding traffic. Failures in hiding > traffic are potentially very bad for individuals. As such general > solutions are not something you can recommend universally to people, > as amateurs are not going to be able to make good decisions about the > risks and some may get themselves tortured and killed. 1) being able to communicate for non-tech savvy users This is a very important point, especially a failure to do so might be critical in reality like you pointed out. So the easier we make it for non-tech people to "just get it working", many more life's will be saved from torture. Because the alternative are insecure communication channels. > This may not be something the developers for Wireguard want to be > responsible for. 2) The responsibility of software developers As usual with GPL/similar licenses, software is provided AS-IS. We are not selling a "fully autonomous car" here that is actually not able to drive on its own, but instead giving a warranty free software to people. It's important to raise these points, but from what I can see the easier we make it for people to securely communicate, the less likely threats arrive. Outside of the scope of wireguard I see tunnel combinations like moving wireguard traffic through udp+tcp/53, tcp/80+443, which are also interesting options, but are probably solved with other tunneling tools. Cheers, Nico -- Sustainable and modern Infrastructures by ungleich.ch ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-27 7:44 ` Nico Schottelius @ 2021-09-27 8:17 ` Fredrik Strömberg 0 siblings, 0 replies; 15+ messages in thread From: Fredrik Strömberg @ 2021-09-27 8:17 UTC (permalink / raw) To: WireGuard mailing list Hi everyone, On Mon, Sep 27, 2021 at 9:55 AM Nico Schottelius <nico.schottelius@ungleich.ch> wrote: > Bruno Wolff III <bruno@wolff.to> writes: > > On Mon, Sep 27, 2021 at 09:53:08 +0900, > > Nico Schottelius <nico.schottelius@ungleich.ch> wrote: > > > > The problem is mostly orthogonal to Wireguard. There isn't going to be > > a one size fits all solution for hiding traffic. Exactly. And it would be a big mistake to attempt to merge obfuscation support into WireGuard itself. Tor's approach of pluggable transports is probably the right one. https://www.wireguard.com/known-limitations/ "WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however." Here are my arguments: https://lists.zx2c4.com/pipermail/wireguard/2018-September/003292.html Cheers, Fredrik Stromberg ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: WireGuard with obfuscation support 2021-09-26 12:09 WireGuard with obfuscation support el3xyz 2021-09-27 0:53 ` Nico Schottelius @ 2021-09-27 16:21 ` Jason A. Donenfeld 1 sibling, 0 replies; 15+ messages in thread From: Jason A. Donenfeld @ 2021-09-27 16:21 UTC (permalink / raw) To: el3xyz; +Cc: wireguard Hey Evgeny, There are some neat aspects of the approach here. Encrypting using the pubkey has the nice effect of making packets look like noise while also being sufficiently peer-linked that it might not be super feasible to detect (though still possible I suppose). I don't think we'd merge something like this into wireguard-itself, unfortunately. Obfuscation is a bit of a cat and mouse game, and were we to bake a handful of methods into wireguard, much focus would be spent on detecting those, and then the whole thing would be moot. From my own obfuscation projects, I've found the most effective techniques involve mimicry of other explicitly-allowed protocols, rather than just turning packets into noise, and mimicking the related packet timing and length relations of those protocols too. It's possible to do this in part using Markov chains, but also for your likely use case, you may be able to just code logic for fake tcp + http -looking sessions, or perhaps quic in the future. But your likely use case is also not likely to be the same as others' use cases for obfuscation. For example, while much obfuscation focuses on censorship resistance, there's another corner that focuses on IDS evasion, like hiding inside of Kerberos or RDP or even resembling SIGTRAN packets. And even in the censorship resistance space, there are often important tradeoffs to be made between performance and detection: do you want your connection to be as speedy as possible, or do you want to ensure that you won't be detected? What are the repercussions of failure for each case? And moreover, what about when targeted traffic shaping is used in connection with DPI or related heuristics? In that case, a popular technique appears to be adding FEC to packets. And so on and so forth. This all is to say that the obfuscation game is a big rabbit hole of sorts, and there's unlikely to be one solution for the many applications of it. For that reason, as I've written on this list before, I think obfuscation ought to be in a layer above wireguard, not within it. You can do this by setting the endpoint to be a localhost udp port, or better, by writing a netfilter module or using something like NFQUEUE to do it in userspace. While there's a lot of enthusiasm for "pluggable transports" and such, I actually don't think it's a bad idea to violate the layering distinction and borrow things like peer public keys when that makes for a potentially slicker system. For example, I could imagine a netfilter plugin that specifically attaches to a wireguard interface, and uses config information from it to do per-peer obfuscation, so that additional identities don't need to be configured. An admin would run `iptables -t mangle -A OUTPUT -m evgeny_wg_thing --out-iface wg0 -j EVGENYS_COOL_OBFS_THING_OUT && iptables -t mangle -A INPUT -m evgeny_wg_thing --in-iface wg0 -j EVGENYS_COOL_OBFS_THING_IN` and then presto, everything would work with no additional configuration. Splitting out your ideas into something that runs adjacent to wireguard but works intimately with it might require a little bit more work in the short term, but I think long term that will lead to a more sound design, and it could grow and morph all sorts of interesting different modes. Jason ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-09-27 16:37 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-26 12:09 WireGuard with obfuscation support el3xyz 2021-09-27 0:53 ` Nico Schottelius 2021-09-27 7:11 ` Bruno Wolff III 2021-09-27 7:34 ` Roman Mamedov 2021-09-27 9:14 ` Bruno Wolff III 2021-09-27 9:36 ` Roman Mamedov 2021-09-27 10:21 ` Bruno Wolff III 2021-09-27 13:01 ` Konstantin Ryabitsev 2021-09-27 13:48 ` Lonnie Abelbeck 2021-09-27 15:28 ` StarBrilliant 2021-09-27 15:59 ` Nico Schottelius 2021-09-27 16:37 ` StarBrilliant 2021-09-27 7:44 ` Nico Schottelius 2021-09-27 8:17 ` Fredrik Strömberg 2021-09-27 16:21 ` Jason A. Donenfeld
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).