Re: [feature request] To support "Wireguard over raw TCP"

Re: [feature request] To support "Wireguard over raw TCP"

[StarBrilliant]

On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
<kexianbin@diyism.com> wrote:
>
> Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic into raw tcp (config files as follows),
> It's very stable on my home network than using wireguard alone,
> But if we can integrate RAW TCP feature into wireguard, it would significantly improve performance and stability for end users.
>
>
> from: https://gist.github.com/diyism/1b80903a83776675031c73ae499438d8#file-wireguard_config-txt-L145
>
> $wget https://github.com/wangyu-/udp2raw-tunnel/releases/download/20180830.2/udp2raw_binaries.tar.gz
> $tar xzvf udp2raw_binaries.tar.gz
> $sudo cp udp2raw_amd64 /usr/bin/
> $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
> $cat /etc/wireguard/wg0.conf
> [Interface]
> PrivateKey = <client privkey>
> Address = 10.0.0.3/32
> ListenPort = 24447
> MTU = 1300
> PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server pubkey> allowed-ips 0.0.0.0/0
> PostDown = ip route del 10.0.0.0/24
>
> [Peer]
> #10.0.0.1
> PublicKey = <server pubkey>
> Endpoint = 127.0.0.2:24448
> #AllowedIPs = 0.0.0.0/0
>
> $sudo wg-quick down wg0 ; sudo wg-quick up wg0
> $ping 10.0.0.1
> 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
> $sudo ip route add 104.24.0.0/16 dev wg0
> $ping myip.ipip.net
> PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
> 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185 ms
> $curl http://myip.ipip.net
> IP：<server ip>
>
> #take care, "MTU = 1300" in wg0.conf is needed when wireguard over udp2raw, or else most https requests will be blocked because of mtu problem.


Hello Kexianbin,

This is an UNOFFICIAL response to your question. (But I think the
official developers may have similar answers.)

Wireguard probably will not accept an official integration to udp2raw.
The reasons are:

1) Wireguard wants to keep their kernel part code minimized, therefore
easy for security auditing, and less bugs.The UDP protocol is actually
very simple and straightforward. (By the way, if you intended to use
Wireguard in China, be informed that this is a protocol that is very
easy to block by the ISP.)

2) I have read the source code of udp2raw. To be frank, the code is of
very low quality. For this reason, I don't think udp2raw would be
integrated into Wireguard unless it's rewritten.

3) Udp2raw is not suitable for everyone or for every country. For
example udp2raw may have problems passing middleboxes, which is common
among satellite ISPs in Oceania. Middleboxes break and resemble TCP
segments thus make udp2raw literally unusable. Also it is not
congestion friendly (by design), so a massive deployment may affect
the global Internet ecology.

However the good news is, Wireguard provides an open control interface
(see https://www.wireguard.com/xplatform/ ). By utilizing this
interface, we can develop an alternate frontend application other than
the official command "wg", that automatically sets up the kernel
Wireguard kernel part and a userland udp2raw part, packaged as one
application.


My words for Wireguard developers:

1) In case you may not know the udp2raw protocol, here is a
description. Some ISPs in certain countries have strange QoS strategy
that deprioritize UDP packets during network congestion, resulting a
50% loss rate or more for UDP. The udp2raw protocol simulates a
three-way TCP handshake and add TCP header to UDP packets so they will
not be dropped. This protocol does not do congestion control or rate
control, neither does it understand any TCP semantics. It's a dirty
hack for dirty ISP, not suitable for everyone, but overwhelmingly
useful in certain countries.

2) Wireguard currently does not support binding to localhost. This is
required for any third-party plugins upon Wireguard to work. We might
need to consider binding to localhost an important feature to go in
the near future.


Best regards,
StarBrilliant
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] To support "Wireguard over raw TCP"

[Breus Blaauwendraad]

[-- Attachment #1.1: Type: text/plain, Size: 6429 bytes --]

Hello StarBrilliant,

I think that what Kexianbin is trying to make clear is that it would be
nice if  native TCP support would be added in WireGuard.
He (probably) currently uses udp2raw as an alternative, because an UDP-only
VPN is sadly enough not working in every situation.
With him, there have been others pitching ideas on how to wrap the
WireGuard UDP traffic in TCP, which in my opinion, is a poor idea.

So, why would UDP for a VPN service not be enough?

First of all, most VPN traffic obfuscation techniques require a TCP
connection instead of UDP.
VPN usage is particularly useful in countries were Internet censorship is
applied.
Since obfuscating VPN traffic comes with performance overhead, wrapping the
UDP in TCP and obfuscating this would kill the performance advantage
WireGuard has over other protocols.

However, what is arguably more important: various corporate firewalls
(hotels/restaurants/offices) are known to block UDP (for random ports
besides the standard DNS 53 port etc.).
In these instances, it would be useful to have the possibility to build a
fall back to TCP instead of UDP in a VPN service (or even the protocol
itself).

Also, various researchers I have spoken to told me that sometimes they need
a more reliable (TCP) connection, which is then more important than the
speed UDP provides.

I'm looking into the possibilities to deploy the WireGuard VPN protocol for
an existing VPN service currently using OpenVPN, but I keep stumbling on
the problem that WIreGuard does not support TCP.
I (think I) have read all posts regarding TCP for WireGuard, but it seems
that there do not exists a good way to tackle this problem.

Could someone tell whether or not TCP would be a future additional option
for WireGuard, and why (not)?

Also, do you think there actually does exist a neat and fitting solution
for the problems I described?

Kind regards,

Breus Blaauwendraad


On Tue, 25 Sep 2018 at 17:54, StarBrilliant <coder@poorlab.com> wrote:

> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
> <kexianbin@diyism.com> wrote:
> >
> > Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic
> into raw tcp (config files as follows),
> > It's very stable on my home network than using wireguard alone,
> > But if we can integrate RAW TCP feature into wireguard, it would
> significantly improve performance and stability for end users.
> >
> >
> > from:
> https://gist.github.com/diyism/1b80903a83776675031c73ae499438d8#file-wireguard_config-txt-L145
> >
> > $wget
> https://github.com/wangyu-/udp2raw-tunnel/releases/download/20180830.2/udp2raw_binaries.tar.gz
> > $tar xzvf udp2raw_binaries.tar.gz
> > $sudo cp udp2raw_amd64 /usr/bin/
> > $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
> > $cat /etc/wireguard/wg0.conf
> > [Interface]
> > PrivateKey = <client privkey>
> > Address = 10.0.0.3/32
> > ListenPort = 24447
> > MTU = 1300
> > PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server
> pubkey> allowed-ips 0.0.0.0/0
> > PostDown = ip route del 10.0.0.0/24
> >
> > [Peer]
> > #10.0.0.1
> > PublicKey = <server pubkey>
> > Endpoint = 127.0.0.2:24448
> > #AllowedIPs = 0.0.0.0/0
> >
> > $sudo wg-quick down wg0 ; sudo wg-quick up wg0
> > $ping 10.0.0.1
> > 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
> > $sudo ip route add 104.24.0.0/16 dev wg0
> > $ping myip.ipip.net
> > PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
> > 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185 ms
> > $curl http://myip.ipip.net
> > IP：<server ip>
> >
> > #take care, "MTU = 1300" in wg0.conf is needed when wireguard over
> udp2raw, or else most https requests will be blocked because of mtu problem.
>
>
> Hello Kexianbin,
>
> This is an UNOFFICIAL response to your question. (But I think the
> official developers may have similar answers.)
>
> Wireguard probably will not accept an official integration to udp2raw.
> The reasons are:
>
> 1) Wireguard wants to keep their kernel part code minimized, therefore
> easy for security auditing, and less bugs.The UDP protocol is actually
> very simple and straightforward. (By the way, if you intended to use
> Wireguard in China, be informed that this is a protocol that is very
> easy to block by the ISP.)
>
> 2) I have read the source code of udp2raw. To be frank, the code is of
> very low quality. For this reason, I don't think udp2raw would be
> integrated into Wireguard unless it's rewritten.
>
> 3) Udp2raw is not suitable for everyone or for every country. For
> example udp2raw may have problems passing middleboxes, which is common
> among satellite ISPs in Oceania. Middleboxes break and resemble TCP
> segments thus make udp2raw literally unusable. Also it is not
> congestion friendly (by design), so a massive deployment may affect
> the global Internet ecology.
>
> However the good news is, Wireguard provides an open control interface
> (see https://www.wireguard.com/xplatform/ ). By utilizing this
> interface, we can develop an alternate frontend application other than
> the official command "wg", that automatically sets up the kernel
> Wireguard kernel part and a userland udp2raw part, packaged as one
> application.
>
>
> My words for Wireguard developers:
>
> 1) In case you may not know the udp2raw protocol, here is a
> description. Some ISPs in certain countries have strange QoS strategy
> that deprioritize UDP packets during network congestion, resulting a
> 50% loss rate or more for UDP. The udp2raw protocol simulates a
> three-way TCP handshake and add TCP header to UDP packets so they will
> not be dropped. This protocol does not do congestion control or rate
> control, neither does it understand any TCP semantics. It's a dirty
> hack for dirty ISP, not suitable for everyone, but overwhelmingly
> useful in certain countries.
>
> 2) Wireguard currently does not support binding to localhost. This is
> required for any third-party plugins upon Wireguard to work. We might
> need to consider binding to localhost an important feature to go in
> the near future.
>
>
> Best regards,
> StarBrilliant
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 8750 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] To support "Wireguard over raw TCP"

[Matthias Urlichs]

[-- Attachment #1.1.1: Type: text/plain, Size: 803 bytes --]

On 25.09.2018 18:29, Breus Blaauwendraad wrote:
> Could someone tell whether or not TCP would be a future additional
> option for WireGuard, and why (not)?

Which of the umpteen available/possible ways of encapsulating UDP
packets in TCP (and possibly obfuscating them in some way) would you
want Wireguard to natively implement?

The answer is simple: None of them. Bind to localhost, and use a
separate program for forwarding UDP packets.

Also: Any performance gain from supporting TCP natively (as opposed to
going through userspace) is easily dwarfed by the fact that congestion
control requires occasionally dropping packets – specifically, the
packets queued to the TCP socket. TCP cannot do that. Even more
complexity in the kernel? not likely.

-- 
-- Matthias Urlichs



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] To support "Wireguard over raw TCP"

[KeXianbin(http://diyism.com)]

[-- Attachment #1.1: Type: text/plain, Size: 7259 bytes --]

The most important for me is to keep the P2P feature(auto NAT traverse) of
wireguard while wrapping the wireguard UDP packets into udp2raw Fake
TCP/Raw TCP packets. I think that keeping p2p feature of wireguard in
wireguard+udp2raw is more complex or even impossible than Wireguard itself
supports Fake TCP/Raw TCP packets:
https://github.com/wangyu-/udp2raw-tunnel/issues/212

On Oct 2, 2018 11:11, "Breus Blaauwendraad" <b.blaauwendraad@gmail.com>
wrote:

> Hello StarBrilliant,
>
> I think that what Kexianbin is trying to make clear is that it would be
> nice if  native TCP support would be added in WireGuard.
> He (probably) currently uses udp2raw as an alternative, because an
> UDP-only VPN is sadly enough not working in every situation.
> With him, there have been others pitching ideas on how to wrap the
> WireGuard UDP traffic in TCP, which in my opinion, is a poor idea.
>
> So, why would UDP for a VPN service not be enough?
>
> First of all, most VPN traffic obfuscation techniques require a TCP
> connection instead of UDP.
> VPN usage is particularly useful in countries were Internet censorship is
> applied.
> Since obfuscating VPN traffic comes with performance overhead, wrapping
> the UDP in TCP and obfuscating this would kill the performance advantage
> WireGuard has over other protocols.
>
> However, what is arguably more important: various corporate firewalls
> (hotels/restaurants/offices) are known to block UDP (for random ports
> besides the standard DNS 53 port etc.).
> In these instances, it would be useful to have the possibility to build a
> fall back to TCP instead of UDP in a VPN service (or even the protocol
> itself).
>
> Also, various researchers I have spoken to told me that sometimes they
> need a more reliable (TCP) connection, which is then more important than
> the speed UDP provides.
>
> I'm looking into the possibilities to deploy the WireGuard VPN protocol
> for an existing VPN service currently using OpenVPN, but I keep stumbling
> on the problem that WIreGuard does not support TCP.
> I (think I) have read all posts regarding TCP for WireGuard, but it seems
> that there do not exists a good way to tackle this problem.
>
> Could someone tell whether or not TCP would be a future additional option
> for WireGuard, and why (not)?
>
> Also, do you think there actually does exist a neat and fitting solution
> for the problems I described?
>
> Kind regards,
>
> Breus Blaauwendraad
>
>
> On Tue, 25 Sep 2018 at 17:54, StarBrilliant <coder@poorlab.com> wrote:
>
>> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
>> <kexianbin@diyism.com> wrote:
>> >
>> > Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic
>> into raw tcp (config files as follows),
>> > It's very stable on my home network than using wireguard alone,
>> > But if we can integrate RAW TCP feature into wireguard, it would
>> significantly improve performance and stability for end users.
>> >
>> >
>> > from: https://gist.github.com/diyism/1b80903a83776675031c73ae499438
>> d8#file-wireguard_config-txt-L145
>> >
>> > $wget https://github.com/wangyu-/udp2raw-tunnel/releases/
>> download/20180830.2/udp2raw_binaries.tar.gz
>> > $tar xzvf udp2raw_binaries.tar.gz
>> > $sudo cp udp2raw_amd64 /usr/bin/
>> > $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
>> > $cat /etc/wireguard/wg0.conf
>> > [Interface]
>> > PrivateKey = <client privkey>
>> > Address = 10.0.0.3/32
>> > ListenPort = 24447
>> > MTU = 1300
>> > PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server
>> pubkey> allowed-ips 0.0.0.0/0
>> > PostDown = ip route del 10.0.0.0/24
>> >
>> > [Peer]
>> > #10.0.0.1
>> > PublicKey = <server pubkey>
>> > Endpoint = 127.0.0.2:24448
>> > #AllowedIPs = 0.0.0.0/0
>> >
>> > $sudo wg-quick down wg0 ; sudo wg-quick up wg0
>> > $ping 10.0.0.1
>> > 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
>> > $sudo ip route add 104.24.0.0/16 dev wg0
>> > $ping myip.ipip.net
>> > PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
>> > 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185 ms
>> > $curl http://myip.ipip.net
>> > IP：<server ip>
>> >
>> > #take care, "MTU = 1300" in wg0.conf is needed when wireguard over
>> udp2raw, or else most https requests will be blocked because of mtu problem.
>>
>>
>> Hello Kexianbin,
>>
>> This is an UNOFFICIAL response to your question. (But I think the
>> official developers may have similar answers.)
>>
>> Wireguard probably will not accept an official integration to udp2raw.
>> The reasons are:
>>
>> 1) Wireguard wants to keep their kernel part code minimized, therefore
>> easy for security auditing, and less bugs.The UDP protocol is actually
>> very simple and straightforward. (By the way, if you intended to use
>> Wireguard in China, be informed that this is a protocol that is very
>> easy to block by the ISP.)
>>
>> 2) I have read the source code of udp2raw. To be frank, the code is of
>> very low quality. For this reason, I don't think udp2raw would be
>> integrated into Wireguard unless it's rewritten.
>>
>> 3) Udp2raw is not suitable for everyone or for every country. For
>> example udp2raw may have problems passing middleboxes, which is common
>> among satellite ISPs in Oceania. Middleboxes break and resemble TCP
>> segments thus make udp2raw literally unusable. Also it is not
>> congestion friendly (by design), so a massive deployment may affect
>> the global Internet ecology.
>>
>> However the good news is, Wireguard provides an open control interface
>> (see https://www.wireguard.com/xplatform/ ). By utilizing this
>> interface, we can develop an alternate frontend application other than
>> the official command "wg", that automatically sets up the kernel
>> Wireguard kernel part and a userland udp2raw part, packaged as one
>> application.
>>
>>
>> My words for Wireguard developers:
>>
>> 1) In case you may not know the udp2raw protocol, here is a
>> description. Some ISPs in certain countries have strange QoS strategy
>> that deprioritize UDP packets during network congestion, resulting a
>> 50% loss rate or more for UDP. The udp2raw protocol simulates a
>> three-way TCP handshake and add TCP header to UDP packets so they will
>> not be dropped. This protocol does not do congestion control or rate
>> control, neither does it understand any TCP semantics. It's a dirty
>> hack for dirty ISP, not suitable for everyone, but overwhelmingly
>> useful in certain countries.
>>
>> 2) Wireguard currently does not support binding to localhost. This is
>> required for any third-party plugins upon Wireguard to work. We might
>> need to consider binding to localhost an important feature to go in
>> the near future.
>>
>>
>> Best regards,
>> StarBrilliant
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>

[-- Attachment #1.2: Type: text/html, Size: 10443 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] To support "Wireguard over raw TCP"

[KeXianbin(http://diyism.com)]

[-- Attachment #1.1: Type: text/plain, Size: 8001 bytes --]

Sorry, I've got some help from udp2raw author, he/she tell me
udp2raw/faketcp needs a tcp handshake to build a tcp connection. So
Integrating FakeTCP into wireguard has no possibility to keep the
P2P/nat-traverse feature.
Finally I abandon/recall my Feature Request to integrating faketcp into
Wireguard. Maybe I can only integrate udp2raw into a personal Wireguard
android client to only connect the wireguard on my VPS(with a public
ip:port).

Malcolm Ke

On Oct 2, 2018 14:53, "KeXianbin(http://diyism.com)" <kexianbin@diyism.com>
wrote:

> The most important for me is to keep the P2P feature(auto NAT traverse) of
> wireguard while wrapping the wireguard UDP packets into udp2raw Fake
> TCP/Raw TCP packets. I think that keeping p2p feature of wireguard in
> wireguard+udp2raw is more complex or even impossible than Wireguard itself
> supports Fake TCP/Raw TCP packets: https://github.com/
> wangyu-/udp2raw-tunnel/issues/212
>
> On Oct 2, 2018 11:11, "Breus Blaauwendraad" <b.blaauwendraad@gmail.com>
> wrote:
>
>> Hello StarBrilliant,
>>
>> I think that what Kexianbin is trying to make clear is that it would be
>> nice if  native TCP support would be added in WireGuard.
>> He (probably) currently uses udp2raw as an alternative, because an
>> UDP-only VPN is sadly enough not working in every situation.
>> With him, there have been others pitching ideas on how to wrap the
>> WireGuard UDP traffic in TCP, which in my opinion, is a poor idea.
>>
>> So, why would UDP for a VPN service not be enough?
>>
>> First of all, most VPN traffic obfuscation techniques require a TCP
>> connection instead of UDP.
>> VPN usage is particularly useful in countries were Internet censorship is
>> applied.
>> Since obfuscating VPN traffic comes with performance overhead, wrapping
>> the UDP in TCP and obfuscating this would kill the performance advantage
>> WireGuard has over other protocols.
>>
>> However, what is arguably more important: various corporate firewalls
>> (hotels/restaurants/offices) are known to block UDP (for random ports
>> besides the standard DNS 53 port etc.).
>> In these instances, it would be useful to have the possibility to build a
>> fall back to TCP instead of UDP in a VPN service (or even the protocol
>> itself).
>>
>> Also, various researchers I have spoken to told me that sometimes they
>> need a more reliable (TCP) connection, which is then more important than
>> the speed UDP provides.
>>
>> I'm looking into the possibilities to deploy the WireGuard VPN protocol
>> for an existing VPN service currently using OpenVPN, but I keep stumbling
>> on the problem that WIreGuard does not support TCP.
>> I (think I) have read all posts regarding TCP for WireGuard, but it seems
>> that there do not exists a good way to tackle this problem.
>>
>> Could someone tell whether or not TCP would be a future additional option
>> for WireGuard, and why (not)?
>>
>> Also, do you think there actually does exist a neat and fitting solution
>> for the problems I described?
>>
>> Kind regards,
>>
>> Breus Blaauwendraad
>>
>>
>> On Tue, 25 Sep 2018 at 17:54, StarBrilliant <coder@poorlab.com> wrote:
>>
>>> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
>>> <kexianbin@diyism.com> wrote:
>>> >
>>> > Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic
>>> into raw tcp (config files as follows),
>>> > It's very stable on my home network than using wireguard alone,
>>> > But if we can integrate RAW TCP feature into wireguard, it would
>>> significantly improve performance and stability for end users.
>>> >
>>> >
>>> > from: https://gist.github.com/diyism/1b80903a83776675031c73ae49943
>>> 8d8#file-wireguard_config-txt-L145
>>> >
>>> > $wget https://github.com/wangyu-/udp2raw-tunnel/releases/download/
>>> 20180830.2/udp2raw_binaries.tar.gz
>>> > $tar xzvf udp2raw_binaries.tar.gz
>>> > $sudo cp udp2raw_amd64 /usr/bin/
>>> > $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
>>> > $cat /etc/wireguard/wg0.conf
>>> > [Interface]
>>> > PrivateKey = <client privkey>
>>> > Address = 10.0.0.3/32
>>> > ListenPort = 24447
>>> > MTU = 1300
>>> > PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server
>>> pubkey> allowed-ips 0.0.0.0/0
>>> > PostDown = ip route del 10.0.0.0/24
>>> >
>>> > [Peer]
>>> > #10.0.0.1
>>> > PublicKey = <server pubkey>
>>> > Endpoint = 127.0.0.2:24448
>>> > #AllowedIPs = 0.0.0.0/0
>>> >
>>> > $sudo wg-quick down wg0 ; sudo wg-quick up wg0
>>> > $ping 10.0.0.1
>>> > 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
>>> > $sudo ip route add 104.24.0.0/16 dev wg0
>>> > $ping myip.ipip.net
>>> > PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
>>> > 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185
>>> ms
>>> > $curl http://myip.ipip.net
>>> > IP：<server ip>
>>> >
>>> > #take care, "MTU = 1300" in wg0.conf is needed when wireguard over
>>> udp2raw, or else most https requests will be blocked because of mtu problem.
>>>
>>>
>>> Hello Kexianbin,
>>>
>>> This is an UNOFFICIAL response to your question. (But I think the
>>> official developers may have similar answers.)
>>>
>>> Wireguard probably will not accept an official integration to udp2raw.
>>> The reasons are:
>>>
>>> 1) Wireguard wants to keep their kernel part code minimized, therefore
>>> easy for security auditing, and less bugs.The UDP protocol is actually
>>> very simple and straightforward. (By the way, if you intended to use
>>> Wireguard in China, be informed that this is a protocol that is very
>>> easy to block by the ISP.)
>>>
>>> 2) I have read the source code of udp2raw. To be frank, the code is of
>>> very low quality. For this reason, I don't think udp2raw would be
>>> integrated into Wireguard unless it's rewritten.
>>>
>>> 3) Udp2raw is not suitable for everyone or for every country. For
>>> example udp2raw may have problems passing middleboxes, which is common
>>> among satellite ISPs in Oceania. Middleboxes break and resemble TCP
>>> segments thus make udp2raw literally unusable. Also it is not
>>> congestion friendly (by design), so a massive deployment may affect
>>> the global Internet ecology.
>>>
>>> However the good news is, Wireguard provides an open control interface
>>> (see https://www.wireguard.com/xplatform/ ). By utilizing this
>>> interface, we can develop an alternate frontend application other than
>>> the official command "wg", that automatically sets up the kernel
>>> Wireguard kernel part and a userland udp2raw part, packaged as one
>>> application.
>>>
>>>
>>> My words for Wireguard developers:
>>>
>>> 1) In case you may not know the udp2raw protocol, here is a
>>> description. Some ISPs in certain countries have strange QoS strategy
>>> that deprioritize UDP packets during network congestion, resulting a
>>> 50% loss rate or more for UDP. The udp2raw protocol simulates a
>>> three-way TCP handshake and add TCP header to UDP packets so they will
>>> not be dropped. This protocol does not do congestion control or rate
>>> control, neither does it understand any TCP semantics. It's a dirty
>>> hack for dirty ISP, not suitable for everyone, but overwhelmingly
>>> useful in certain countries.
>>>
>>> 2) Wireguard currently does not support binding to localhost. This is
>>> required for any third-party plugins upon Wireguard to work. We might
>>> need to consider binding to localhost an important feature to go in
>>> the near future.
>>>
>>>
>>> Best regards,
>>> StarBrilliant
>>> _______________________________________________
>>> WireGuard mailing list
>>> WireGuard@lists.zx2c4.com
>>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>>
>>
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 11407 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] To support "Wireguard over raw TCP"

[Michael Rash]

[-- Attachment #1.1: Type: text/plain, Size: 5274 bytes --]

On Tue, Sep 25, 2018 at 12:06 PM KeXianbin(http://diyism.com) <
kexianbin@diyism.com> wrote:

> Thanks for the info.
>
> On Sep 25, 2018 23:53, "StarBrilliant" <coder@poorlab.com> wrote:
>
>> On Tue, Sep 25, 2018 at 1:17 PM KeXianbin(http://diyism.com)
>> <kexianbin@diyism.com> wrote:
>> >
>> > Currently, I'm using udp2raw-tunnel to transform wireguard udp traffic
>> into raw tcp (config files as follows),
>> > It's very stable on my home network than using wireguard alone,
>> > But if we can integrate RAW TCP feature into wireguard, it would
>> significantly improve performance and stability for end users.
>> >
>> >
>> > from:
>> https://gist.github.com/diyism/1b80903a83776675031c73ae499438d8#file-wireguard_config-txt-L145
>> >
>> > $wget
>> https://github.com/wangyu-/udp2raw-tunnel/releases/download/20180830.2/udp2raw_binaries.tar.gz
>> > $tar xzvf udp2raw_binaries.tar.gz
>> > $sudo cp udp2raw_amd64 /usr/bin/
>> > $sudo udp2raw_amd64 -c -l127.0.0.2:24448 -r<server ip>:24447 -a
>> > $cat /etc/wireguard/wg0.conf
>> > [Interface]
>> > PrivateKey = <client privkey>
>> > Address = 10.0.0.3/32
>> > ListenPort = 24447
>> > MTU = 1300
>> > PostUp = ip route add 10.0.0.0/24 dev wg0 && wg set wg0 peer <server
>> pubkey> allowed-ips 0.0.0.0/0
>> > PostDown = ip route del 10.0.0.0/24
>> >
>> > [Peer]
>> > #10.0.0.1
>> > PublicKey = <server pubkey>
>> > Endpoint = 127.0.0.2:24448
>> > #AllowedIPs = 0.0.0.0/0
>> >
>> > $sudo wg-quick down wg0 ; sudo wg-quick up wg0
>> > $ping 10.0.0.1
>> > 64 bytes from 10.0.0.1: icmp_seq=2113 ttl=64 time=183 ms
>> > $sudo ip route add 104.24.0.0/16 dev wg0
>> > $ping myip.ipip.net
>> > PING myip.ipip.net (104.24.20.50) 56(84) bytes of data.
>> > 64 bytes from 104.24.20.50 (104.24.20.50): icmp_seq=1 ttl=60 time=185 ms
>> > $curl http://myip.ipip.net
>> > IP：<server ip>
>> >
>> > #take care, "MTU = 1300" in wg0.conf is needed when wireguard over
>> udp2raw, or else most https requests will be blocked because of mtu problem.
>>
>>
>> Hello Kexianbin,
>>
>> This is an UNOFFICIAL response to your question. (But I think the
>> official developers may have similar answers.)
>>
>> Wireguard probably will not accept an official integration to udp2raw.
>> The reasons are:
>>
>> 1) Wireguard wants to keep their kernel part code minimized, therefore
>> easy for security auditing, and less bugs.The UDP protocol is actually
>> very simple and straightforward. (By the way, if you intended to use
>> Wireguard in China, be informed that this is a protocol that is very
>> easy to block by the ISP.)
>>
>> 2) I have read the source code of udp2raw. To be frank, the code is of
>> very low quality. For this reason, I don't think udp2raw would be
>> integrated into Wireguard unless it's rewritten.
>>
>> 3) Udp2raw is not suitable for everyone or for every country. For
>> example udp2raw may have problems passing middleboxes, which is common
>> among satellite ISPs in Oceania. Middleboxes break and resemble TCP
>> segments thus make udp2raw literally unusable. Also it is not
>> congestion friendly (by design), so a massive deployment may affect
>> the global Internet ecology.
>>
>
Let me also add (unofficially of course) that stealth against active
scanning is also an important goal achieved by Wireguard's usage of UDP,
and switching to TCP would break this. If TCP is required, then integration
options with third party tools such as udp2raw-tunnel will always be there.
Wireguard should not have to directly support those options, and rather
should stick to its current compelling design.

--Mike




>
>> However the good news is, Wireguard provides an open control interface
>> (see https://www.wireguard.com/xplatform/ ). By utilizing this
>> interface, we can develop an alternate frontend application other than
>> the official command "wg", that automatically sets up the kernel
>> Wireguard kernel part and a userland udp2raw part, packaged as one
>> application.
>>
>>
>> My words for Wireguard developers:
>>
>> 1) In case you may not know the udp2raw protocol, here is a
>> description. Some ISPs in certain countries have strange QoS strategy
>> that deprioritize UDP packets during network congestion, resulting a
>> 50% loss rate or more for UDP. The udp2raw protocol simulates a
>> three-way TCP handshake and add TCP header to UDP packets so they will
>> not be dropped. This protocol does not do congestion control or rate
>> control, neither does it understand any TCP semantics. It's a dirty
>> hack for dirty ISP, not suitable for everyone, but overwhelmingly
>> useful in certain countries.
>>
>> 2) Wireguard currently does not support binding to localhost. This is
>> required for any third-party plugins upon Wireguard to work. We might
>> need to consider binding to localhost an important feature to go in
>> the near future.
>>
>>
>> Best regards,
>> StarBrilliant
>>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>


-- 
Michael Rash | Founder
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

[-- Attachment #1.2: Type: text/html, Size: 8062 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [feature request] To support "Wireguard over raw TCP"

[Saeid Akbari]

Hi,

> 2) Wireguard currently does not support binding to localhost. This is
> required for any third-party plugins upon Wireguard to work. We might
> need to consider binding to localhost an important feature to go in
> the near future.

FYI,
I just recently used WireGuard with udp2raw-tunnel successfully. Both 
localhost endpoint on the client side, and localhost endpoint on the server-
side worked like a charm. Although I understand you can't "bind" the udp 
socket to 127.0.0.1 to restrict its outside usage, but it works on 0.0.0.0 
regardless.


_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard