Re: Seeking suggestions for a WG port to use with restrictive public wifi networks
And also 4433 which is used by DTLS https://wiki.wireshark.org/DTLS --dad On 20/11/18 9:53 AM, Lonnie Abelbeck wrote: On Nov 19, 2018, at 2:33 PM, John wrote: Should I stick with the "standard" udp service ports for my trial-and-error based approach? Wikipedia has an article that lists many of these (List_of_TCP_and_UDP_port_numbers). Any suggestions are welcomed. Possibly: UDP/500 (IPSec IKE) or UDP/4500 (IPSec NAT-T) Lonnie ___ 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
Re: Android key-icon in statusbar
> On 19.11.2018, at 21:04, nico...@eisfunke.com wrote: > > Hello, > >> I’v installed wireguard-app from play store on android 8.1. >> If using the userspace version i get a "key-icon" in the status-bar when a >> tunnel is active. >> Switching to the kernel version the icon is not working any more. > > the userspace version uses the native Android VPN-API, which always shows the > key icon for security reasons. > > The kernel version doesn't use this API because, well, it uses the kernel > module. That's why the key icon isn't shown. > Sorry, i’m a new to this and did not know it. I have another problem while testing: My ROM has no wireguard-support so I had to compile myself. Dirty flashing back to original (AICP) ROM caused stock on the lockscreen. Is there any option to force android to use the userspace-version to test both version without erasing the whole flash? What files should i remove in order to avoid the lockscreen issue? Thank you in advance, Robert ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: WireGuard server and multiple clients
Nope, Wireguard should work with multiple clients by default. You just have to manually add the public key and assign an IP for each one. Whether any specific configuration is “recommended” really depends on your exact use-case and assessment of the other options that are available to you. Wireguard can be a great VPN to let friends and family connect to you, but so can OpenVPN or even Hamachi. Commercial WG VPN’s are still sparse primarily because the project is still relatively young. The providers need to write custom integrations to tie wireguard servers into their billing and client key generation systems, and many may not trust it yet because the codebase is evolving so much. From: WireGuard on behalf of John Smith Sent: Monday, November 19, 2018 9:30:00 AM To: WireGuard List Subject: WireGuard server and multiple clients Hello, If I were to set up a WireGuard server and have multiple clients connecting to it, is there anything I need to be aware of? Specifically, I am looking to understand if this is recommended as I already see commercial offering of WireGuard - but not by all providers - so I was wondering if there are any caveats to this approach. For added context, I was managing a VPN server for my family and friends but now I am considering switching to WireGuard. Thanks. - J Smith ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zx2c4.com%2Fmailman%2Flistinfo%2Fwireguarddata=02%7C01%7C%7C682833c00bdb4550ea6008d64e523de3%7C84df9e7fe9f640afb435%7C1%7C0%7C636782512459091879sdata=KARAdd2N0g93ovqzUe8adi3ek%2FOWBZRTWQHllLVO8qs%3Dreserved=0 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Problem to load wireguard LKM in Archlinux
Are you certain that the dkms rebuild was triggered? Seems like like it was not. Perhaps manually trigger it and reboot. On Monday, November 19, 2018, Tosh wrote: > Hello, > > I'm using Wireguard on ArchLinux since a long time, and today I have > some troubles to start my VPN. Here is the log of dmeg when I try to > 'modprobe wireguard' : > > wireguard: Unknown symbol poly1305_blocks_avx (err > -2) > wireguard: Unknown symbol poly1305_emit_avx (err > -2) > wireguard: Unknown symbol poly1305_blocks_avx512 (err > -2) > wireguard: Unknown symbol chacha20_avx512vl (err > -2) > wireguard: Unknown symbol chacha20_avx2 (err -2) > wireguard: Unknown symbol poly1305_blocks_avx2 (err > -2) > wireguard: Unknown symbol chacha20_avx512 (err -2) > > I did a MAJ of my system yesterday, but wireguard wasn't upgraded, so I > don't know where the problem come from...Seems a LKM related to crypto > is missing, but I don't know which one is. > > My kernel is 4.19.2-arch1-1-ARCH, and my wireguard packages are : > > - community/wireguard-dkms 0.0.20181115-1 > > - community/wireguard-tools 0.0.20181115-1 > > Thanks for your work, > > -- > -TOSH- > > If you need privacy you can encrypt your mails with my GPG key: > 9B79 7754 00E2 23C7 FC90 E5C6 E5D9 1B2F 0BD5 3C6A > > -- Sent from Gmail Mobile ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Traffic on port 53 fails on LTE but works on WiFi
Finally, something I can actually help with. Yes, Verizon is actively blocking data through port 53. Back in 2015 I discovered by accident that VPN traffic through port 53 on Verizon was not monitored by whatever they use to calculate data usage. Even better, it worked on deactivated sim cards for a few months after they were deactivated. Basically this meant I could dig around in the local Verizon store's dumpster every few months to find sim cards, pop them into a portable hotspot, and use a VPN over 53 for completely free, unthrottled data on Verizon without even having an account with them. I was a broke high school student and my parents wouldn't allow me to have service on my phone at the time so this was a life saver. Fast forward to a couple months ago, someone else gets root on the mifi 6620L, finds the loophole, and decides to sell mifi's with a VPN client or proxy installed that redirected everything through port 53. Basically resulting in a seamless experience for free unlimited data. These hacked devices sold for $300+ on eBay. Of course, after it was in the wild Verizon started DPIing port 53 and now nothing gets through. On 11/19/18, John wrote: > I have a simple WireGuard VPN setup I use running WG on a home Linux > box and connecting to it with several iOS clients. The server peer is > setup on port 53 since a the networkadmins of some remote WiFi > networks my mobile devices seems to block udp traffic on higher ports. > Encrypted connections work fine on WiFi as I have setup, but do _not_ > work when I connect via LTE (Verizon supplying the data). On LTE, I > am no longer able to transfer data to/from the server peer but I can > handshake with it. > > If I inspect the output of `sudo wg` on the server peer, I see the > endpoint IP address changes to reflect my Verizon LTE IP and the time > since the last handshake reset to a few seconds which is consistent > with my ability to connect to the WireGuard peer server. > > I am unable to transfer data (pull up a web site or check email etc). > It's as/if Verizon is blocking my data flow on port 53. If I change > the port from 53 to 123, it seems to work fine although I do not have > universal connectivity on the various WiFi networks I visit on port > 123. The optimal port would be 53 for my use case. > > So the questions: > 1) What can I try on the server peer side to diagnose? > 2) Do people feel that Verizon is actively blocking the connection on port > 53? > ___ > 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
[ANNOUNCE] WireGuard Snapshot `0.0.20181119` Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, A new snapshot, `0.0.20181119`, 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 consitute 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 == * chacha20,poly1305: fix up for win64 * poly1305: only export neon symbols when in use * poly1305: cleanup leftover debugging changes * crypto: resolve target prefix on buggy kernels * chacha20,poly1305: don't do compiler testing in generator and remove xor helper * crypto: better path resolution and more specific generated .S * poly1305: make frame pointers for auxiliary calls * chacha20,poly1305: do not use xlate This should fix up the various build errors, warnings, and insertion errors introduced by the previous snapshot, where we added some significant refactoring. In short, we're trying to port to using Andy Polyakov's original perlasm files, and this means quite a lot of work to re-do that had stableized in our old .S. This snapshot contains commits from: Jason A. Donenfeld and Samuel Neves. 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.20181119.tar.xz SHA2-256: 7d47f7996dd291069de4efb3097c42f769f60dc3ac6f850a4d5705f321e4406b BLAKE2b-256: 7691db05dbdc6619700f8334ebf258c6160ae2d6f481ef98475f0c5c2627b3a6 A PGP signature of that file decompressed is available here: https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20181119.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- iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlvy8mUQHGphc29uQHp4 MmM0LmNvbQAKCRBJ/HASpd4DrrvKEADU62WfrC0UJ0omVR3KnCfCFCubGkEHmDHr au3H6LEkENJp+JdP593DvSxqdYl6kWKI5rW0IpPJSLCKM17uUHTRKUSDSJ4bvE0h glAhTXhQXgrWz1RVc6l8veXRORY3ypkrzQGFiVN8gWnTTICvshi+zz4LWUI2AAYj BRUFIURBM9cDbb/Hucr/vx9S1zj90WSOvRMXgjT708Vf8QSoExgXN5h7gFGdbjz8 AcyVxdGLh9ES3E9232BmWbsO2N2JUAI5WOmMSCPlFZQPZ1XMT1QoqKV7nS17b7OG jrbLTZ3r4NducKAPt81TE7Z0zrpy9zBm+BP8uJlpATpxa7LH1TK4SkMIBNewoD+a 5H0a4/3DbJ8h53cEQVtrfQYI+tlC9GkW+17GD5PfGJVG1v28VKyWObmOC4+Zm1Wc p/N3aJYMBCoyIf/d1IRWobP/e6s7B9HcvoLYPsYUdscSJZyMw2If0543v+wVoXmW kMDdwPNwUCg1T/dcn5Atf+BIq7LpO4y8rGKpONKbPGXjSALQmCTqK8XGLVZU46rW JrRt/bk3e+CBsTOMpfHSXDJhjiMDViPdqskYGGOfAfGaAUT1V6Oo43fhjC2yAJ4/ ZhmO9NGY697dfcTvD/jq+LlrhAlujOpJYiKJqgE+MWC1OwqUSKP3m1aO5v6gAnpD 6WZrXat0FQ== =PLaO -END PGP SIGNATURE- ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Traffic on port 53 fails on LTE but works on WiFi
OK! Firstly, thank you to everyone who took the time to reply. I think it's a safe assumption that WG is functioning as it should and that I need to identify another port on which to run. I will post a new thread on this topic. On Mon, Nov 19, 2018 at 10:28 AM Jacob Schooley wrote: > > Finally, something I can actually help with. > > Yes, Verizon is actively blocking data through port 53. > > Back in 2015 I discovered by accident that VPN traffic through port 53 on > Verizon was not monitored by whatever they use to calculate data usage. Even > better, it worked on deactivated sim cards for a few months after they were > deactivated. Basically this meant I could dig around in the local Verizon > store's dumpster every few months to find sim cards, pop them into a portable > hotspot, and use a VPN over 53 for completely free, unthrottled data on > Verizon without even having an account with them. I was a broke high school > student and my parents wouldn't allow me to have service on my phone at the > time so this was a life saver. > > Fast forward to a couple months ago, someone else gets root on the mifi > 6620L, finds the loophole, and decides to sell mifi's with a VPN client or > proxy installed that redirected everything through port 53. Basically > resulting in a seamless experience for free unlimited data. These hacked > devices sold for $300+ on eBay. Of course, after it was in the wild Verizon > started DPIing port 53 and now nothing gets through. > > > > On 11/19/18, John wrote: > > I have a simple WireGuard VPN setup I use running WG on a home Linux > > box and connecting to it with several iOS clients. The server peer is > > setup on port 53 since a the networkadmins of some remote WiFi > > networks my mobile devices seems to block udp traffic on higher ports. > > Encrypted connections work fine on WiFi as I have setup, but do _not_ > > work when I connect via LTE (Verizon supplying the data). On LTE, I > > am no longer able to transfer data to/from the server peer but I can > > handshake with it. > > > > If I inspect the output of `sudo wg` on the server peer, I see the > > endpoint IP address changes to reflect my Verizon LTE IP and the time > > since the last handshake reset to a few seconds which is consistent > > with my ability to connect to the WireGuard peer server. > > > > I am unable to transfer data (pull up a web site or check email etc). > > It's as/if Verizon is blocking my data flow on port 53. If I change > > the port from 53 to 123, it seems to work fine although I do not have > > universal connectivity on the various WiFi networks I visit on port > > 123. The optimal port would be 53 for my use case. > > > > So the questions: > > 1) What can I try on the server peer side to diagnose? > > 2) Do people feel that Verizon is actively blocking the connection on port > > 53? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181119` Available
Hi Jordan, On Mon, Nov 19, 2018 at 7:04 PM Jordan Glover wrote: > > It fails to build for me (doing in-kernel build with Linux 4.20rc3 and > WireGuard/contrib/kernel-tree/create-patch.sh) with below message: > > > make[2]: *** No rule to make target > 'net/wireguard/crypto/zinc/chacha20/chacha20-x86_64.o', needed by > 'net/wireguard/built-in.a'. Stop. > > There is also following warn when applying wireguard patch: > > diff: /WireGuard/src/**/*.S_shipped: No such file or directory Ugh, sorry. This keeps happening: neglecting the jerry rig scripts, because they're not in src/. I need to either move those into src/ or add them to the CI so that this doesn't happen again. https://git.zx2c4.com/WireGuard/patch/?id=37466fb996ea174cddd3d836c2f49c53b10648ad should fix it. Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
WireGuard server and multiple clients
Hello, If I were to set up a WireGuard server and have multiple clients connecting to it, is there anything I need to be aware of? Specifically, I am looking to understand if this is recommended as I already see commercial offering of WireGuard - but not by all providers - so I was wondering if there are any caveats to this approach. For added context, I was managing a VPN server for my family and friends but now I am considering switching to WireGuard. Thanks. - J Smith ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Android key-icon in statusbar
Hello! I’v installed wireguard-app from play store on android 8.1. If using the userspace version i get a "key-icon" in the status-bar when a tunnel is active. Switching to the kernel version the icon is not working any more. Any sugestions? Robert ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Docker Swarm over WireGuard
Hello there! I'm using WireGuard about a year and really happy with it. It's easy-to-use, fast and stable. Great thanks for this precious software. Sometimes I use servers from providers which do not have any internal network. So I tried to setup Docker Swarm and route it's ingress network over WireGuard. For some reason it's not working: internal load balancer fails to access containers from other nodes. So it's impossible to reach containers from other nodes, load balancing/routing mesh becomes completely broken. Setup is pretty basic and everything works like a charm but this particular feature. I also found few related questions, so there are number of people interested in fixing this: https://stackoverflow.com/questions/52409012/docker-swarm-mode-routing-mesh-not-working-with-wireguard-vpn https://github.com/moby/moby/issues/37985 https://github.com/moby/moby/issues/36689 (that's my issue, more details here) Of course, I do understand that this could be Docker-specific issue, so I'm just asking here for some directions: - Does someone succeeded at enchancing Docker Swarm with WireGuard? - My it be netns-related thing? Should we place Docker ingress network and wg0 interface into same namespace? Any help appreciated. -- Best regards, Kirill Kovalev ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181119` Available
On Monday, November 19, 2018 6:27 PM, Jason A. Donenfeld wrote: > Hello, > > A new snapshot, `0.0.20181119`, 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 consitute 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 == > > - chacha20,poly1305: fix up for win64 > - poly1305: only export neon symbols when in use > - poly1305: cleanup leftover debugging changes > - crypto: resolve target prefix on buggy kernels > - chacha20,poly1305: don't do compiler testing in generator and remove xor > helper > - crypto: better path resolution and more specific generated .S > - poly1305: make frame pointers for auxiliary calls > - chacha20,poly1305: do not use xlate > > This should fix up the various build errors, warnings, and insertion > errors > introduced by the previous snapshot, where we added some significant > refactoring. In short, we're trying to port to using Andy Polyakov's > original > perlasm files, and this means quite a lot of work to re-do that had > stableized > in our old .S. > > This snapshot contains commits from: Jason A. Donenfeld and Samuel Neves. > > 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.20181119.tar.xz > SHA2-256: 7d47f7996dd291069de4efb3097c42f769f60dc3ac6f850a4d5705f321e4406b > BLAKE2b-256: > 7691db05dbdc6619700f8334ebf258c6160ae2d6f481ef98475f0c5c2627b3a6 > > A PGP signature of that file decompressed is available here: > https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20181119.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 > It fails to build for me (doing in-kernel build with Linux 4.20rc3 and WireGuard/contrib/kernel-tree/create-patch.sh) with below message: make[2]: *** No rule to make target 'net/wireguard/crypto/zinc/chacha20/chacha20-x86_64.o', needed by 'net/wireguard/built-in.a'. Stop. There is also following warn when applying wireguard patch: diff: /WireGuard/src/**/*.S_shipped: No such file or directory Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Seeking suggestions for a WG port to use with restrictive public wifi networks
Have you tried 1701/udp? That's the standard L2TP port - it's unlikely to be particularly useful on networks which deliberate block VPN access, but I've encountered a number of networks on which that port was usable, and not much else. Cheers, Steve On Tue, 20 Nov 2018 at 09:38 John wrote: > Use case: WG VPN server (linux) and iOS clients (I mention that > because the solution need to just-work with the iOS WG client without > extra steps for ease). > > Goal: identify a port on which to run WG that has a good chance of > being open to clients on both LTE and public WiFi networks. > > I currently run OpenVPN on 80/tcp which works for the vast majority of > networks. I'd like to switch over to WG. > > I found that port 123 is not very compatible with the public networks > I tend to use. Port 53 seems to work on WiFi, but does not ork due to > Verizon actively blocking traffic on it. I tried a few higher numbers > including 51820 and 41185 but they seem to be blocked. I also tried a > few standard service ports including: 80, 443, and 1194 but all of > which failed to connect. > > Should I stick with the "standard" udp service ports for my > trial-and-error based approach? Wikipedia has an article that lists > many of these (List_of_TCP_and_UDP_port_numbers). Any suggestions are > welcomed. > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > -- Cheers, *Steve Gilberd* Erayd LTD *·* Consultant *Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237* *PO Box 10019, The Terrace, Wellington 6143, NZ* ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20181119` Available
On Monday, November 19, 2018 8:02 PM, Jason A. Donenfeld wrote: > Hi Jordan, > On Mon, Nov 19, 2018 at 7:04 PM Jordan Glover > golden_mille...@protonmail.ch wrote: > > > It fails to build for me (doing in-kernel build with Linux 4.20rc3 and > > WireGuard/contrib/kernel-tree/create-patch.sh) with below message: > > make[2]: *** No rule to make target > > 'net/wireguard/crypto/zinc/chacha20/chacha20-x86_64.o', needed by > > 'net/wireguard/built-in.a'. Stop. > > There is also following warn when applying wireguard patch: > > diff: /WireGuard/src/**/*.S_shipped: No such file or directory > > Ugh, sorry. This keeps happening: neglecting the jerry rig scripts, > because they're not in src/. I need to either move those into src/ or > add them to the CI so that this doesn't happen again. > > https://git.zx2c4.com/WireGuard/patch/?id=37466fb996ea174cddd3d836c2f49c53b10648ad > should fix it. > > Jason I can confirm that above fix works. Thank you. Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
