Re: WireGuard roaming behind a load balancer
On 01/16/19 18:21, Ivan Labáth wrote: > In your setup, where H,A,B are wg nodes, and > (H)A - B > is switched to > (A)H - B I assume here A and H are the active/hot-spare pair, and B is the remote node. > B->HA traffic will be lost (considered junk) until either > > - B's timer expires and a B->H rekey is issued (maybe 10s of seconds?) To be precise, this timer is 120 seconds from the last successful handshake. > - H->B traffic and/or timer initiates a H->B rekey > > If HA can initate traffic to B, you may be able to rig a rekey soon, > with a <1s outage, or even lossless in some circumstances, but you are > going against the design of a host-to-host "stateless" vpn. H can immediately send handshakes to all peers when it is brought up (and will do so today if they have persistent keepalives set). But you need more than HA being able to initiate traffic to B. B could have roamed to a new IP while it was communicating with A. Then A would know about the new IP (because it received an authenticated packet from there), but H would not. So you need some way to stream endpoint updates between A and H. I'm not sure if WireGuard's netlink has a way to push endpoint changes (that would be nice), but you could at least poll netlink on the active host, and push netlink on the standby. You could also extend the netlink interface with a way for userspace to request a handshake on all peers. Then you could leave the interface up, and wouldn't need any persistent keepalives. > Real hot-standby HA VPNs with transparent lossless switching > on the HA side usually share their ephemeral keys. Sharing ephemeral keys would avoid the need for a new handshake at failover, but that is very little benefit, since handshakes happen every couple of minutes anyway. More importantly, sharing keys comes with the security risk of sending your most sensitive data over the network. Anyone with those keys can decrypt VPN traffic in real time. Plus you *still* need the updated endpoint information to send packets from H to B before B sends anything to AH, even if the session key is still valid. So I highly recommend against attempting to extract the ephemeral keys from the kernel. > Regards, > Ivan Cheers, Samuel ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WireGuard roaming behind a load balancer
Hi, Wireguard isn't completely stateless. It has connections and state, even though it is comparably small and transient. Wireguard roaming supports changing IPs. An authenticated packet updates the ip and all works well. Changing hosts requires a rekey (to re-establish transient keys), and that won't be automatically triggered by unauthenticated gibberish, so plain switching won't work immediately. If you don't mind a relatively short outage when switching, it should work fine. In your setup, where H,A,B are wg nodes, and (H)A - B is switched to (A)H - B B->HA traffic will be lost (considered junk) until either - B's timer expires and a B->H rekey is issued (maybe 10s of seconds?) - H->B traffic and/or timer initiates a H->B rekey If HA can initate traffic to B, you may be able to rig a rekey soon, with a <1s outage, or even lossless in some circumstances, but you are going against the design of a host-to-host "stateless" vpn. Real hot-standby HA VPNs with transparent lossless switching on the HA side usually share their ephemeral keys. Regards, Ivan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Cannot compile Noise.c on Kernel 5.0?
On Wednesday, January 16, 2019 5:37 PM, Sam Cater wrote: > Hi Wireguard Mailing List, > > Probably going to be showing a lot of ignorance here! > > Wireguard has run fine on this system in the past, but today I tried to > build 20181218 on self-built 5.0 kernel (which in and of itself seems > stable and working fine). The compile fails on src/noise.o with the > issue linked below on line 453. > > If I switch back to the stock 4.19 kernel provided by Fedora then > everything compiles fine. It's also worth mentioning that the same issue > appears to happen when I install the COPR packages for Fedora. > > Appreciate I'm a non-standard kernel but just in case it is a Linux 5 > incompatibility rather than "I can't build software", I thought I'd post > here in case it was helpful. > > Mini paste at: https://pastebin.com/raw/W4LRT5bx For Linux 5.0 you need to use wireguard snapshot from git: https://git.zx2c4.com/WireGuard/log/ The error you posted was fixed by: https://git.zx2c4.com/WireGuard/commit/?id=a56a0fee861d104b9bdb22847656fc40a9b13079 Later in build there will be another error fixed by: https://git.zx2c4.com/WireGuard/commit/?id=eb8316abc24da2e38de65d88c519aa8dfd6227f4 Jordan ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Optional DNS-Check or Ping-test for the Android App
On Wed, Jan 16, 2019 at 1:29 PM Fabian Schwamborn < fab...@familie-schwamborn.com> wrote: > I think you misunderstood me. Most broadband providers don't offer fixed > IPv4. Due to privacy considerations, even under IPv6 on normal connections, > addresses will always change. (prefix) As soon as an address changes and my > dynamic DNS system registers it, an IPsec or OpenVPN client on my phone can > reconnect. (This happens once a week). > The Wireguard app simply lacks a monitor to see if the IP address has > changed. Therefore a ttl in the DNS was introduced (After a registered > loss of the connection - also shown in the log - no DNS request is executed > and the tunnel breaks down permanently.) > > I think the > Yes, I thought you were asking for what you already have setup. My apologies. > se are the most common scenarios with OpenWRT routers ... > > Having a DNS entry does not mean that it always points to a static ip, so > when a tunnel disconnects, the Android-app itself (userspace) should handle > this like many other existing VPN-Clients do by a re-query of the DNS > entry... > > My question is, is there any opinion on such an implementation? Should i > try to implement it into the android app and provide the code? > (Unfortunately i am not a good android app-developer) > This sounds like something the wg-go userspace should support, not the android or ios app ui. > > Am 16.01.2019 um 21:57 schrieb David Cowden: > > You need to setup dns for your home site then use that to connect. Or you > need to synchronize the endpoint out of band. I can't imagine this is > something wg wants to tackle--this is a general problem all software > encounters. > > On Tue, Jan 15, 2019 at 10:52 PM Fabian Schwamborn < > fab...@familie-schwamborn.com> wrote: > >> Hello, >> >> >> >> I have a suggestion for improving the Android app or would like to ask if >> such a change would be desirable in general (e.g. pull request): >> >> I'm using Wireguard as a connection between my home router and my mobile >> phone, but unfortunately I don't have a fixed IP address. As soon as the IP >> address changes, the app does not reconnect. (Happens once a week) >> >> Is it possible to integrate a function into the app, that pings through >> the tunnel so that you can perform a keep-alive check and reconnect the >> tunnel completely after a failure (including DNS request)? >> >> Is it conceivable, to implement a DNS-check function in the app? (E.g. >> like the existing example DNS check script for Linux works?) >> >> Then the app would have the same functionality as my previous IP-Sec >> client. This would also allow better coverage of failover IP scenarios. >> >> >> Best Regards >> >> Fabian >> ___ >> 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: Logging remote connecting IP
On Wed, Jan 16, 2019 at 10:52:48AM -0500, John wrote: > > For auditing purposes, I would like to be able to log the remote > > endpoint IP for each wg connection on the server side. What's the best > > way to do this, preferably using syslog? > > Enable the debug option when building should print to dmesg. That's good to know, but not very useful in our case, because we get the module from Fedora COPR. Moreover, I'd consider ability to log incoming connections info-level, not debug-level logging. -K ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
WireGuard roaming behind a load balancer
Greetings, WireGuard is a really cool project! Thanks! With WireGuard's native roaming support, I have a question about just how stateful/stateless the roaming is. Here's a hypothetical situation: Let's say WireGuard is being used to tunnel into a location and is served behind a load balancer for high availability. If both nodes have identical WireGuard config files at the start of WireGuard (and, for simplicity, let's assume the configurations don't change). If one node dies, the load balancer will automatically start sending packets to the standby node running WireGuard (perhaps existing on the same subnet as the other node, but with a different IP). In a sense, the server-side "peer" has just roamed from machine to another, but the public/Internet IP address didn't change (because that is assigned to the load balancer itself). Will this work with WireGuard today? TIA ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Cannot compile Noise.c on Kernel 5.0?
Hi Wireguard Mailing List, Probably going to be showing a lot of ignorance here! Wireguard has run fine on this system in the past, but today I tried to build 20181218 on self-built 5.0 kernel (which in and of itself seems stable and working fine). The compile fails on src/noise.o with the issue linked below on line 453. If I switch back to the stock 4.19 kernel provided by Fedora then everything compiles fine. It's also worth mentioning that the same issue appears to happen when I install the COPR packages for Fedora. Appreciate I'm a non-standard kernel but just in case it is a Linux 5 incompatibility rather than "I can't build software", I thought I'd post here in case it was helpful. Mini paste at: https://pastebin.com/raw/W4LRT5bx ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wireguard-go as a library
Hello, I am from Mysterium Network project team. We are open source dVPN project. Currently we use OpenVPN as our VPN transport, but started works to integrate WG too. Since we try to support all major OSes we would like to use wireguard-go for win, ios, darwin and android. Currently this project does not fit to be used as a library. We would like to contribute to this project, making it a bit more friendly to be used as a library. Would you accept such contributions or it is meant to be as a standalone binary type project? Is there any contribution guidelines for such improvements? Would it be ok if we would make a pull request in a github? This way all details regarding proposed code could be worked out. best regards, Antanas Mysterium Network ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wireguard: Adding an interface name filter for Android?
Hi,
I've been using WireGuard on my Laptop for months and I've just got to
try it on my Android device with kernel support just now.
I've just noticed that Android's ndc doesn't take it nicely when the
interface name has a period on it. I'm not sure whether this is a
known issue, but it seems to be a good idea to add a name filter for
Android. I'm guessing that some other symbols would be also
problematic.
Here's a terminal log I manually captured after running wg-quick
myself as the logcat didn't indicate much:
OnePlus6:/data/data/com.wireguard.android # ./cache/bin/wg-quick up
arter97.com
[#] ip link add arter97.com type wireguard
[#] wg setconf arter97.com /proc/self/fd/0
[#] ip link set up dev arter97.com
[#] ip6tables -I INPUT 1 -p udp --dport * -j DROP -m comment
--comment "wireguard rule arter97.com"
[#] ip link set down dev arter97.com
[#] ndc interface setcfg arter97.com '192.168.2.8' 32
[#] wg set arter97.com fwmark 0x2
[#] iptables -I OUTPUT 1 -m mark --mark 0x2 -j ACCEPT -m comment
--comment "wireguard rule arter97.com"
[#] ip6tables -I OUTPUT 1 -m mark --mark 0x2 -j ACCEPT -m comment
--comment "wireguard rule arter97.com"
[#] ndc interface setcfg arter97.com up
[#] ndc network create 20968 vpn 1 1
[#] ndc network interface add 20968 arter97.com
[#] ndc resolver setnetdns 20968 '' '1.1.1.1'
[#] ndc network route add 20968 arter97.com 0.0.0.0/0
[#] ndc interface setmtu arter97.com 1370
Error: 400 0 Failed to set MTU (No such file or directory)
[#] iptables -D OUTPUT -m mark --mark 0x2 -j ACCEPT -m comment
--comment "wireguard rule arter97.com"
[#] ip6tables -D OUTPUT -m mark --mark 0x2 -j ACCEPT -m comment
--comment "wireguard rule arter97.com"
[#] ip link del arter97.com
[#] ndc network destroy 20968
64|OnePlus6:/data/data/com.wireguard.android #
OnePlus6:/data/data/com.wireguard.android # ./cache/bin/wg-quick up
arter97
[#] ip link add arter97 type wireguard
[#] wg setconf arter97 /proc/self/fd/0
[#] ip link set up dev arter97
[#] ip6tables -I INPUT 1 -p udp --dport * -j DROP -m comment
--comment "wireguard rule arter97"
[#] ip link set down dev arter97
[#] ndc interface setcfg arter97 '192.168.2.8' 32
[#] wg set arter97 fwmark 0x2
[#] iptables -I OUTPUT 1 -m mark --mark 0x2 -j ACCEPT -m comment
--comment "wireguard rule arter97"
[#] ip6tables -I OUTPUT 1 -m mark --mark 0x2 -j ACCEPT -m comment
--comment "wireguard rule arter97"
[#] ndc interface setcfg arter97 up
[#] ndc network create 4402 vpn 1 1
[#] ndc network interface add 4402 arter97
[#] ndc resolver setnetdns 4402 '' '1.1.1.1'
[#] ndc network route add 4402 arter97 0.0.0.0/0
[#] ndc interface setmtu arter97 1370
[#] ndc network users add 4402 0-9
[#] am broadcast -a com.wireguard.android.action.REFRESH_TUNNEL_STATES
com.wireguard.android
Broadcasting: Intent {
act=com.wireguard.android.action.REFRESH_TUNNEL_STATES
pkg=com.wireguard.android }
Broadcast completed: result=0
Thanks,
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WireGuard deployment considerations for improved privacy
Hi Fredrik, I appreciate this proposition as well as your summary for the current state of Wireguard for this particular case. I agree with you wholeheartedly that before the mass adoption of Wireguard happens these use cases should be addressed properly. I'd love to hear what Jason has to say about this and what he proposes. I too have been thinking about all the edge cases for Wireguard. My approach has been to look at it from a penetration test perspective. Reality is that Wireguard doesn't live in isolation. As a system - hardware, OS and all it's settings + Wireguard - connected to the Internet and a user(s) presents many hostile dynamics. Ultimately, whatever solution emerges needs to supplement the goals and features of Wireguard, otherwise it deafts the purpose. Would it make sense to create a small group to tackle this and other use cases - scaling, simplicity, etc? On my end, I'm not a cryptologist, but I can write software that would test the security of any system. I'm sure other members of this list have a ton of skills and experience to bring to this. Here's a list of things I'd like to see and would be willing to participate/create if they don't exist yet: 1. A honeypot server with public logs for a small team to gather and record real-time traffic as an authorized user of the server - root.2. A test suite that goes through all the domain specific scenarios from the results of #1 and provides a verification at the end once completed.3. Provide feedback from all this back to Jason for enhancements, etc. in upstream Wireguard. Feel free to reach out off-list. Thanks,Jose On Tuesday, January 15, 2019, 9:27 AM, Fredrik Strömberg wrote: On Tue, Jan 15, 2019 at 1:05 PM Henning Reich wrote: > > Thank for your reply too, > > I "use" this list and conversation to get a bit more information about crypto > at all (it looks like I need that :-) > I see. When I wanted to learn more about network security protocols I read the RFC for TLS from start to finish a few times. Every time I didn't understand a word or concept I looked it up on Wikipedia, often reading the entire article on that concept. In your case maybe read the WireGuard paper a few times and reference Wikipedia. That's a good start. > I try to explain how I understood the problem, and anybdoy can tell me, where > I have make a mistake :-) > From https://www.wireguard.com/protocol/#key-exchange-and-data-packets > the initiation message and the response use > initiator.ephemeral_private = DH_GENERATE() and > responder.ephemeral_private = DH_GENERATE() > Correct. Although to be exact DH-Generate returns a keypair (private, public). > This means (I think), that for every new connection, a new DH-Key is > generated. For me (not a programmer) it looks like all other private > informations in the messages a encrypted/hashed with values derived from this > DH-Key. Almost. It uses Diffie-Hellman with the ephemeral private key as one component. In the first message, msg.static is encrypted using a key derived from DH of the Initiator's ephemeral private key, and the Responder's static public key (which is already known to Initiator). The first message also includes the field msg.ephemeral which contains the Initiator's ephemeral public key, transmitted in the clear. When the message is received by the Responder, she is able to decrypt msg.static and learn the Initiator's static public key. You might ask how that is possible when she doesn't have the Initiator's ephemeral private key. The reason is that she can derive the correct encryption key using the Initiator's ephemeral public key, previously transmitted in the clear, and her (the Responder) static private key. ECDH ( Initiator's ephemeral private key, Responder's static pubkey ) = ECDH ( Initiator's ephemeral public key, Responder's static private key ) > Because both site knows the other static key, I would look in the "XX" Row, > and there is your quoted destination proberty not exisintg. > WireGuard uses Noise_IK, not Noise_XX. > It's probably possible that I ignore some cryptographic basics or > misunderstood same facts. So I hope somebody takes the time and give me some > more hints. Thanks > No worries. We're all learning something. If you want to learn more about cryptographic protocols just put in the time. And when you don't understand something, or suspect that you are wrong, read the whole thing again. That's what I did :) Cheers, Fredrik ___ 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
Logging remote connecting IP
Hello: For auditing purposes, I would like to be able to log the remote endpoint IP for each wg connection on the server side. What's the best way to do this, preferably using syslog? Best, -K ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
