Re: IPv6 endpoint AND IPv4 fallback endpoint in roadwarrior scenario?
What happens if the DNS-lookup fails (e.g broken or manipulated DNS)? In my opinion it should be possible to work with static IPv6 addresses and fall back to static IPv4 addresses. Regards, Renne Am 29.09.19 um 21:31 schrieb Henning Reich: Should a DNS entry Wirth one record and one A record solve thus problem? So the OS decide the best way to connect? Ulrich Kalloch mailto:u...@noc23.de>> schrieb am So., 29. Sep. 2019, 16:29: Hello @ all i am interested in this too. Regards Ulli Am 27.05.19 um 20:10 schrieb Rene 'Renne' Bartsch, B.Sc. Informatics: > Hi, > > is it meanwhile possible to define an IPv6 endpoint AND and an IPv4 > endpoint as fallback > in case a road warrior does not get IPv6 connectivity when switching > internet sockets? > > Regards, > > Renne > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com <mailto:WireGuard@lists.zx2c4.com> > https://lists.zx2c4.com/mailman/listinfo/wireguard ___ WireGuard mailing list WireGuard@lists.zx2c4.com <mailto: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: Adding 2FA to WireGuard
Hi Rèmi,
I suggested to use use FIDO2/CTAP2 hardware tokens about a week ago.
For in-band signaling I suggest to use OrchidV2 addresses derived from
the public key (https://www.rfc-editor.org/rfc/pdfrfc/rfc7343.txt.pdf).
That way any peer can calculate the addresses of the other peers from
their public keys without the need of a lookup table.
Regards,
Renne
Am 12.09.19 um 23:01 schrieb Rémi Lapeyre:
Hi everybody! We are using WireeGuard on Mac and Linux which works
great but for
compliance purpose, we would like to be able to add an OTP challenge
on connection.
I've been looking at the archive of the mailing list and at the
various projects
built around WireGuard and started writing an implementation based on
the idea
from
https://lists.zx2c4.com/pipermail/wireguard/2017-September/001741.html:
> Alternatively, you could do OTP in-band, in order to authorize that
> public key for a certain window of time before inactivity. In this
> scheme, you'd disallow access to the network segment based on firewall
> rules until a certain in-band challenge is made -- perhaps by
> contacting a certain sandboxed server and answering an OTP challenge
> there
My current implementation (I plan to publish it under MIT license once
it's
ready) has a Python server on the WireGuard server bound to the wg
interface
that add an IPTable rule to allow the traffic for a given amount of
time when
a TOTP is received over TCP. Here are some details
- The TOTP is bound to the internal tunnel IP address so the IP
address that
opens the TCP connection is used to identify the user, as thee
packet must
have been decrypted, it seems to me that there is no way to spoof this.
- A small text protocol let the user log-in, log-out and read the
status of the
connection.
The client needs to send the TOTP just after connecting to the server,
for which
I had hoped to use the "PostUp" field of wg-quick.
{Post,Pre}-{Up,Down} seems to be only available on wg-quick for now
but we are
using the wireguard-apple client so I have a few questions:
1. Is the absence of support {Post,Pre}-{Up,Down} in wireguard-apple on
purpose or would a patch to add this welcomed?
2. Is this way to do the OTP authentication sound?
3. I've seen that TunSafe has added an extension to the WireGuard
protocol so
the TOTP auth would not be shared by an attacker that succeded to
connect when
the user is already connected. This seems like a good idea to do,
what are your
thougts about this? Would you recommend against my "easier"
implementation?
4. I know that TunSafe was strongly advised against when it was
closed-source.
Now that it is AGPL code, is it still the case?
One more thing, to simplify the deployment of WireGuard, I would like
to propose
a change in the way the MacOS client import WireGuard configurations
from a file.
Our current flow is "Please open the WireGuard app, click on create
Tunnel, give
it a name, paste this configuration underneath what's already written,
hit save
and send us your public key". It gives a lot of oportunity to the user to
mistype something and make changing the configuration cumbersome
("Edit the
tunnel, don't touch the `[Interface]` part but replace what's
underneath by
this") so I would like to be able to send to the user a configuration
file with
the PrivateKey missing and have the WireGuard client generate one on
the fly but
this currently gives an error "Interface’s private key is required". Would
sending a patch for this be welcomed too?
Thanks for taking the time to help me, I look forward to contribute to
WireGuard :)
Rémi
___
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: Support FIDO2/CTAP2 security tokens as keystore
Am 18.08.19 um 19:09 schrieb Reto: For starters, storing stuff on a hard disc is certainly not "quite insecure". Are you aware that you can encrypt discs / partions / files? Anyone with access to the running machine or malicious software can read the keys on hard-disk. How do you de-crypt the encrypted disk on a headless machine which has to reboot autonomously on error conditions? Wireguard also allows you to set the private key on the fly, so you can feed it for example secrets stored in pass (gpg encrypted), which you *can* decrypt with a yubikey already. Are you speaking specifically about wg-quick? In that case the manpage already shows you how to feed wg encrypted secrets Or, perhaps it is desirable to store private keys in encrypted form, such as through use of pass(1): PostUp = wg set %i private-key <(pass WireGuard/private-keys/%i The point of security-tokens is you never get access to the private key. Instead you pass the stream-cipher encrypted with the public key to the security token to be de-crypted by the security token. Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Support FIDO2/CTAP2 security tokens as keystore
Hi, currently the private key ist stored on HDD which is quite insecure. I suggest to support FIDO2/CTAP2 security tokens as keystore (see https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol). Have Phun, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
Hi Lonnie, I agree. If a peer could push updated information of a remote peer (e.g. ip address, port) to all other peers it would be great, too. Regards, Renne Am 09.06.19 um 21:59 schrieb Lonnie Abelbeck: Hi List, Request For Comments: I would find it useful if "wg" would support a "syncpeers" subcommand. -- Usage: wg syncpeers -- Available subcommands: syncpeers: Synchronizes a configuration file of peers to a WireGuard interface -- Given: - A user creates a wireguard.conf file. - Uses "wg setconf wg0 wireguard.conf" to apply the configuration. Request: - Later, a user edits a wireguard.conf file: adds peers, deletes peers, and/or edits peers. - Use "wg syncpeers wg0 wireguard.conf" to synchronize the configuration file of peers with the current state. - Synchronize changes with minimal impact, determine peer differences and leave unchanged settings alone. - Basically internally using "wg set wg0 ..." to make the minimum changes. - If the [Peer] Endpoint is a DNS hostname, the Endpoint will be resolved and IP updated. Note: Interestingly, "wg setconf wg0 wireguard.conf" *almost* performs as requested except for a 17 second interruption of the tunnel *if* PersistentKeepalive is 0. Even if PersistentKeepalive is 3600, a "wg setconf wg0 wireguard.conf" will not effect an active tunnel except for resetting traffic counters. I understand a script could be created to perform this as well, but adding it to "wg" lowers the hurdle for many users. If the 17 second interruption of active tunnels while using "wg setconf wg0 wireguard.conf" could be eliminated, this request may be moot. Comments please. 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
IPv6 endpoint AND IPv4 fallback endpoint in roadwarrior scenario?
Hi, is it meanwhile possible to define an IPv6 endpoint AND and an IPv4 endpoint as fallback in case a road warrior does not get IPv6 connectivity when switching internet sockets? Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wg-quick: Add ORCHIDv2 address for in-band management
Orchidv2 IETF RFC 7343: https://tools.ietf.org/pdf/rfc7343 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Add Wireguard to Linux staging tree
Hi, it seems activities adding Wireguard to the Linux kernel have stopped because of lack of audits and cryptographic weakness tests. I suggest to offer adding Zinc/Wireguard to the Linux kernel staging tree to make it easily available for testing and auditing. Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wg-quick: Add ORCHIDv2 address for in-band management
Hi, I suggest to extend wg-quick with functions to add an ORCHIDv2 address derived from the public key for in-band managment purposes (e.g. DHCPv6 relays, peer list exchange, ...). Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard
Am 30.01.19 um 16:46 schrieb Gawen ARAB: Hey Rene, > I suggest to use a cryptographically generated IPv6 address (128-bit hash of Wiregurad public key with first n bits replaced by a Wireguard-specific IPv6 prefix) > for routing and management purposes. Adding a reverse-lookup IPv6-address -> Wireguard public key via DHT would allow a public IPv6 overlay network > with authorization via firewall rules. Nodes should also be able to announce their subnets via DHT. I agree. I plan to use the subnet ORCHID as defined by RFC 4843. See command `wh orchid`. Great! :-) RFC 4843 has been obsoleted by RFC 7343. Please use RFC 7343 instead and re-use as much cryptographic code of Wireguard as possible to reduce possible bugs and weaknesses. I suggest to omit the custom UDP protocol and libpcap by adding an ORCHIDv2 address to the wireguard network device and run the DHT via a port of the ORCHIDv2 address. That way you can easily calculate the ORCHIDv2 address of a peer from the public key and connect the DHT. Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard
Am 30.01.19 um 00:55 schrieb Steve Gilberd: I very much like the idea of this project - I've been looking for a decent full-mesh L3 VPN for ages, and have never found a solution I've been properly happy with. Thanks for your work in developing this solution :-). Me, too - Thanks! :-) However - I'm concerned about some of the potential increased attack surface that your architecture introduces: - uses extra crypto functionality which is not already part of wireguard; and - passes messages across public networks using that functionality; and - clamps the wireguard keys in some unspecified way to embed a proof-of-work (in fairness, I haven't read the code, so please correct me if I have misunderstood). For what it's worth, if it would be possible to also encapsulate your control protocol inside wireguard, that would be vastly preferable: it allows the transport cryptography to be implemented in one place, once (i.e. in wireguard), and lets wirehub be a purely organisational overlay for managing links, rather than touching the crypto and introducing troubling extra complexities. I agree. Piggybacking Wirehub communication on Wireguard encryption instead of custom UDP saves an additional layer of encryption an thus superfluous code. Wirehub should only use ZINC functions to sign/validate the DHT entries with the Wireguard private/public key. I suggest to use a cryptographically generated IPv6 address (128-bit hash of Wiregurad public key with first n bits replaced by a Wireguard-specific IPv6 prefix) for routing and management purposes. Adding a reverse-lookup IPv6-address -> Wireguard public key via DHT would allow a public IPv6 overlay network with authorization via firewall rules. Nodes should also be able to announce their subnets via DHT. I would also love to see some sort of PKI option with this project, to avoid having to explicitly trust all the peers. I'd prefer to be able to simply provide the peers with a signature they can present to other peers that proves they can be trusted (or even better, have that signature generated by a nominated host at connect / setup time for each peer, which avoids much of the shenanigans involved with handling expiry, revocations etc.) Having the ability to tell all peers on the network to immediately terminate all connections with a specific compromised peer would also be handy. A PKI increases complexity a lot. I suggest using the cryptographically generated IPv6 address approach with distributed firewall rules. Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wg-quick: Add option TableDefaultGW
Hi, We're in the situation in which we want to use the default routing table but need another routing table for a policy-based routing of public static IP-Adresses with a wireguard default gateway in the VPN. "Table " is no option as it would create all routes in the new table. My current idea is to use PostUp = wg set %i peer allowed-ips ::/0, 0.0.0.0/0 PostUp = ip -4 route add default dev %i table " PostUp = ip -6 route add default dev %i table " PreDown = ip -4 route del default dev %i table " PreDown = ip -6 route del default dev %i table " and use "ip rule"-statements in PostUp/PreDown. To simplify such a VPN setup with a default gateway I suggest a wg-quick option "TableDefaultGW " which adds a routing table for the default gateway only. Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Android and Manjaro road warriors behind dynamic IP addresses/Carrier Grade NAT?
Hi Markus, that's what I thought about, too. It means to add another authentication system (SSH) and fiddle around on Android smartphones. Is there any way for Wireguard peers with static IP addresses to push endpoint information of all connected peers to all other peers? Or at least a hook which allows to dump changing endpoints into a file in real-time? The optimal solution would be to integrate something like https://github.com/manuels/wireguard-p2p (DHT + hole punching techniques) into Wireguard itself. Addressing by public keys and resolving IP-addresses/ports by a DHT would even make Wireguard John-Doe-compatible. ;-) Regards, Renne Am 29.12.18 um 13:53 schrieb Markus Grundmann: Hi Renne, for this reason I use a jump server based on SSH in the middle of the nodes. [authorized_keys] no-port-forwarding,no-X11-forwarding,command="~/bin/poll .my-ip ; cat ~/.remote-ip" ssh-rsa B3N ... After you have received the IP addresses you can use "wg" to set the new endpoint address on both nodes. The small script named "/bin/poll" uses the environment variables of SSH to wrote the current IP into a file. Best regards, Markus On 29.12.18 13:16, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: Hi, we have Android and Manjaro road warriors which are often behind internet sockets with dynamic IP addresses AND Carrier Grade NAT. Does anyone know a trick how to initiate a direct Wireguard connection between to road warriors without knowing their endpoint IP addresses/ports? Regards, Renne ___ 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
Android and Manjaro road warriors behind dynamic IP addresses/Carrier Grade NAT?
Hi, we have Android and Manjaro road warriors which are often behind internet sockets with dynamic IP addresses AND Carrier Grade NAT. Does anyone know a trick how to initiate a direct Wireguard connection between to road warriors without knowing their endpoint IP addresses/ports? Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wg-quick: Read private key from file?
Hi, does wg-quick allow to read the private key from a file instead of a .conf-file? Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Behaviour of multiple Allowed-IPs 0.0.0.0/0 or ::0/0?
Hi, how does Wireguard behave with multiple peers with Allowed-IPs 0.0.0.0/0 or ::0/0? Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wg-quick: Separate files for interface and peer definitions?
Hi, we want to distribute the same file with peer definitions to all Wireguard peers. Is there any way in wg-quick to use one configuration file for the interface definition and another file for the definition of peers? Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
DHT suggestion (was: Both peers behind NAT?)
I suggest to extend the roaming messages after the following scheme: :<64-bit linux timestamp>:<128-bit current IPv4|IPv6 address>:<16-bit current UDP port>: When peerA gets a new address or port it sends a roaming message to directly connected peers B, C, D which store the roaming packet of peerA in their DHT table. When peerE which is connected to peerB and peerC wants to contact peerA it sends a query to the other peers (B, C). If they can't reply with a current roaming package, they forward the query to peerD. PeerE receives roaming packages for peerA from other peers, validates the signature and uses the IP address and UDP port of the most current received roaming message to contact peerA. This way users/admins/operators only need to know the public key of peering partners and do not have to know IP addresses or UDP ports or fiddle around with annoying DynDNS configurations or DynDNS-services. Best regards, Renne Am 29.11.18 um 09:00 schrieb Rene 'Renne' Bartsch, B.Sc. Informatics: Hi, I'm new to the list, so a "Hello" to all! :-) Are there any plans to implement a DHT-based solution for IP-address/port provisioning like https://github.com/manuels/wireguard-p2p? In case of static IP-addresses configuration is also simplified as you don't have to fiddle around with IP-addresses. If peers announce their subnets via DHT, it would allow to set up overlay networks easily. Regards, Renne ___ 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
Both peers behind NAT?
Hi, I'm new to the list, so a "Hello" to all! :-) Are there any plans to implement a DHT-based solution for IP-address/port provisioning like https://github.com/manuels/wireguard-p2p? In case of static IP-addresses configuration is also simplified as you don't have to fiddle around with IP-addresses. If peers announce their subnets via DHT, it would allow to set up overlay networks easily. Regards, Renne ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
