* Re: compile error on WireGuard Kernel/ROM Integration
From: Robert Walli @ 2019-04-13 7:14 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
In-Reply-To: <CAHmME9ojqhKDRGkEqmaP-bCXPjgpjwRKKvQL1Z9Gu+bx018jyQ@mail.gmail.com>
> On 13.04.2019, at 02:17, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Link to kernel sources?
Tried diffrent kernels eg.: https://github.com/mobspyguy/android_kernel_samsung_apq8084
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: compile error on WireGuard Kernel/ROM Integration
From: Jason A. Donenfeld @ 2019-04-13 0:17 UTC (permalink / raw)
To: Robert Walli; +Cc: WireGuard mailing list
In-Reply-To: <068214E5-B780-4A6C-AE79-BD772177EBCB@gmx.net>
Link to kernel sources?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* compile error on WireGuard Kernel/ROM Integration
From: Robert Walli @ 2019-04-12 16:59 UTC (permalink / raw)
To: wireguard
Hello!
I got an error compiling wireguard for android 9 kernel 3.10.108 for trlte:
---
net/wireguard/compat/udp_tunnel/udp_tunnel.c:87:26: warning: assignment from incompatible pointer type
error, forbidden warning: udp_tunnel.c:87
---
tried with rom- and kernel integration as described on: https://forum.xda-developers.com/android/development/wireguard-rom-integration-t3711635
with LineageOS and Resurrection Remix OS.
any suggestions how to solve this problem?
Robert
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* ipset-dns combined with wg-quick
From: Feng Li @ 2019-04-12 10:17 UTC (permalink / raw)
To: Jason, wireguard
Hello Jason,
I have tried `wg-quick`, it works well but it will pass through all
traffic to the peer.
And I found you have created a small project called "ipset-dns"[1],
which is good for routing traffics by domains.
However, if I combined it with `wg-quick`, it will not work.
The network will connect timeout. And I found the ipset-dns did works well.
So I guess the question is the route table related.
But I'm not familiar with it.
The ultimate aim is like this:
If I want to route google.com/twitter.com/facebook.com to the peer,
just add the domains in the dnsmasq.conf.
The related command looks like this, the marks and route table maybe
have some conflicts.
```
+ sets youtube 1
+ iptables -t mangle -D PREROUTING -m set --set youtube dst,src -j
MARK --set-mark 1
+ ipset -X youtube
+ ipset -N youtube iphash
+ iptables -t mangle -A PREROUTING -m set --set youtube dst,src -j
MARK --set-mark 1
--set option deprecated, please use --match-set
+ routes 1 wg0
+ echo 0
+ ip route flush table 1
+ ip rule del table 1
+ ip rule add fwmark 1 table 1 priority 1000
+ ip route add default via 10.0.0.2 table 1
+ killall ipset-dns
+ ipset-dns youtube '' 1919 8.8.8.8
+ killall -SIGHUP dnsmasq
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.0.4/24 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] mount `8.8.8.8' /etc/resolv.conf
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] iptables -A FORWARD -i eth0 -j ACCEPT; iptables -A FORWARD -o eth0
-j ACCEPT;iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
```
Could you give me some helps?
Thanks.
[1]: https://git.zx2c4.com/ipset-dns/tree/README.md
--
Thanks and Best Regards,
Feng Li(Alex)
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Revisiting the weird MTU issue
From: Derrick Lyndon Pallas @ 2019-04-10 18:20 UTC (permalink / raw)
To: Roman Mamedov; +Cc: WireGuard mailing list
In-Reply-To: <20190410203431.24b55c89@natsu>
MTU discovery isn't supported widely in my experience. My rule has been to set the interface to 1280, which is the minimum allowed.
~Derrick • iPhone
> On Apr 10, 2019, at 8:34 AM, Roman Mamedov <rm@romanrm.net> wrote:
>
> Hello,
>
> I use WireGuard over IPv6 on a PPPoE connection. The Internet interface MTU is
> 1492. By my calculations MTU 1412 on the WG interface should fit.
>
> However, the following occurs on various MTU combinations between the Remote
> (a server in a DC with full 1500 wire MTU) and Local WG interface MTUs:
>
> Fails or not, is whether a within-WG Remote->Local TCP connection (iperf3)
> works fine or hangs up after transferring a few initial bits of data.
>
> Remote Local Result
> ====================
> 1420 1420 Fails (as expected)
>
> 1420 1412 Fails (weird)
>
> 1412 1412 Works (fair enough)
>
> 1420 1408 Works (super weird!!!)
>
> Now I hope I described the situation clearer than the last time posting about
> this, so maybe someone has an idea what could be the culprit?
>
> So far this doesn't cause too much issue, as I'm using on designated p2p links
> for when one of the peers is on this PPPoE, I just use 1412 on both sides. But
> still, surely the above shouldn't happen?
>
> --
> With respect,
> Roman
> _______________________________________________
> 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
^ permalink raw reply
* Revisiting the weird MTU issue
From: Roman Mamedov @ 2019-04-10 15:34 UTC (permalink / raw)
To: WireGuard mailing list
Hello,
I use WireGuard over IPv6 on a PPPoE connection. The Internet interface MTU is
1492. By my calculations MTU 1412 on the WG interface should fit.
However, the following occurs on various MTU combinations between the Remote
(a server in a DC with full 1500 wire MTU) and Local WG interface MTUs:
Fails or not, is whether a within-WG Remote->Local TCP connection (iperf3)
works fine or hangs up after transferring a few initial bits of data.
Remote Local Result
====================
1420 1420 Fails (as expected)
1420 1412 Fails (weird)
1412 1412 Works (fair enough)
1420 1408 Works (super weird!!!)
Now I hope I described the situation clearer than the last time posting about
this, so maybe someone has an idea what could be the culprit?
So far this doesn't cause too much issue, as I'm using on designated p2p links
for when one of the peers is on this PPPoE, I just use 1412 on both sides. But
still, surely the above shouldn't happen?
--
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Multiple VPN connections on Android
From: Jason A. Donenfeld @ 2019-04-08 1:39 UTC (permalink / raw)
To: Julian Orth; +Cc: WireGuard mailing list
In-Reply-To: <d46cbe36-887a-d7ab-4daa-3aea02b78e8c@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4169 bytes --]
That's an interesting point; in theory it's probably possible to multiplex
into one tun device, provided the routes for each distinct wg interface
don't overlap.
On Sun, Apr 7, 2019, 19:37 Julian Orth <ju.orth@gmail.com> wrote:
> On 3/26/19 8:49 PM, mikma.wg@lists.m7n.se wrote:>
> > On 2019-03-26 15:17, Julian Orth wrote:
> >> Hello list,
> >>
> >> I'm currently using WireGuard on Android for two purposes:
> >>
> >> 1. Routing all traffic via a commercial VPN provider to protect myself
> on
> >> open wireless networks.
> >> 2. Connecting to my home network.
> >>
> >> Unfortunately WireGuard on Android does not allow me to do both of these
> >> things at the same time. I assume this is because VpnService [1] only
> allows 1
> >> VPN connection at a time.
> >
> > Can't you add the peer for your home network to the same configuration
> (tun
> > device) as the peer for the commercial VPN provider? It seems a straight
> > forward solution to me if you are okay with the IP addresses assigned by
> the
> > VPN provider.
>
> Using the same src IP is not going to work in my case. The VPN provider
> might
> also assign me a new IP and then I might have to reconfigure my home
> network.
> Not something I want to deal with.
>
> But this would also require me to share the same public key between my home
> network and the VPN provider. For some reason this does not feel right to
> me. On
> the other hand, I use the same SSH key on multiple sites so maybe this
> feeling
> is not justified.
>
> My current provider allows me to generate the key pair locally and to only
> send
> them the public key. If they insistet on generating the keys on their
> servers
> and sending me the private key, then this solution would be impossible.
>
> >
> >>
> >> Has any thought been put into emulating multiple tun devices in user
> space?
> >
> > I don't see why you would need multiple tun devices.
>
> By "emulating multiple tun devices" I did not mean emulating all of the
> functionality of tun devices. Packets are processed as follows right now:
>
> 1. Kernel chooses the correct route and device
> 2. Kernel sends the packet via the device
> 3. If the device is a wireguard tun device:
> a. Choose the peer and wrap the packet in a wireguard packet
> b. Goto 1 with the original packet replaced by the wrapped packet
>
> What I suggest is emulating steps 1 and 2. An emulated tun devices would
> therefore only have to consist of a set of assigned routes and an instance
> of
> the wireguard core that implements step 3.
>
> Let's say the Android app currently processes packets as follows:
>
> void process(packet) {
> peer, packet := wireguard.process(packet);
> peer.udp_send(packet);
> }
>
> My suggestion is to change this as follows:
>
> void process(packet) {
> seen_peers := { }; // a set
> while (true) {
> tap_dev := find_tap_dev(packet.dst);
> peer, packet := tap_dev.process(packet);
> if (seen_peers.contains(peer)) {
> // routing loop
> return;
> }
> seen_peers.add(peer);
> if (find_tap_dev(packet.dst) == null) {
> peer.udp_send(packet);
> return;
> }
> }
> }
>
> The Android tun device created via VpnService would then of course contain
> the
> union of all routes of the emulated tun devices.
>
> > It is possible to
> add
> > multiple IPv4 and IPv6 addresses to the tun device, but there may be a
> problem
> > with the source address selection. Linux allows specifying a preferred
> address
> > for each route, but it isn't possible in the Android API AFAIK. If you
> have a
> > rooted device then you can potentially update the routing tables with the
> > preferred source address for each VPN route.
>
> I don't think routing should be necessary for this. Afaik, other VPN apps
> already support using multiple tunnels at once.
>
> >
> > /Mikma
>
> PS: Your mail was classified as spam by gmail.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
[-- Attachment #1.2: Type: text/html, Size: 5256 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Multiple VPN connections on Android
From: Matthias Urlichs @ 2019-04-07 10:55 UTC (permalink / raw)
To: wireguard
In-Reply-To: <d46cbe36-887a-d7ab-4daa-3aea02b78e8c@gmail.com>
On 07.04.19 12:37, Julian Orth wrote:
> If they insistet on generating the keys on their servers
> and sending me the private key
A VPN provider who does this obviously has no clue whatsoever, and thus
should not be used in the first place.
--
-- Matthias Urlichs
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Multiple VPN connections on Android
From: Julian Orth @ 2019-04-07 10:37 UTC (permalink / raw)
To: mikma.wg; +Cc: WireGuard mailing list
In-Reply-To: <911c5ed5-0bf8-80bb-cf15-7b2c6ee896fa@m7n.se>
On 3/26/19 8:49 PM, mikma.wg@lists.m7n.se wrote:>
> On 2019-03-26 15:17, Julian Orth wrote:
>> Hello list,
>>
>> I'm currently using WireGuard on Android for two purposes:
>>
>> 1. Routing all traffic via a commercial VPN provider to protect myself on
>> open wireless networks.
>> 2. Connecting to my home network.
>>
>> Unfortunately WireGuard on Android does not allow me to do both of these
>> things at the same time. I assume this is because VpnService [1] only allows 1
>> VPN connection at a time.
>
> Can't you add the peer for your home network to the same configuration (tun
> device) as the peer for the commercial VPN provider? It seems a straight
> forward solution to me if you are okay with the IP addresses assigned by the
> VPN provider.
Using the same src IP is not going to work in my case. The VPN provider might
also assign me a new IP and then I might have to reconfigure my home network.
Not something I want to deal with.
But this would also require me to share the same public key between my home
network and the VPN provider. For some reason this does not feel right to me. On
the other hand, I use the same SSH key on multiple sites so maybe this feeling
is not justified.
My current provider allows me to generate the key pair locally and to only send
them the public key. If they insistet on generating the keys on their servers
and sending me the private key, then this solution would be impossible.
>
>>
>> Has any thought been put into emulating multiple tun devices in user space?
>
> I don't see why you would need multiple tun devices.
By "emulating multiple tun devices" I did not mean emulating all of the
functionality of tun devices. Packets are processed as follows right now:
1. Kernel chooses the correct route and device
2. Kernel sends the packet via the device
3. If the device is a wireguard tun device:
a. Choose the peer and wrap the packet in a wireguard packet
b. Goto 1 with the original packet replaced by the wrapped packet
What I suggest is emulating steps 1 and 2. An emulated tun devices would
therefore only have to consist of a set of assigned routes and an instance of
the wireguard core that implements step 3.
Let's say the Android app currently processes packets as follows:
void process(packet) {
peer, packet := wireguard.process(packet);
peer.udp_send(packet);
}
My suggestion is to change this as follows:
void process(packet) {
seen_peers := { }; // a set
while (true) {
tap_dev := find_tap_dev(packet.dst);
peer, packet := tap_dev.process(packet);
if (seen_peers.contains(peer)) {
// routing loop
return;
}
seen_peers.add(peer);
if (find_tap_dev(packet.dst) == null) {
peer.udp_send(packet);
return;
}
}
}
The Android tun device created via VpnService would then of course contain the
union of all routes of the emulated tun devices.
> It is possible to add
> multiple IPv4 and IPv6 addresses to the tun device, but there may be a problem
> with the source address selection. Linux allows specifying a preferred address
> for each route, but it isn't possible in the Android API AFAIK. If you have a
> rooted device then you can potentially update the routing tables with the
> preferred source address for each VPN route.
I don't think routing should be necessary for this. Afaik, other VPN apps
already support using multiple tunnels at once.
>
> /Mikma
PS: Your mail was classified as spam by gmail.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: mesh VPN with wireguard?
From: Roman Mamedov @ 2019-04-06 13:01 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: wireguard
In-Reply-To: <bf1d3b6ac8dc6a31c82042b363db3bf3@wpkg.org>
On Thu, 28 Mar 2019 23:22:45 +0900
Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> Does Wireguard allow to set up mesh VPN with "relative ease"?
>
> Say, we have 10 servers with public IPs, we want them all to create a
> VPN network with private subnet 10.11.12.0/24, and have all 10 servers
> communicate directly with each other.
> Then a year later, expand it to 100 servers.
Sure.
But note that in this case unlike Tinc you cannot have some servers exit to
the outside world via some other servers (with AllowedIP 0.0.0.0/0). There has
to be just one such exit point per a WG network.
If it's purely for communication between servers, then of course no issue.
> Something in the line of: https://www.tinc-vpn.org/
Another limitation compared to Tinc is that Tinc will autoheal the partially
disconnected mesh and will have some nodes forwarding for the others, in case
direct communication between some of them gets cut (e.g. due to a peering or
routing issue on the underlying Internet -- this saved me a few times).
WG will do no such thing, and node-to-node communication working will depend
on both nodes always having direct connectivity to each other.
--
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Wireguard on PiZeroW
From: Jason A. Donenfeld @ 2019-04-06 12:05 UTC (permalink / raw)
To: Robert Ross; +Cc: WireGuard mailing list
In-Reply-To: <CAGGGmFFC7cZ6kQ2e+WwuDkKeSorbP5_zLYNxOszzSK2QoPVL1w@mail.gmail.com>
I backported that 8 days ago here:
https://git.zx2c4.com/WireGuard/commit/?id=65e1f2838401bf033f3c8a8cdd718589574d9d2d
See if the latest snapshot (0.0.20190409) works for you.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Ubuntu 19.04 'Disco Dingo' - No Wireguard PPA
From: Terry Burgess @ 2019-03-29 22:17 UTC (permalink / raw)
To: wireguard
[-- Attachment #1.1: Type: text/plain, Size: 196 bytes --]
Hi folks;
Title says it all. 'Disco' final beta was March 28. I installed it on a
test machine today and found that Wireguard doesn't have a Disco PPA yet.
Will one be on it's way soon?
Cheers!
[-- Attachment #1.2: Type: text/html, Size: 602 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Wireguard on PiZeroW
From: Robert Ross @ 2019-03-27 17:47 UTC (permalink / raw)
To: wireguard
In-Reply-To: <CAGGGmFFSDwPGrfdvBOR_toubEpZG6nrtUk4oMO+FjRWpWSX-aA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1330 bytes --]
Follow up
I reinstalled Raspian Stretch and kernel-headers for 4.14.79+ and got the
same error. I downloaded the previous release from here -->
https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20190123.zip
and the error did not occur.
Robert
On Tue, Mar 26, 2019 at 4:21 PM Robert Ross <rpross3@gmail.com> wrote:
> Details:
> PiZeroW
> Linux XXX 4.14.98+ #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l GNU/Linux
> Latest kernel-headers
> Added rpi-source
>
> I get this error compiling on PiZeroW
>
> ~/WireGuard/src# make
> CC [M] /root/WireGuard/src/main.o
> CC [M] /root/WireGuard/src/noise.o
> CC [M] /root/WireGuard/src/device.o
> /root/WireGuard/src/device.c: In function 'wg_xmit':
> /root/WireGuard/src/device.c:165:3: error: implicit declaration of
> function 'skb_mark_not_on_list' [-Werror=implicit-function-declaration]
> skb_mark_not_on_list(skb);
> ^~~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> scripts/Makefile.build:326: recipe for target
> '/root/WireGuard/src/device.o' failed
> make[2]: *** [/root/WireGuard/src/device.o] Error 1
> Makefile:1535: recipe for target '_module_/root/WireGuard/src' failed
> make[1]: *** [_module_/root/WireGuard/src] Error 2
> Makefile:37: recipe for target 'module' failed
> make: *** [module] Error 2
>
> TIA for any insights. Robert
>
[-- Attachment #1.2: Type: text/html, Size: 2135 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Wireguard on PiZeroW
From: Robert Ross @ 2019-03-26 21:21 UTC (permalink / raw)
To: wireguard
[-- Attachment #1.1: Type: text/plain, Size: 953 bytes --]
Details:
PiZeroW
Linux XXX 4.14.98+ #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l GNU/Linux
Latest kernel-headers
Added rpi-source
I get this error compiling on PiZeroW
~/WireGuard/src# make
CC [M] /root/WireGuard/src/main.o
CC [M] /root/WireGuard/src/noise.o
CC [M] /root/WireGuard/src/device.o
/root/WireGuard/src/device.c: In function 'wg_xmit':
/root/WireGuard/src/device.c:165:3: error: implicit declaration of function
'skb_mark_not_on_list' [-Werror=implicit-function-declaration]
skb_mark_not_on_list(skb);
^~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:326: recipe for target
'/root/WireGuard/src/device.o' failed
make[2]: *** [/root/WireGuard/src/device.o] Error 1
Makefile:1535: recipe for target '_module_/root/WireGuard/src' failed
make[1]: *** [_module_/root/WireGuard/src] Error 2
Makefile:37: recipe for target 'module' failed
make: *** [module] Error 2
TIA for any insights. Robert
[-- Attachment #1.2: Type: text/html, Size: 1354 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: iOS connection issue
From: Roopesh Chander S @ 2019-04-02 8:46 UTC (permalink / raw)
To: wireguard
Just to confirm, you’re saying you can connect from your Mac with this config and access the Internet, but can’t do that from iPhone from the same config. (I’m assuming you didn’t have the VPN on in your Mac when trying to connect from the iPhone.)
Can you provide the log from your iPhone to investigate further? (Settings > Log). You can email it to team at wireguard dot com.
> From the General VPN info, it says the server address is 127.0.0.1, which doesn’t sound right.
I’m assuming you’re seeing this in Settings > VPN > [vpn name] (i) once the VPN is up. That’s indeed not the actual IP of the server — it’s just an arbitrary string we provide iOS. I’ve noted down a task to fix it when there’s a single peer with an endpoint.
Thanks,
roop.
> Glen Huang wrote:
>
> Hi,
>
> I can connect to my wg server on my Mac with this config
>
> [Interface]
> Address = 10.0.0.2
> DNS = 8.8.8.8
> PrivateKey = <value>
>
> [Peer]
> Endpoint = <ip>:<port>
> PublicKey = <value>
> AllowedIPs = 0.0.0.0/0, ::/0
>
> But once upload it as qr code to my iPhone, I can establish the vpn connection, but can not access any websites.
>
> From the General VPN info, it says the server address is 127.0.0.1, which doesn’t sound right.
>
> One strange thing is that if I change the endpoint’s ip to a couple arbitrary ones, I can still establish vpn connections, but can not access any websites and server address is 127.0.0.1, same result as my config.
>
> Also after I scan the qr code and the VPN profile is added, iPhone will alert an error saying the vpn server could not be found, but if I dismiss I can establish the connection (and couldn’t access any site).
>
> I wonder what I might have done wrong?
>
> Thanks.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Multiple connection support for GUI clients
From: Jason A. Donenfeld @ 2019-04-06 11:58 UTC (permalink / raw)
To: Varun Priolkar; +Cc: WireGuard mailing list
In-Reply-To: <CALwBDFuMTbXCEXW3Qbpbuk6LL1pj+bCedZ9p6P6R6tJV0zBqTQ@mail.gmail.com>
On iOS and Android, this is a limitation of the APIs provided to us by
Apple and Google. On macOS, the API is extremely buggy with multiple
tunnels, and we're not sure we can make it usable until Apple
straightens out the behavior there in a future release. If you'd like
to poke around with the latter, feel free to join us in #wireguard on
Freenode.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: [PATCH] centos 6 compatibility
From: Mieczysław Nalewaj @ 2019-03-29 14:36 UTC (permalink / raw)
To: wireguard
In-Reply-To: <c3e6e9e7-40c6-def5-df0c-cc9fc0740301@poczta.onet.pl>
[-- Attachment #1.1: Type: text/plain, Size: 420 bytes --]
New, improved version of patch for WireGuard Centos6 compatibility.
W dniu 2019-03-27 o 15:48, Mieczysław Nalewaj pisze:
> Is there any chance to add this code?
>
> W dniu 2019-03-03 o 14:30, namiltd@poczta.onet.pl pisze:
>> ---
>> src/crypto/zinc/blake2s/blake2s.c | 17 +++++++++++++++++
>> src/socket.c | 7 +++++++
>> 2 files changed, 24 insertions(+)
>> ....
>> .ipv6_v6only = true
>
>
[-- Attachment #1.2: Type: text/html, Size: 1882 bytes --]
[-- Attachment #2: wireguard.diff --]
[-- Type: text/plain, Size: 1125 bytes --]
diff -ruN master/src/socket.c master-centos6/src/socket.c
--- master/src/socket.c 2019-03-29 15:10:20.000000000 +0100
+++ master-centos6/src/socket.c 2019-03-29 15:10:31.000000000 +0100
@@ -16,6 +16,9 @@
#include <linux/inetdevice.h>
#include <net/udp_tunnel.h>
#include <net/ipv6.h>
+#define GCC_VERSION (__GNUC__ * 10000 \
+ + __GNUC_MINOR__ * 100 \
+ + __GNUC_PATCHLEVEL__)
static int send4(struct wg_device *wg, struct sk_buff *skb,
struct endpoint *endpoint, u8 ds, struct dst_cache *cache)
@@ -363,7 +366,11 @@
struct socket *new4 = NULL, *new6 = NULL;
struct udp_port_cfg port4 = {
.family = AF_INET,
+#if GCC_VERSION == 40407
+ {.local_ip.s_addr = htonl(INADDR_ANY)},
+#else
.local_ip.s_addr = htonl(INADDR_ANY),
+#endif
.local_udp_port = htons(port),
.use_udp_checksums = true
};
@@ -371,7 +378,11 @@
int retries = 0;
struct udp_port_cfg port6 = {
.family = AF_INET6,
+#if GCC_VERSION == 40407
+ {.local_ip6 = IN6ADDR_ANY_INIT},
+#else
.local_ip6 = IN6ADDR_ANY_INIT,
+#endif
.use_udp6_tx_checksums = true,
.use_udp6_rx_checksums = true,
.ipv6_v6only = true
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: [PATCH] centos 6 compatibility
From: Mieczysław Nalewaj @ 2019-03-27 14:48 UTC (permalink / raw)
To: wireguard
In-Reply-To: <dd1d1bde-dd6b-6f36-e08f-3552ee0686a2@poczta.onet.pl>
[-- Attachment #1.1: Type: text/plain, Size: 2824 bytes --]
Is there any chance to add this code?
W dniu 2019-03-03 o 14:30, namiltd@poczta.onet.pl pisze:
> ---
> src/crypto/zinc/blake2s/blake2s.c | 17 +++++++++++++++++
> src/socket.c | 7 +++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/src/crypto/zinc/blake2s/blake2s.c
> b/src/crypto/zinc/blake2s/blake2s.c
> index b881db0..60b7763 100644
> --- a/src/crypto/zinc/blake2s/blake2s.c
> +++ b/src/crypto/zinc/blake2s/blake2s.c
> @@ -19,9 +19,16 @@
> #include <linux/init.h>
> #include <linux/bug.h>
> #include <asm/unaligned.h>
> +#define GCC_VERSION (__GNUC__ * 10000 \
> + + __GNUC_MINOR__ * 100 \
> + + __GNUC_PATCHLEVEL__)
>
> +#if GCC_VERSION > 40407
> typedef union {
> struct {
> +#else
> +typedef struct {
> +#endif
> u8 digest_length;
> u8 key_length;
> u8 fanout;
> @@ -33,8 +40,10 @@ typedef union {
> u8 inner_length;
> u8 salt[8];
> u8 personal[8];
> +#if GCC_VERSION > 40407
> };
> __le32 words[8];
> +#endif
> } __packed blake2s_param;
>
> static const u32 blake2s_iv[8] = {
> @@ -74,9 +83,17 @@ static inline void blake2s_init_param(struct
> blake2s_state *state,
> {
> int i;
>
> +#if GCC_VERSION <= 40407
> + const __le32 *words;
> + words = (const __le32 *)param;
> +#endif
> memset(state, 0, sizeof(*state));
> for (i = 0; i < 8; ++i)
> +#if GCC_VERSION > 40407
> state->h[i] = blake2s_iv[i] ^ le32_to_cpu(param->words[i]);
> +#else
> + state->h[i] = blake2s_iv[i] ^ le32_to_cpu(words[i]);
> +#endif
> }
>
> void blake2s_init(struct blake2s_state *state, const size_t outlen)
> diff --git a/src/socket.c b/src/socket.c
> index 652d798..dfc98d3 100644
> --- a/src/socket.c
> +++ b/src/socket.c
> @@ -16,6 +16,9 @@
> #include <linux/inetdevice.h>
> #include <net/udp_tunnel.h>
> #include <net/ipv6.h>
> +#define GCC_VERSION (__GNUC__ * 10000 \
> + + __GNUC_MINOR__ * 100 \
> + + __GNUC_PATCHLEVEL__)
>
> static int send4(struct wg_device *wg, struct sk_buff *skb,
> struct endpoint *endpoint, u8 ds, struct dst_cache *cache)
> @@ -363,7 +366,9 @@ int wg_socket_init(struct wg_device *wg, u16 port)
> struct socket *new4 = NULL, *new6 = NULL;
> struct udp_port_cfg port4 = {
> .family = AF_INET,
> +#if GCC_VERSION > 40407
> .local_ip.s_addr = htonl(INADDR_ANY),
> +#endif
> .local_udp_port = htons(port),
> .use_udp_checksums = true
> };
> @@ -371,7 +376,9 @@ int wg_socket_init(struct wg_device *wg, u16 port)
> int retries = 0;
> struct udp_port_cfg port6 = {
> .family = AF_INET6,
> +#if GCC_VERSION > 40407
> .local_ip6 = IN6ADDR_ANY_INIT,
> +#endif
> .use_udp6_tx_checksums = true,
> .use_udp6_rx_checksums = true,
> .ipv6_v6only = true
[-- Attachment #1.2: Type: text/html, Size: 4954 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Multiple connection support for GUI clients
From: Varun Priolkar @ 2019-04-04 5:41 UTC (permalink / raw)
To: wireguard
Hi,
I tried out the preview Mac OS, iOS and Android clients, which worked
great. However a glaring miss was the lack of support to connect to
multiple Wireguard tunnels at once, which is extremely helpful when
you are only routing specific internal subnets through them. Any plans
for including this functionality in the future? This is possible with
the CLI client.
I'm not sure if this was asked earlier. Apologies if so.
--
Regards,
Varun Priolkar
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Server with multiple peers
From: Varun Priolkar @ 2019-04-05 18:47 UTC (permalink / raw)
To: Aaron Jones; +Cc: wireguard
In-Reply-To: <09129085-bbbe-79da-3b03-2e41c67eafac@gmail.com>
If you really want to do something like this(I'm not sure why), don't
add the route via Wireguard. You can instead use iBGP multipath or
ECMP to do this.
On Fri, Apr 5, 2019 at 9:01 PM Aaron Jones <aaronmdjones@gmail.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 30/03/2019 00:45, Indro Fedrigo wrote:
> > Hi Jason, I'm trying to create a server with multiple peers form a
> > wgx.conf file : the parameter AllowedIPs seems to get set only for
> > the last peer... Any idea ? Thanks for this great piece of
> > software! Indro Fedrigo
>
> You cannot duplicate AllowedIPs. It forms WireGuard's internal routing
> table. You're essentially asking for "If we have traffic to
> 192.168/16, send it to peer A, and also to peer B, and also to peer C,
> and also to peer D".
>
> That doesn't work.
>
> - --
> Aaron Jones
>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAlyndKEACgkQivBzdIir
> MBLnIRAAp3UURDFtevTlWUSwgKiVyzN9eT6MGtHi1owDOSVafWPoHJ+pM2PGkPj9
> v2aJsgeJK6cIC6j23F8G0ombgGsVaNFTVjeOLNThzgkv2DXJhgWjDu1iuyUmlAI6
> ZSuZ9ccd+OPa3YMGX9apGTeulvVjYGs06yJ5xpgCsqIMhCnj/XOS9HoWrGDWHqOA
> 3AZJK9/i3jIXQHYPSCpdXrppNCw8APQWgNuB1aDPdBMcw8bgARiJzWDF7Q2xBPxx
> SXS2PnFp9oG3+CNqGpEKnurUfx6QSGDPVps6a33HGpdTTAfyZw1Ha8ZSQgb3Yzt0
> U1JWxhLAF+o9ubkK0n9Q0jaunrDfDbbuPmvNF3ZAAkKmITsXPSieT0WB6kXk7l0K
> HZbyEexGLwrCTbLhublIazxQZsJe+ftz8liOrQr3/arGKS1NYItRV0nRKKVSR5Xx
> CsUV4Ngz2Wm+gFaET4QmEJJCARY+LNV+Ntrm+R+s+5vgGK1AJ4iRfR2vYt9dotje
> NiyHqF3FTFpqNK/tZ4CXgROniAmqJs5R4MRRqE5cgEsX8te5iDeCbtZPaAQepECj
> +tWhd10//pjr0G5PajPD8bzIWU2cgHT6JkqwA4l/ibR5EaJm7LQvS0ppUVzS6poy
> bbY0YILEtPSkDioZhxkZ3GTR2rAmE5lcGdW054CYDEdhfx9bYGo=
> =6Gmi
> -----END PGP SIGNATURE-----
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
--
Regards,
Varun Priolkar
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* mesh VPN with wireguard?
From: Tomasz Chmielewski @ 2019-03-28 14:22 UTC (permalink / raw)
To: wireguard
Does Wireguard allow to set up mesh VPN with "relative ease"?
Say, we have 10 servers with public IPs, we want them all to create a
VPN network with private subnet 10.11.12.0/24, and have all 10 servers
communicate directly with each other.
Then a year later, expand it to 100 servers.
Something in the line of: https://www.tinc-vpn.org/
Tomasz Chmielewski
https://lxadm.com
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* [ANNOUNCE] WireGuard Snapshot `0.0.20190406` Available
From: Jason A. Donenfeld @ 2019-04-06 11:21 UTC (permalink / raw)
To: WireGuard mailing list
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
A new snapshot, `0.0.20190406`, has been tagged in the git repository.
Please note that this snapshot is, like the rest of the project at this point
in time, experimental, and does not constitute a real release that would be
considered secure and bug-free. WireGuard is generally thought to be fairly
stable, and most likely will not crash your computer (though it may).
However, as this is a pre-release snapshot, it comes with no guarantees, and
its security is not yet to be depended on; it is not applicable for CVEs.
With all that said, if you'd like to test this snapshot out, there are a
few relevant changes.
== Changes ==
* allowedips: initialize list head when removing intermediate nodes
Fix for an important regression in removing allowed IPs from the last
snapshot. We have new test cases to catch these in the future as well.
* wg-quick: freebsd: rebreak interface loopback, while fixing localhost
* wg-quick: freebsd: export TMPDIR when restoring and don't make empty
Two fixes for FreeBSD which have already been backported into ports.
* tools: genkey: account for short reads of /dev/urandom
* tools: add support for Haiku
The tools now support Haiku! Maybe somebody is working on a WireGuard
implementation for it?
* tools: warn if an AllowedIP has a nonzero host part
If you try to run `wg set wg0 peer ... allowed-ips 192.168.1.82/24`, wg(8)
will now print a warning. Even though we mask this automatically down to
192.168.1.0/24, usually when people specify it like this, it's a mistake.
* wg-quick: add 'strip' subcommand
The new strip subcommand prints the config file to stdout after stripping
it of all wg-quick-specific options. This enables tricks such as:
`wg addconf $DEV <(wg-quick strip $DEV)`.
* tools: avoid unneccessary next_peer assignments in sort_peers()
Small C optimization the compiler was probably already doing.
* peerlookup: rename from hashtables
* allowedips: do not use __always_inline
* device: use skb accessor functions where possible
Suggested tweaks from Dave Miller.
* qemu: set framewarn 1280 for 64bit and 1024 for 32bit
These should indicate to us more clearly when we cross the most strict stack
thresholds expected when using recent compilers with the kernel.
* blake2s: simplify
* blake2s: remove outlen parameter from final
The blake2s implementation has been simplified, since we don't use any of the
fancy tree hashing parameters or the like. We also no longer separate the
output length at initialization time from the output length at finalization
time.
* global: the _bh variety of rcu helpers have been unified
* compat: nf_nat_core.h was removed upstream
* compat: backport skb_mark_not_on_list
The usual assortment of compat fixes for Linux 5.1.
This snapshot contains commits from: Jason A. Donenfeld, Luis Ressel, Samuel
Neves, Bruno Wolff III, and Alexander von Gluck IV.
As always, the source is available at https://git.zx2c4.com/WireGuard/ and
information about the project is available at https://www.wireguard.com/ .
This snapshot is available in compressed tarball form here:
https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20190406.tar.xz
SHA2-256: 2f06f3adf70b95e74a7736a22dcf6e9ef623b311a15b7d55b5474e57c3d0415b
BLAKE2b-256: 787a01fa3d6a800d7376a04ff57dd16d884a7d3cb99d2f91bfc59895ab759200
A PGP signature of that file decompressed is available here:
https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20190406.tar.asc
Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
If you're a snapshot package maintainer, please bump your package version. If
you're a user, the WireGuard team welcomes any and all feedback on this latest
snapshot.
Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/
Thank you,
Jason Donenfeld
-----BEGIN PGP SIGNATURE-----
iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlyoi8YQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrjjSD/0fLlg/QLlGngPIldxT/BsaNLyiPxBBcrFv
lr0jl0x6qNXi6Gj/2KEdiTH/wCmzsWhu7Fa+q5KIly8hYDDBnDfDXYVxQcUva9H0
1XNXDuq+R2yW9r7pWZXRWtbmxWrY6SWvoB73L0Tbqrv0AIFNtmJdF5ut7lFuCw+v
5TZ3OsXvATGVDx9wWVdufrT3la+RhzYDushNJ8JZtCcENKutUgLg3QfjiArjfT7W
ndjsVINbeXWeUsB/lEK95U9yliCLjQiaJspf6LSvm/s7V+ZIQybWi2a4x9T5ZwuH
o2JP5x4xOElCH3hJ+lCD/rSSBHFRkwq0XtwjOVcgTRXZSWCbuaE/CSeA4JaAKXdB
rklV+LpBt9h/ghm8o92ieExK2IJwoOBM8b1f+DEjIepc75PA0BuSqhFXRuV4jAr9
i3zEtDz48ZksY6z9o+XObVCAg64sh+7vOr9Ztgkx30juDbwAoMfCx2IDSb702GlW
sBQwt5fbhC1y0k4WfY/MMuuH29jcJUuDHB7bees3atXr5yOR7r58gEKKKGwcHPG+
8+Dz+ihRv9pFSJPCon4nupohHMwBo7ZjpsV3V6lkz8GY7+QeM/P9BQLkdpIU38NS
bazNAN1MAkvLOkYS6gMK5Y8o8+uJsLJJMQCaDSx5eMUkYS4TE8YHBH4BucfpzW6P
bdz1k5I6NQ==
=eR4J
-----END PGP SIGNATURE-----
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Crashes in wg_allowedips_insert_X
From: Jason A. Donenfeld @ 2019-04-06 10:28 UTC (permalink / raw)
To: mikma.wg; +Cc: WireGuard mailing list
In-Reply-To: <CAHmME9o=2FVbqH0Sn6oD6ss-edsnJHNMKsXHehEAwDqv1juQEg@mail.gmail.com>
Let me know if this fixes it for you:
https://git.zx2c4.com/WireGuard/commit/?id=fdfdd38cceebcd62df60785e8523e068b84f7076
Thanks again for the bug report. I'll have a new snapshot out fairly
soon containing this important fix.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: Crashes in wg_allowedips_insert_X
From: Jason A. Donenfeld @ 2019-04-06 9:23 UTC (permalink / raw)
To: mikma.wg; +Cc: WireGuard mailing list
In-Reply-To: <505e458e-4df9-8fbe-9891-83bdc8933260@m7n.se>
Thanks for the report! I'll try to fix this and will let you know.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* Re: How ca I use two peers with 0.0.0.0?
From: ajs124 @ 2019-04-05 17:48 UTC (permalink / raw)
To: wireguard
In-Reply-To: <1554113120.148180037@f500.i.mail.ru>
Hey!
There's multiple ways to achieve this, each with its own set of drawbacks.
Firstly though, the reason why this is impossible the way you tried it, can be seen in section two (Cryptokey Routing) of the paper[1].
Now onto how you can do this anyhow:
1. Multiple wireguard interfaces
The problem being that you need more ports, because you can't listen twice on the same ip on the same port. (Well, you kind of can, but let's just say you can't).
2. Tunnel over wireguard, e.g. IPIP, GRE, VXLAN, etc
The main drawback is that every tunneling layer comes with more overhead and it's just not a pretty solution, but it should work.
I hope this helps you in solving your problem.
Best Regards
ajs124
[1]: https://www.wireguard.com/papers/wireguard.pdf
On Mon, 01 Apr 2019 13:05:20 +0300
Дмитрий Марков <dmitri__13@mail.ru> wrote:
> Hello!
>
> Recently I tried to install wireguard.
>
> I have 4 computers. 2 of them have public ip. 2 of them behind NAT.
>
> I want to use 2 public PC as endpoits, but I don't understand how to set up 0.0.0.0 for both of them on client side.
>
> So this my configuration on clientside behind NAT
> [Interface]
> ListenPort = 51820
> PrivateKey = KEY
> [Peer]
> PublicKey = KEY1
> AllowedIPs = 0.0.0.0/0
> Endpoint = X.X.X.X:51820
> [Peer]
> PublicKey = KEY2
> AllowedIPs = 0.0.0.0/0
> Endpoint = X.X.X.X:51820
> Wireguard don't allow me to use 0.0.0.0 on both of them. How can I use two peers at this situation?
>
>
> --
> With Best Regards,
> Dmitry Markov
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox