Re: [ANNOUNCE] Alpha Snapshots of WireGuard for Android and macOS
MacOS users should be aware that if you have manually assigned DNS servers
the current wg-quick implementation will remove them and not restore them.
On Tue, May 15, 2018, 6:54 PM Jason A. Donenfeld wrote:
> Hey folks,
>
> We're gradually adding more platforms capable of running WireGuard, thanks
> to
> some still-buggy userspace code Mathias and I have been developing. Today
> you
> can try WireGuard on two new platforms: Android and macOS.
>
> [NEW] WireGuard for Android
> ---
> You can download the app from the Play Store or from F-Droid. It supports
> adding wg-quick(8)-style .conf files or .zips of them. The app uses the
> kernel
> module if available, which gives the best performance, stability, and
> battery
> life, and falls back to the userspace code if it's not available. Download
> at:
> https://play.google.com/store/apps/details?id=com.wireguard.android
>
> [NEW] WireGuard for macOS
> -
> You can install wg-quick, wg, and wireguard-go using Homebrew. Then you
> should
> be able to run `wg-quick up whatever` and familiar commands as you're used
> to.
> If you're setting up a network manually, you can run `wireguard-go utun3`
> in
> place of the usual Linux command `ip link add utun3 dev wireguard`. Install
> with the Homebrew command:
> $ brew install wireguard-tools
>
> [FUTURE] WireGuard for ${YOUR_FAVORITE_PLATFORM}
>
> It's a work in progress, and we hope to have nice things to announce in the
> coming weeks. If you're interested in helping to develop support for a
> particular platform, please send us an email at t...@wireguard.com.
>
> [WORKHORSE] WireGuard for Linux
> ---
> The Linux kernel implementation remains the recommended and most complete
> WireGuard implementation, and we're actively working on upstreaming this
> code
> to kernel.org. Install instructions are available for every major distro
> on:
> https://www.wireguard.com/install/
>
> [DISCLAIMER] Alpha Warning for Security-related Software
>
> The new implementations for macOS and Android are alpha quality, at best,
> so
> keep expectations low. There are bugs. There may even be security issues,
> and
> we don't yet certify that this software does what we want it to do. Let us
> know as you encounter the inevitable nasty bugs. Consider this as
> "pre-release"
> software.
>
> Enjoy!
> Jason
> ___
> 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: WG load balancing?
On Thu, May 10, 2018 at 5:22 AM Matthias Urlichs wrote: > Hello list, > Assume a branch office with two uplinks to the Internet that wants to > use WG to talk to the main office, using both of these uplinks in > parallel (assuming they're both up) for better uplink speed (and for > redundancy if they aren't). Now the obvious idea is to create two WG > interfaces on each side, and add a couple of firewall rules to make sure > that packets fwmarked 1 go out on the first uplink, and so on. > That's the easy part. The hard part is how to teach the kernel to load > balance its default route between the WG interfaces. I tried to use a > libteam or bonding interface to tie them together, but apparently WG > isn't Ethernet, so that doesn't work. > I thought about using a GRE tunnel, but tunnels have fixed endpoint > addresses – somehow I don't think it'd be a good idea to create two > wireguard interfaces with the same IP address … and I don't really want > to do heavy-handed address mangling on every packet. Losing all > connectivity whenever I happen to flush my firewall tables doesn't > appeal to me. > Ideally I would like the kernel's wireguard interfaces to be compatible > with teaming … any takers? > -- > -- Matthias Urlichs > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard If you are in kernel >=4.4 you can use hash-based multipath routing. A hash by default based upon source and destination address will be calculated and flows matching the hash will be assigned to a particular path. If need to better balance traffic you can configure the kernel to use source and destination ports as part of the hash also. The kernel will assign hashes to the links in a manner that balances the traffic across them. You can also assign weights to each path and the kernel will assign traffic according to the ratio of the weights. For example to equally balance the traffic between 2 wireguard interfaces the command would be: ip route add default nexthop dev wg0 weight 1 nexthop dev wg1 weight 1 If you wanted to send 5 times as much traffic over the 2nd link: ip route add default nexthop dev wg0 weight 1 nexthop dev wg1 weight 5 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Problems with IP
The recently released RHEL 7.5 ships with iproute2 4.11.0 so, shouldn't have the problem. If someone is interested in maintaining a patched version of 3.10.0 for prior RHEL versions the commit which added suppress_prefixlength can be found at https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?h=v3.12.0&id=b1d0525f9cc3ef6fa7670ff3769828404cea31d4 It first appeared in version 3.12.0. The patch applies cleanly on top of iproute 3.10.0. Whether it does on Redhat's patched version of 3.10.0 I don't know. On Fri, Apr 20, 2018 at 11:56 AM, Jason A. Donenfeld wrote: > Hey Joe, > > Maybe we should patch the rpm for RHEL in some way? I can probably work > around the old iproute2 by doing a different ip-rule(8) trick, if you'd be > up for shipping that. > > Jason > > -- > Sent from my telephone. > > On Fri, Apr 20, 2018, 16:48 Aaron Jones wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 20/04/18 14:32, bessonov.vic...@e-queo.com wrote: >> > I've tried to run this instruction manually, result is still the >> > same. The system runs CentOS 7 and properly updated. >> >> Updated, yes; but not up to date. The version of iproute2 is too old. >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2 >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJa2f2dAAoJEIrwc3SIqzASCVMP/A9tBO8Sbl1z9rGK0q9vjdyK >> kMeFxKGVWqR4Xz8Sy9wfS+iKeXlBQxKukaZCTuSDr9WzsbpzvohYcE0FvGuDPZgf >> G9TgrGK9NAPow6pIdCfgeIIUnBQQ5geLtnxXKdrr7yaXn2rB8KWi1nwM+NbenNnC >> iJcPe7U9I+RzlDwESTHJMJJGR4hI8zbRSU4H3Nb2PEoYpizHUQuG56RGmOSDO08a >> 1+uol4iBsR0EEBqyt3PUDjuSTjXSAm6G328pErC+aU6I9wP+FHsFUvfMnVd7GDG1 >> mJfVx2R8mLInlWX0gpL9YgelOC+/jIRDOeNKvdQAoqF3+7Tz+mT7J++/FLdQa3Sq >> mgHaX+Tvjw6Rnl9KEYC9DqclmHuaoeAHtp7FGnxOXrSOE6fwVh/4BsfKKb7ntU0C >> Wn0tRNrd/QagFm9Nyytm1g1IjoD/B+dXo9cT9p+bls/wBis4+jZZqJte40Kg1MaT >> TlUeyLqVqXMWoUyqqn7Rit4E5ejgPbQpPywdKlJKCQrW4OoU+ualW+t+LUrluPAQ >> ANQkenewaPmoEY4wLGJx02LeD8heYRGzVDkBMmohMiaSVgwibOfxcea7WiggcMNy >> HICqRz1rCHIhDa0togIb2YPSiVsz+7rqW6shUgFabpDV3c7edfaZNcu5KwW5laCk >> nY6A1S5hrgEOr3E8iPeK >> =mFFE >> -END PGP SIGNATURE- >> ___ >> 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 > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [HACK] UDP tunneling over TCP for WireGuard
I have done similar in the past using socat but found I got better reliability and performance by running ppp over pseudo ttys created using socat and then having wireguard use the ppp interfaces for their traffic. An example of the socat and ppp configuration: On the server side: socat pty,link=/dev/ttyp10,raw,echo=0 TCP4-LISTEN:587,reuseaddr sudo pppd noauth /dev/ttyp10 10.10.50.10:10.10.60.10 On the client side: sudo socat pty,link=/dev/ttyp10,raw,echo=0 TCP4:server_address:587,reuseaddr sudo pppd noauth /dev/ttyp10 10.10.60.10:10.10.50.10 On Wed, Apr 18, 2018 at 7:55 AM, Luca Beltrame wrote: > Hello, > > at one of the places I use WireGuard, outgoing UDP is *completely* blocked by > the perimeter firewall. In addition, only a handful of ports are open. (Not > that this has helped security in any way, but I digress) > > This meant that I could not connect to my WireGuard-using OpenWRT router which > is somewhere else. > > As a happy WireGuard user, I thought about how to handle this. Port was an > easy solution: 587 is open, so I could just have the router redirect it to the > actual endpoint port. UDP, not so much. > > What came out was a horrid hack involving socat and sacrifices to the Great > Old Ones, but that it worked enough for me. > > tl;dr: Use socat to tunnel local UDP port via TCP to a remote port, then > redirect UDP there to the actual WireGuard endpoint port. > > First of all, I set a systemd unit to have this running continuously: > > [Unit] > Description=UDP over TCP forwarder > After=autossh@tsugumi.service > > [Service] > ExecStart=/usr/bin/socat -t600 -T600 -d -d UDP4-LISTEN:51821 tcp4:ENDPOINT_IP: > 587 > User=nobody > Group=nobody > Restart=always > ProtectSystem=full > ProtectHome=true > PrivateTmp=true > > [Install] > WantedBy=multi-user.target > > I set fairly high timeouts because WireGuard is not very chatty and socat > usually exists when there's no traffic for a while. > > Then, I set the relevant bits in wg0.conf: > > [Interface] > ListenPort = 51820 > PrivateKey = > Address = 10.64.0.4/32 > MTU=1280 > > [Peer] > PublicKey = > AllowedIPs = 10.64.0.1/32, > Endpoint = 127.0.0.1:51821 > PersistentKeepalive = 60 > > As you notice, it goes to localhost then it's pushed via TCP to the remote > endpoint. At this time, I had to lower the MTU to adjust for overhead (as > discussed on IRC) that I introduced with this monstrosity. > > On the remote side, I have (running through openWRT's init): > > /usr/bin/socat -d -d tcp4-listen:587,reuseaddr,fork UDP4:127.0.0.1:51820 > > which brings packets back to port 51820, where wg is listening. > > And voila', it works: > > interface: wg0 > public key: > private key: (hidden) > listening port: 51820 > > peer: > endpoint: 127.0.0.1:51821 > allowed ips: 10.64.0.1/32, > latest handshake: 30 seconds ago > transfer: 300.68 MiB received, 175.78 MiB sent > persistent keepalive: every 1 minute > > Very hacky, but gets the job done. Any suggestions on how to make it better? > > -- > Luca Beltrame - KDE Forums team > KDE Science supporter > GPG key ID: A29D259B > ___ > 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: Why does 'allowed-ips' affect route selection behavior?
On Sun, Apr 15, 2018 at 6:26 PM, Jason A. Donenfeld wrote:
> Hi Patrick,
>
> I see some others on the wireguard mailing list have replied to a
> ghost email. That is, I don't have the original that they're replying
> to. Looking into it a bit further, it appears that reasonable spam
> filters -- which includes but is not limited to gmail's -- will have
> your mail immediately bounced, because of your strict dmarc entry
> ("v=DMARC1; p=reject; rua=mailto:dm...@insaneirish.com";), since
> mailing list servers like lists.zx2c4.com tend to "remail" things. You
> might want to loosen these up a bit. Anyway, I've pulled it out of the
> archives for quoting here:
More recent versions of the 2.1 series of mailman have features to
wrap messages from senders using DMARC instead of just straight
remailing them to help address this issue.
>
>> Hi Folks,
>>
>> Getting my feet wet with wireguard and enjoying the simplicity and
>> performance thus far. Nonetheless, I have a question about how the
>> normal route selection process is being affected by what's configured
>> for 'allowed-ips'.
>>
>> I set up a peer and configured 'allowed-ips' for 0.0.0.0/0, as I was
>> going to be sending multiple routes over the peer link via BGP and
>> didn't want to keep modifying it. However, even though my default
>> route was over a different interface, this seemed to result in Linux
>> trying to route default traffic over wg0 despite there not being a
>> default route pointing to wg0.
>>
>> Specifically:
>>
>> $ sudo ip route show
>> default via 10.199.199.1 dev wlan0
>> 10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100
>> 10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131
>>
>> By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1.
>> Packet captures were showing traffic trying to instead use wg0. Then I
>> found this:
>>
>> $ sudo ip route get 4.2.2.1
>> 4.2.2.1 dev wg0 table 51820 src 10.111.111.100
>> cache
>>
>> Can someone please explain this behavior?
>>
>> Obligatory... $ uname -rvm
>> 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv7l
>>
>> And... $ dpkg -l | grep wireguard
>> ii wireguard 0.0.20180413-1 all
>>fast, modern, secure kernel VPN tunnel (metapackage)
>> ii wireguard-dkms 0.0.20180413-1 all
>>fast, modern, secure kernel VPN tunnel (DKMS version)
>> ii wireguard-tools 0.0.20180413-1 armhf
>>fast, modern, secure kernel VPN tunnel (userland utilities)
>
> Are you using wg-quick(8)? If so, wg-quick will by default do special
> things to sync up the allowed ips and the system routing table, which
> includes some special case rule tricks for 0.0.0.0/0. It sounds like
> you know what you're doing and don't actually want this behavior. For
> this, you can simply specify Table=off in the [Interface] section.
> This overrides the default value of Table=auto. Alternatively, you can
> choose Table=main if you want those routes added to the default table
> with no special rule tricks. Or, you can choose an arbitrary
> named-table or number if you'd like to add the allowed ips to some
> other routing table. The man page has info.
>
> Jason
> ___
> 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: Bird OSPF Problems
On Mon, Apr 16, 2018 at 6:31 AM, Zsolt Hegyi wrote: > Hi Cedric, > > As far as I know, wireguard doesn't support multicasts yet, which OSPF uses > for neighbor discovery. The reason why BGP works is because it uses unicast > TCP packets as means of communication. > > To get around this, try telling BIRD that your wireguard interface is an > NBMA network (or a point-to-point link). When it is said that wireguard doesn't support multicast what is really meant is that multicast traffic won't be replicated across multiple peers on the same interface. If only a single peer is required to receive the multicast traffic than assigning the multicast address to that peer will allow the multicast traffic to traverse the wireguard connection to it. When using OSPF with wireguard I find it easiest to just assign each peer to a seperate wireguard interface with an allowed-ip of 0.0.0.0/0. Then it just works because the multicast traffic passes and I don't have to worry about assigning every network that might ever use the peer to the allowed-ip list. If you need to use OSPF over a single or multiple peers on the same interface than most likely you should set the interface type to point-to-multipoint. point-to-point still uses multicast and NBMA still has a DR election and expects all neighbors to be fully meshed and able to talk directly to each other over the network. point-to-multipoint uses unicast but treats each link as a point-to-point connection so there is no DR election. > > vista > > On Mon, 16 Apr 2018, 11:27 cedric Kienzler, > wrote: >> >> Hey List, >> >> i'm currently facing issues with OSPF over the wireguard tunnel. >> >> I use both, IPv4 and IPv6 and everything works fine. I can ping through >> the tunnel, traffic flows perfectly, but when i try to configure OSPF using >> the Bird routing daemon, i didn't even see a HELLO message. Also when trying >> to list the interface using 'show ospf interfaces' i didn't even see the >> Interface. >> >> For IPv6 i use 2a03 as prefix. >> Should i configure multicast IPv6 (fe80::) on the interface too to get >> OSPF working? >> >> Interesting fact: BGB using Bird works just fine. >> >> Anyone here that could help me? >> >> >> Thanks a lot. >> >> Best regards, >> Cedi >> ___ >> 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 > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: PMTU Discovery Security Concerns
On Sun, Apr 15, 2018 at 12:13 PM, Jason A. Donenfeld wrote: > On Sun, Apr 15, 2018 at 6:06 PM, Tim Sedlmeyer wrote: >> PMTUD on the Internet is often broken and increasingly becoming more >> broken, so in my opinion introducing any level of potential security >> concern to support it would be unwise. > > I was wondering if there's actually an appropriate use case for PMTUD > within networks that are well behaved. For example, within various > intranets, or between physical sites within a campus. Perhaps these > aren't relevant, since they're centrally managed anyway, and so we > should just give up with PMTUD all together? > If you are in the network operations side of a intranet/campus network, getting wireguard going probably isn't your first time wrangling with MTU. >> If MTU issues are regularly presenting a significant issue to >> successful deployment of wireguard than in the short term I would >> suggest doing what many ipsec implementations do, give up some >> performance in order to increase the likelihood of successful >> transmission by assigning a default MTU significantly small enough to >> avoid issues in the vast majority of circumstances. For instance by >> default the OS X ipsec vpn implementation assigns an MTU of 1280, the >> minimum IPv6 datagram size, to the tunnel by default. Cisco assigns an >> MTU of 1300 by default. > > Not a bad idea for end user clients. Ugly, but maybe nobody would be > too perturbed. wg-quick(8) has an MTU= parameter, after all, which > could be set to 1280. > >> In the long term some form of packetization layer path mtu discovery >> probably should be added to the wireguard protocol itself. Perhaps by >> padding the first message of the handshake to utilize it as a mtu >> discovery probe. > > I was thinking about implementing something like this on top of > WireGuard -- a basic ping probe tool that walks through each peer and > tries to ping one of its allowed IPs within the tunnel. Maybe this > would take care of most peoples' use cases. It is explicit, however, > rather than the nice on-demand automatic aspect of traditional PMTUD. Not sure how well a ping probe would work. - Which allowed-ip do you use? - If the allowed-ip is a network, which ip within it do you choose to ping? - If you are connected to a single peer with an allowed-ip of 0.0.0.0/0 what ip do you ping? The allowed-ip isn't guaranteed to be on the same device as the peer so, in the end you aren't measuring the mtu over the connection between peers but the complete path to that allowed-ip which could involve more devices and connections with smaller MTUs than between the peers themselves. See RFC4821, RFC8085 and https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-01 for more info about PLMTUD. https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01 has a quick overview of where IPsec stands with implementing it. > > But anyway, all of this falls into the category of, "let's just not do > PTMUD." I'm still not convinced it's impossible to do securely, mostly > because I haven't heard anybody explicitly say, "we thought about this > for 25 years and it can't be done." ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: PMTU Discovery Security Concerns
PMTUD on the Internet is often broken and increasingly becoming more broken, so in my opinion introducing any level of potential security concern to support it would be unwise. If MTU issues are regularly presenting a significant issue to successful deployment of wireguard than in the short term I would suggest doing what many ipsec implementations do, give up some performance in order to increase the likelihood of successful transmission by assigning a default MTU significantly small enough to avoid issues in the vast majority of circumstances. For instance by default the OS X ipsec vpn implementation assigns an MTU of 1280, the minimum IPv6 datagram size, to the tunnel by default. Cisco assigns an MTU of 1300 by default. In the long term some form of packetization layer path mtu discovery probably should be added to the wireguard protocol itself. Perhaps by padding the first message of the handshake to utilize it as a mtu discovery probe. On Sun, Apr 15, 2018 at 10:08 AM, Jason A. Donenfeld wrote: > Hi list, > > [CC'ing Luis, who's been working on this with me.] > > I've more or less figured out how to do PMTU discovery (something > along the lines of https://xn--4db.cc/WFHQzX2o/c inspired by the vti > driver). I wonder, however, if this is safe to do. > > The basic idea is that if you're talking to a WireGuard peer via its > internal tunnel IP address, the kernel keeps some notion of what that > internal IP address's PMTU is. Meanwhile, WireGuard itself is talking > to that peer via its external endpoint IP address, and the kernel > keeps some notion of what that external IP address's PMTU is. If the > encrypted packets are larger than the external PMTU, well behaved > networks will send ICMP messages, indicating that packets sent to that > external endpoint IP should be smaller. This, however, doesn't have > anything to do with what the user is trying to send internally, and so > there will continue to be overly large packets sent. > > The way to fix it would be to relay the external endpoint PMTU to the > internal tunnel PMTU. Then, when an external encrypted packet gets > dropped due to being overly large, the ICMP message for that winds up > affecting the internal tunneled IP address's PMTU, so that the next > message it sends is smaller. All is well, packets flow, and TCP > sessions no longer stall. This is generally how PMTU discovery works > with network tunnels. > > The security problem is that those ICMP messages indicating we should > send smaller packets are unauthenticated, since they're triggered by > things external to the tunnel, rather than inside the tunnel. By > propagating the information from those unauthenticated ICMP messages > to state that concerns the inside of the tunnel, we're essentially > enabling an unauthenticated state injection. This could enable some > mischief. On the benign end of the spectrum, an attacker could launch > a DoS attack by causing the sending end to use smaller and smaller > packets. On the scarier end of the spectrum, an attacker could > intelligently do this to change the size of packets and observe the > way in which a data flow is rechunked, in order to infer something > about the actual data being encrypted. > > These security concerns make me inclined to just simplistically > declare, "PMTU discovery in tunnels can't be done securely with the > existing Internet, so WireGuard doesn't support it." However, > undoubtedly smart people have thought about this before, and perhaps > they've come up with real solutions for this. Indeed I've come across > various discussions of the matter in the IPsec RFCs. But at the > present moment, I'm unsure what the most reasonable way forward is. > > So, I thought if anyone on the list has thought about this extensively > before and would like to chime in with some wisdom, I'm all ears. > > Regards, > Jason > ___ > 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: Using WG for transport security in a p2p network
On Thu, Apr 5, 2018 at 3:13 AM, Matthias Urlichs wrote: > Hi, > > > Another option would be to run insecure QUIC or SCTP on top of WireGuard, > > You cannot run SCTP on the Internet anyway. Too many routers block anything > that's not TCP/UDP/ICMP. > > I'm also wondering how easy this would be to program. It would clearly be > much > more heavyweight than simply opening a socket, but I guess it can be done > via > invocations of the `wg` or `wg-quick` tools. > > Don't use the tools. There's a library around that you can use to do all of > the heavy lifting via netlink sockets. You'll also need the privilege to > assign addresses and routes to the WG interfaces. > > Ideally we wouldn't need root > > If you go the netlink route, you do need one process that has the > appropriate privilege, which means root at install time (but not runtime). The process doesn't need full root permissions even at install time. Whatever process is going to create and manage the interfaces needs the CAP_NET_ADMIN capability. > > > Once the network is live, we'd need the transport protocol to be relatively > stable, or at least be easily upgradeable > > Well, the WG wire protocol is supposed to be stable by now. Switching away > from it would require new code on your side anyway, so you can implement the > exact method of switching at that time. > > -- > -- Matthias Urlichs > > > ___ > 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: Reconciling "cryptokey-based" and regular routing
You need to create multiple wireguard interfaces and assign a single peer to each. On Fri, Mar 16, 2018 at 1:01 PM, Roman Mamedov wrote: > Hello, > > I need to have multiple gateways on my WG network that can provide access to > the entire IPv4 (or IPv6) Internet, for redundancy and load-balancing > purposes. > > In WG terms this means I need to set AllowedIPs to 0.0.0.0/0 on more than one > peer. Then I would add routes into the regular routing table for various > destinations, > > ip -4 route add 8.8.8.8 via 10.0.0.1 > ip -4 route add 8.8.4.4 via 10.0.0.2 > > or > > ip -4 route add default \ > nexthop via 10.0.0.1 weight 1 \ > nexthop via 10.0.0.2 weight 1 > > or whatever. > > But as documentation and some testing show, this can't really work in WG's > "cryptokey-routing" system. If multiple hosts have 0.0.0.0/0 as allowed IPs, > WG just sends everything to a random one of them (the first one?), > disregarding all of the routing table settings from the examples above. > > Is there any possibility to still use multiple routers like that? > > If not, then could you add an option to not use AllowedIPs for routing? > Or at least to not enforce filtering on incoming packets -- then perhaps I > could have only 10.0.0.1 and 10.0.0.2 in AllowedIPs for those hosts, and > outgoing routing would work properly, with replies from Internet hosts not > getting filtered out? > > (Apologies for multiple posts per day, I'm just deploying WireGuard for the > first time today, and it's quite unusual compared to what I used before. I > will stop soon :) > > -- > 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
Re: Cannot ping peer 1 from peer 2
The ip address for the wg0 interface on peer 2 is set to 10.100.1.2/32 so peer2 has no route to reach 10.100.1.1. You either need to set a route to 10.100.1.1 on peer 2 or change the address on peer 2 so the subnet it is in includes 10.100.1.1. For example 10.100.1.2/24. On Thu, Mar 15, 2018 at 10:07 PM, Vikas wrote: > Here is the config on peer 1 (Vmware VM running ubuntu 16.04): > = > > vk@ubuntu /g/r/c/w/server> ifconfig ens33 > ens33 Link encap:Ethernet HWaddr 00:0c:29:c8:6c:d5 > inet addr:10.0.1.77 Bcast:10.0.1.255 Mask:255.255.255.0 > inet6 addr: fe80::5b06:24b6:c9e4:954e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:327949 errors:0 dropped:0 overruns:0 frame:0 > TX packets:87146 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:351155285 (351.1 MB) TX bytes:12179516 (12.1 MB) > > > vk@ubuntu /g/r/c/w/server> more etc-wireguard-wg0.conf > [Interface] > Address = 10.100.1.1/24 > ListenPort = 51820 > PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A > POSTROUTING -o ens33 -j MASQUERADE > PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D > POSTROUTING -o ens33 -j MASQUERADE > PrivateKey = CPQLRq40QGY3+8yn2LlYb1x3zU/3/Ki+A4QjVYgbakY= > SaveConfig = true > > [Peer] > PublicKey = uL8bs5596DJO7BMnrIVG5btvr4LTzlbx1ovwHe59NBc= > AllowedIPs = 10.100.1.2/32 > > > vk@ubuntu /g/r/c/w/server> ifconfig wg0 > wg0 Link encap:UNSPEC HWaddr > 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 > inet addr:10.100.1.1 P-t-P:10.100.1.1 Mask:255.255.255.0 > UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:459 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) > > > > Here is the config on peer 2 (Vmware VM running ubuntu 18.04): > == > > root@ubuntu /g/r/c/w/client# ifconfig ens33 > ens33: flags=4163 mtu 1500 > inet 10.0.1.71 netmask 255.255.255.0 broadcast 10.0.1.255 > inet6 fe80::c4d7:35d6:306b:fc91 prefixlen 64 scopeid 0x20 > ether 00:0c:29:b6:bb:18 txqueuelen 1000 (Ethernet) > RX packets 532611 bytes 765847699 (765.8 MB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 71767 bytes 5458394 (5.4 MB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > > root@ubuntu /g/r/c/w/client# more etc-wireguard-wg0.conf > [Interface] > Address = 10.100.1.2 > PrivateKey = AMZXJ1vBx6OOnZlbnYHuShTBAPuOzwCgweG73BS/4WY= > > [Peer] > PublicKey = KNuvytvYu9NktxybaOHsCF11q96IGfc+dT/Dv8L6KB0= > AllowedIPs = 0.0.0.0/0 > Endpoint = 10.0.1.77:51280 > > > root@ubuntu /g/r/c/w/client# ifconfig wg0 > wg0: flags=209 mtu 1420 > inet 10.100.1.2 netmask 255.255.255.255 destination 10.100.1.2 > unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 > txqueuelen 1000 (UNSPEC) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 10 bytes 1480 (1.4 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > > root@ubuntu /g/r/c/w/client# ping 10.0.1.77 > PING 10.0.1.77 (10.0.1.77) 56(84) bytes of data. > 64 bytes from 10.0.1.77: icmp_seq=1 ttl=64 time=0.464 ms > 64 bytes from 10.0.1.77: icmp_seq=2 ttl=64 time=0.715 ms > > > root@ubuntu /g/r/c/w/client# ping 10.100.1.1 > PING 10.100.1.1 (10.100.1.1) 56(84) bytes of data. > ^C > --- 10.100.1.1 ping statistics --- > 3 packets transmitted, 0 received, 100% packet loss, time 2033ms > > > What am I doing wrong? > > -- > VK > ___ > 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: Allowed IPs Toggling
Allowed-ips plays a variety of roles which at different times can be mapped to several traditional network roles but one it doesn't really play the role of routing table. Instead they act as a forwarding information base for the wireguard interface matching ip addresses to peers. Wireguard then makes forwarding not routing decisions based upon this "FIB". Since it is acting as a FIB at any given time it can contain only a single destination for any given entry. If you want support for things like equal cost multipath (something that will never be possible over peers on the same interface), route failover and metric weighted routing than a routing process must get involved to make the routing decisions, populate the routing table and then manage entries in the "FIB" based upon the routing table. As it stands today there are not, at least not readily publicly available, any routing processes which can interact with WireGuard to do so. This is why today to do any sort of dynamic routing with wireguard the peers involved need to be assigned to different interfaces and allowed-ips on them set to 0.0.0.0/0 or the total subset of ip addresses which might ever traverse a peer under any routing situation. Existing routing processes can then just treat them as traditional interfaces and not worry about updating the "FIB". On Thu, Mar 15, 2018 at 2:39 PM, Steve Gilberd wrote: >> Allowed IPs is like a routing table; you can't have two routes for the >> same set of IPs > > If this is the case, then wireguard does not have proper routing support. > > Normally, routing tables allow both multiple and overlapping routes present. > When making routing decisions, the most-specific route is chosen (e.g. a /29 > is higher priority than a /24 which overlaps with it). If there are two > identical routes of the same size, then the one with the lowest routing > metric is used. > > I can understand not allowing identical routes of the same size, as > wireguard doesn't really have a concept of metric (although it could be > useful for backup links). However, it really should allow overlapping routes > of different sizes. There's no ambiguity with routing decisions, and it's a > standard feature that I would normally expect any IP routing stack to have. > > Cheers, > Steve > > > On Fri, 16 Mar 2018, 04:57 Samuel Holland, wrote: >> >> Hello, >> >> On 03/15/18 10:31, Gianluca Gabrielli wrote: >> > I was setting two peers on the server, but every time I re-add one of >> > these >> > two the other one is shown with (none) on "allowed ips" field. Of course >> > that >> > blocks communications with that peer. If I try to re-add it, then the >> > other >> > peer loses its configuration, same problem. >> >> Allowed IPs is like a routing table; you can't have two routes for the >> same set >> of IPs, or WireGuard doesn't know which peer to send the traffic to. You >> want to >> have non-overlapping Allowed IP ranges. This usually means that the range >> of >> Allowed IPs is smaller than the host's subnet. For example: >> >> Host A: >> IP configuration for WireGuard interface: 192.168.123.1/24 >> Allowed IPs for Host B: 192.168.123.2/32 >> >> Host B: >> IP configuration for WireGuard interface: 192.168.123.2/24 >> Allowed IPs for Host A: 192.168.123.1/32 >> >> The IP configuration tells the kernel which IP ranges are accessible via >> the >> WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of >> those IPs >> is associated with each peer. >> >> > Cheers, >> > Gianluca >> >> Cheers, >> Samuel >> ___ >> 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 > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Multiple peers
Another option instead of using the iptables rule is to create a network namespace and assign the wireguard interface to it. ip netns add mesh ip link add wg0 type wireguard ip link set wg0 netns mesh ip -n mesh addr add x.x.x.x/24 dev wg0 ip netns exec mesh wg setconf wg0 /etc/wireguard/wg0.conf ip -n mesh link set wg0 up I prefer this because it isolates any mesh network routing and firewall configuration from that of the physical interfaces of the hub server. You don't have to worry about a routing or firewall misconfiguration on the hub leading to the traffic from the vpn network going on to the hub server's underlying network. Also if you want to provide a service to the VPN network from the server you can run the process in the mesh network namespace or inside a container with only an interface in the mesh namespace available to it. On Tue, Mar 13, 2018 at 1:35 PM, wrote: > Hi Gianluca, > >> I wonder if I need to copy/paste all peers' public key on all the other >> peers' configuration, or I can just configure each peer to connect to the >> server and then allow peers talking with other peers passing through this >> server? > > If you want each peer to have a 1:1 connection to each other peer, then – > yes. But to maintain such a mesh will be quite a bit of work… > > The easier solution should be to use the server as a hub. Make sure the > AllowedIPs on the “clients” permit the subnet IP range you will be using, > e.g. 192.168.10.0/24. The “server's” setting for AllowedIPs for each peer > should reflect the single address (/32) you are setting as interface address > on the peer's side. > > To glue, add an iptables rule: > iptables -A FORWARD -i wg9 -o wg9 -j ACCEPT > > > Kind regards, > Peter > > ___ > 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: TCP Wireguard with socat
Glad you got it working with ssf. If you are still interested in getting it to work with socat, I have done so and it is pretty easy to do. On the server side of the connection: socat -d -d TCP-LISTEN:443,reuseaddr TUN:192.168.255.1/24,up On the client side: socat TCP:server_address:443 TUN:192.168.255.2/24,up This will create tunnel interfaces on each side which forwards any data flowing through them over a socat established TCP connection between the machines. Running 'ip link show' on either end will show the new tun interface. In your wireguard configuration set the server to listen on any port besides 443 since socat is using this port for the TCP connection. On the client side configure the endpoint for the server peer to be 192.168.255.1:server_listenport On Mon, Mar 12, 2018 at 11:14 AM, Gianluca Gabrielli wrote: > Yes, I can confirm now. Wireguard + ssf[1] (UDP forwarding) works very well. > I will proceed doing some benchmark to understand how much this solution is > downgrading performance. > > [1] https://github.com/securesocketfunneling/ssf > > Cheers, > Gianluca > > > ___ > 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
[PATCH] tools: fix removing preshared keys failing on some platforms
errno is checked following fread of the preshared key file. fread doesn't set
errno, so it shouldn't be checked. On the EdgeRouter ER-X when wg uses glibc
instead of musl libc this incorrect check causes removal of preshared keys to
fail. This patch removes the check of errno.
Signed-off-by: Tim Sedlmeyer
---
src/tools/config.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/tools/config.c b/src/tools/config.c
index 5ab6ece..0407b36 100644
--- a/src/tools/config.c
+++ b/src/tools/config.c
@@ -128,10 +128,6 @@ static bool parse_keyfile(uint8_t key[static WG_KEY_LEN],
const char *path)
}
if (fread(dst, WG_KEY_LEN_BASE64 - 1, 1, f) != 1) {
- if (errno) {
- perror("fread");
- goto out;
- }
/* If we're at the end and we didn't read anything, we're
/dev/null or an empty file. */
if (!ferror(f) && feof(f) && !ftell(f)) {
memset(key, 0, WG_KEY_LEN);
--
2.16.1
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
[PATCH] tools: fix removing preshared keys on some platforms
errno is checked following fread of the preshared key file. fread doesn't
set errno, so it shouldn't be checked. On the EdgeRouter ER-X when wg uses
glibc instead of musl libc this incorrect check causes removal of preshared
keys to fail. This patch removes the check of errno.
---
src/tools/config.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/tools/config.c b/src/tools/config.c
index 5ab6ece..0407b36 100644
--- a/src/tools/config.c
+++ b/src/tools/config.c
@@ -128,10 +128,6 @@ static bool parse_keyfile(uint8_t key[static
WG_KEY_LEN], const char *path)
}
if (fread(dst, WG_KEY_LEN_BASE64 - 1, 1, f) != 1) {
- if (errno) {
- perror("fread");
- goto out;
- }
/* If we're at the end and we didn't read anything, we're
/dev/null or an empty file. */
if (!ferror(f) && feof(f) && !ftell(f)) {
memset(key, 0, WG_KEY_LEN);
--
2.16.1
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Removing pre-shared key from peer using wg set fails
Jason, That fixed it. Thanks, Tim On Wed, Nov 22, 2017 at 7:20 PM Jason A. Donenfeld wrote: > Hi Tim, > > Thanks for letting me know. This is a tools regression from > 0.0.2017, which I just fixed, based on your report: > > > https://git.zx2c4.com/WireGuard/patch/?id=7153081da70006a8723474580543bd3223d1baf4 > > Let me know if this fixes the issue. It will be included in the next > snapshot. > > Regards, > Jason > ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Removing pre-shared key from peer using wg set fails
Removal of the preshared-key from a peer using the 'wg set' command and providing /dev/null or an empty file as the preshared-key filename does not result in the key being removed from the peer. The command doesn't return an error, but it also doesn't remove the key. I have attempted it using 0.0.2017 and 0.0.20171122. Supplying /dev/null or an empty file as the filename does work properly for removing the interface private-key. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
