“The WireGuard private key is stored in the memory of the Pritunl client background service and also in the WireGuard configuration file. WireGuard uses a connection-less design and this private key could be used by an attacker to hijack the connection even if multi-factor authentication is used. In high security environments it is important to consider that OpenVPN connections with multi-factor authentication will not have these weaknesses. For this reason the server will quickly revoke WireGuard keys of inactive clients to limit the possibility of this occurring”
Does anyone know how others like Tailscale address this issue?
I am not familiar with pritunl, but it should not be necessary to keep the private key in a file. It is possible to configure wireguard directly with code [1] without calling the wg binary manually as pritunl seems to be doing [2].
I think I’m more worried about the lifecycle of that key. Pritunl issues new keys all the time. What does Tailscale etc do?
Because these keys aren’t the short life, in-memory session keys[1], but auth keys. Knowing this single key effectively bypasses any MFA you may have.
Seems like Tailscale has 180 days by default[2], which feels a bit too long for a person who expects MFA to be more proactive than this. Sure you can change the default to 1 day, but how many users know it’s possible or would even think to change that?
Compare that with OpenVPN where you can force every single auth attempt to use a password plus TOTP code for instance.
When Wireguard was 1st rolled out the smaller code base vs OpenVPN was touted as a feature. Now that 3rd party systems are available to bring feature parity with OpenVPN, it would be interesting to see a comparison of the size of the code base inclusive of these 3rd party systems. Not interesting enough for me to put forth the effort to do it but still interesting.
OpenVPN doesn't have awesome credential management baked in and the core networking code is an order of magnitude more complex, which is why the performance sucks compared to wireguard.
While not totally awesome, OpenVPN is miles beyond Wireguard when it comes to credential management. There are several auth plugins, you can use "the usual stuff" like PAM, and through that LDAP/Kerberos, ActiveDirectory, RADIUS, etc.. For higher security demands, client certificates are also possible and standardized X.509, PKCS#11/15 like CaC, Yubikeys and usual employee ID cards work. Also, OpenVPN supports at least some form of IP assignment and DNS/Route management.
Wireguard has none of that, not even the notion of a user. There are just keys in a special (unsupported by anything else) format that are assigned an IP address statically in a file. Oh, and the frigging software writes into that config file if you change anything.
Wireguard is a nightmare for any attempt at sane system administration.
“Wireguard is a nightmare for any attempt at sane system administration.”
It’s quite simple really: WireGuard is a building block. TFA mentions several systems built on top of WireGuard, that enables sophisticated handling of users/roles, authentication, ACLs, etc.
The problem with the building block approach is that it usually compromises any supposed security advantages Wireguard may have. You get a supersecure bank safe where the key is handed to you in the baker's shop opposite if you ask nicely.
However, the system on top of WireGuard cannot just spit out a key to the user and call it a day.
The key (sorry…) is to make the system a) verify the identity of the users via an IdP (e.g. Okta or something similar) and then b) distribute short-lived keys, that can be revoked.
If one reads how Tailscale handles user authentication and key rotation, one will notice that they have a solid system in place for handling the keys and the product is much more sophisticated than OpenVPN.
I haven’t studied the approach of their competitors (e.g. Firezone) so I can’t comment on that.
OpenVPN is simply bad at networking irrespective of any security considerations. (Wireguard, AFAICT, does the right thing with regard to MTU and is much simpler as a result. OpenVPN seems to go out of its way to be wrong.)
The feature parity I'm waiting for is L2 VPNs. Wireguard is strictly L3-only, and so far all I've seen are some custom hacks to tunnel L2 ethernet frames over wg.
Wireguard is L3 encryption. It's great because it's simple. Linus called it poetry. If you are bridging L2 over the Internet, then one way or another you're stuffing Ethernet frames into IP packets. Linux has built in L2 tunneling, sans encryption. I wouldn't call it a custom hack to open an L2 tunnel over wireguard. It's a one liner on each end. A configuration utility like wg-quick could be made to set it up for you. I wouldn't want wireguard to become OpenVPN.
> I wouldn't call it a custom hack to open an L2 tunnel over wireguard
There's too many headers that are too big. If you do a simple L2 tunnel, you have three options: jumbo frames, packet fragmentation, or custom hacks. None are great.
> Linux has built in L2 tunneling, sans encryption
IIRC, because the extra header for the encryption layer pushes the MTU over 1500.
Regardless of the technology, there is no way to put an 1518 byte Ethernet frame in a 1500 byte IP packet. You're going to have to fragment or live with reduced MTU inside the tunnel.
I'm using that in production with Babel (managing dynamic routes) with great success. Tinc had been solid for us for years, but once I actually payed attention to the performance hit, it was worth a bit of hassle to make it work over wireguard.
First, even with third-party code, WireGuard is going to be significantly smaller than OpenVPN (and significantly easier to audit).
But more importantly, you can't just count lines of code as if they're all equivalent. There's a trusted core of code that is more important than the rest of the code, and WireGuard's trusted code is microscopic compared to OpenVPN. That's the right word in this case: "microscopic". It's some of the easiest code in the whole kernel to read, even given the cryptography.
Yes, there is plenty of evidence for this; see for instance the WireGuard paper. Numerous code size comparisons have been done here.
Further, that is not what the WireGuard paper concludes. For instance: the paper makes a note of the fact that WireGuard is designed to be implemented without dynamic memory allocation, which is not a function of lines of code (in fact, it probably adds lines of code).
You do you, but as a practitioner in this space, I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice. You might disagree, but I think you'd be in the minority of security engineers on the point. Feel free to ask around! The codebases for OpenVPN and the IPSECs are reviled.
Plenty of code size comparisons with Wireguard and 3rd party apps providing feature parity with OpenVPN? Can you provide some links?
The Wireguard paper makes notes of many things including the lines of code needed to implement.
"I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice."
Life is complicated and those type of concerns are almost always in play which means OpenVPN and IPsec are also always in play. Wireguard is great where it is a fit but there are characteristics of Wireguard which also make it the more complicated and fragile solution in some circumstances.
I never asked that! I said it would be interesting to see how the line count of Wireguard and the 3rd party software needed to bring it in feature parity with OpenVPN compared with OpenVPN since the line count of Wireguard by itself is touted as an advantage.
What hand waving and moving of goalposts it that? All I stated was that it would be interesting to see a comparison of line count of Wireguard and the 3rd party tools needed to bring it into feature parity with OpenVPN to the line count of OpenVPN. My above comment just asked for references to studies doing just that which the comment I was responding to claimed to exist.
- Logging of peer IPs when they initially connect or change (yes, you can do this with module flags, but it should come out of the box).
- Tieing WireGuard private keys to a source IP. As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect.
- More control over DNS resolution for endpoints. I want WireGuard to periodically refresh the endpoint IP when I change networks, for instance.
Split DNS, where WireGuard may resolve an endpoint differently on a LAN vs internet. Also for IPv4/IPv6 roaming--if WireGuard resolves an IPv6 address but moves to a non IPv6 network, the peer will never connect as far as I know.
I see this when my equipment roams back into my private network and the wireguard server is inside that LAN. It can be solved by NAT'ing packets arriving on your edge router's inside interface, destinated to your outside IP, back to the inside wireguard server IP.
wrt the IP not being enforced, do you mean different endpoints can require different IPs, or a client can connect to an endpoint with a different IP configured and it's all good? Last time I tested, if you set one IP per user in your wireguard config, that user must connect with that IP.
I believe you're referring to AllowedIPs, which is more around the IPs allowed over the tunnel. I'm talking about the non tunnel source IP of the peer. If you can copy a peers key and use the right AllowedIPs, nothing stops you from impersonating a peer. Being able to lock down peers to a source IP would fix this.
I think that goes against the tenant of wireguard working well while roaming. In general the concept of an identifying ip (outside of wireguard) will only lead to problems: devices can have multiple ips, and also share ips in the case of NAT/CGNAT. In my experience it's never been worth the trouble (again excluding wireguard)
Deny by default and Defense in depth are good security approaches in many organisations.
I may have a critical server that only comes from 1-2 known, static, IPs.
Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my super important server by mistake. I would prefer it simply wasn’t able to connect.
My point is, you deny by default and only allow your static ips at the FW.
You need a firewall rule anyway to let the wg traffic through.
WG was built to handle roaming, and the FW can do a great job of filtering by address already, so it makes sense to not bloat wg with extra code to me.
But the FW can’t filter by source IP and key, which is important to some people. There’s a gap in security coverage between WG and FW. This is commonly supported by IPsec implementations already.
Remember your WG service could be terminating many tunnels from many different sources. Some yes roaming may be valid. Others not. There is no way in WG to selectively disable roaming for some keys but not others. This may be an intentional design decision in WG but I would argue it’s a poor one due to the above.
> As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect.
Yes WireGuard roams, which is the right behavior usually. What's your use case where an otherwise valid encrypted packet should be rejected based on source ip? Could you use ufw?
Mostly laziness. If I'm already giving WireGuard an IP via Endpoint, why not have it locked down to that by default? Isn't that what an end user would expect? Otherwise I have to put that IP in multiple places (WireGuard, nftables, etc).
The two most common topologies I've seen for WireGuard are:
1) Client-server, where the client is behind NAT and the server is publicly available at some DNS. The client specifies the server by hostname as the endpoint, and the server doesn't bother specifying an endpoint. Client roams when they switch networks, server roams when they roll over the server, everybody is happy.
2) Peer-to-peer, where the nodes are directly addressable by IP address, whether by public IP or private virtual private IP. In this case, the node dialing in sets an endpoint of the node being dialed, and the node being dialed doesn't bother specifying an endpoint. Thereafter node identity is verified by private key and nodes can fully roam within the firewall-limited subnet.
In every case I've seen, roaming by default is the right choice.
These are all reasonable things to want and to track down, but it's worth noting that you in fact don't want WireGuard to support these things out of the box; the point of WireGuard is that it has exactly one job, and that job is integrated as deeply as possible with Linux networking. The things you're asking for are meant to be layered on top of WireGuard.
Don't tell people to not want the most basic amount of security implemented within the protocol. The rest of the Linux kernel networking stack logs more verbosely than WireGuard, and it supports packet filtering. If you had someone compromise your WireGuard mesh, you'd never know.
These are oversights, and it's OK for software to have them, but they need to get added in the future. Requiring users to layer this stuff on top of WireGuard creates security footguns. WireGuard's implementation isn't set in stone, it should be improved.
You can add profiles with Apple configurator 2. You don't have to go the full MDM route. It's quite easy.
I think the problem is though that the iOS client doesn't support configuring this option in the profile (whether installed via configurator or MDM) either.
Wow, that's a pretty bullshit sounding response from tailscale. "We don't want to overcrowd the settings". It's ok to say "we'd prefer our users used our paid auth, rather than self host auth and use the fruits of our labour for the app". No need to be so opaque about it.
Same. I recently started using it for a personal project, and was amazed how much it simplifies the access and management of the infrastructure.
I'm also using it to SSH into my home PC. No need to open router ports, configure dynamic IP, or whatever. Just setup tailscale, and I can simply do ssh user@homepc thanks to MagicDNS.
I've been using tailscale for a couple years. wrt ios every couple of weeks all traffic on my phone stops and I need to open the tailscale app and toggle the active switch for traffic to start flowing again. I don't have that problem with my other devices.
The way it works on phones is these apps operate as full VPN due to how network permissions for apps are handled. When you turn on tailscale, tailscale will pass through traffic it doesn’t need to touch. that’s also why you can’t have two vpn apps running at the same time.
I had a similar issue, clearing history and website data in Settings > Safari and reinstalling fixed it for me. I may have rebooted the iPhone as well for good measure.
I really want to like WireGuard, and these get so close to what I want. I think as soon as Headscale gets the iOS story sorted out I'll be able to switch away from IKEv2/IPSec.
Right now the thing that's stopping me is the lack of Split-DNS. I'd even be happy if I could configure this in the official client, I've only got a handful of devices so distributing the configuration by hand is fine. My IKEv2/IPSec set up does this perfectly, and using MDM profiles lets me set up connect-on-demand. WireGuard already does connect-on-demand and my limited testing suggests that it works well enough.
I don't want to use Tailscale since I'd like to keep everything self-hosted. It sounds like Headscale is almost there - it just needs the iOS client to be able to point to an arbitrary endpoint.
You can use openresolv to configure a local DNS server to do split DNS, or let do systemd-resolved do it. Or did you mean Android/iOS with 'official client'?
This is feasible to config in WireGuard, but it’s somewhat up to the host to leverage it appropriately, and the config is certainly not clear about that fact. If you append the DNS config of a peer with the search domains you want sent over the private horizon (eg: 192.168.1.10, 192.168.1.11, internal.domain, other.domain) this is intended to configure conditional forwarding for those zones you specify. Again, it’s dependent on the peer host OS to be able to do that, but that’s how I do it with my client access VPN.
That's the biggest challenge - it's not really a WireGuard problem, but "something" needs to be able to tell iOS "use server X for *.blah, otherwise use whatever servers you got from the WiFi connection".
FYI macOS (/etc/resolver/*) and windows (Set-DnsClientNrtpPolicy) resolvers support split dns out of the box. Suggestion for mobile is less ideal, but just tunnel to a DNS server that takes care of split resolution and use that server when wg interface is up.
Wireguard itself will always consider authentication, dns, routing, etc. out of scope which IMO is really for the best
My mental model of WireGuard is that it wants to replace IPSec (the encryption/tunneling), not IKE/IKEv2 (authentication, session setup, etc). It's not a perfect mental model, but it serves me well.
On the official client I can specify DNS servers for a particular connection, so one "easy" solution would be to specify domains that need to go to that set of DNS servers. e.g., when connected to home use 192.168.x.y to resolve *.blah, otherwise use the system resolvers.
Split DNS is super complicated to implement client side. We halfway implemented a solution and backtracked, eventually settling on just setting /etc/hosts. There's way too many variables involved across all the different operating systems.
These days it's pretty simple to achieve with systemd-resolved. I've been playing with split DNS and VPNs for a while and it seems it's a solved problem on Linux, finally.
The big hurdle is understanding the concept of search domain vs routing domain and the interaction with resolved and NetworkManager.
Funny, systemd is like an opposite of wireguard in design goal. I believe the UNIX way would be /etc/hosts but some way to sync these within clients. Like etcd or whatever.
Ah yes, my bad. /etc/nsswitch.conf (which is also a Linux-ism but BSDs have something similar) supports LDAP. However, an advantage of /etc/hosts is the low latency since its not networked, while LDAP would result to overhead. Still, I believe that would be a suitable alternative. There's some non-bloated alternatives to OpenLDAP, and also an option could be caching.
I only do self-hosted options so it might be a while before I really tinker with Wireguard. I've looked into setting it up but it does not meet my needs today for dynamic mesh routing and requires much of the system configuration of OpenVPN or Strongswan albeit simpler configuration but the same concepts still apply.
My preferred ideal dream setup would be if the Tinc open source VPN had integration with OpenLDAP for ID management and could leverage Wireguard for speed. I am not a proper developer so I can only wish for such a thing or maybe pay someone to make this. Tinc has awesome user-space dynamic mesh routing but lacks user management and is slow compared to Strongswan/OpenVPN. Wireguard is fast. OpenLDAP can back-end ID management for just about anything, especially when combining it with oauth/saml and can be integrated into just about anything and that works for me because I am a fan of decentralized and/or distributed systems.
It does not appear that Tailscale is an identity provider but rather integrates into commercial ID providers? Do they integrate into OpenLDAP or into OAuth/SAML providers that are in front of OpenLDAP?
[Edit] Answering my own question. Custom SAML providers are only supported with the Enterprise edition. [1]
In fairness, they do out of the box support most of the major players in the SSO space for free (google, Microsoft, okta, gitub...). I'm happily using Google SSO to manage a small number of users for my tailscale account free of charge.
FWIW, tailscale is technically not free once more than 1 user, its a commercial service at the end of the day not some self-hosted open source application. They have extremely generous fair use policy in my experience and won't bill for a small number of users though. This means custom SSO is likely only a real issue for paying customers to begin with, although I can understand the frustration for the few users who do want it on the free tier.
If you don’t need identity controls (using a fixed node configuration), you can always use vanilla Wireguard without the user management. You don’t get a NAT traversing mesh, but if your nodes are visible to the net, you do get direct node to node networking. If you only have one node directly visible, you can also use that as a gateway.
I like these more traditional VPN style use tools for Wireguard, but you can always use the lower level version itself, if you’re comfortable with the configuration limitations.
That is how I use Tinc today. I briefly tried Wireguard but it works very much like OpenVPN and Strongswan in that it does not have dynamic mesh routing. Privacy advantages aside, the dynamic mesh routing I get from Tinc works around internet outages, albeit slower than I would like but a 2 minute routing outage is still better than {n} time it takes for ISP's to manually work around fiber breaks and datacenter network changes gone-wrong. But that is just my preference, it certainly isn't for everyone. I could probably accomplish this in Wireguard using weighted routing table rules but that gets complicated and messy very fast and I just lazy enough to avoid this. Perhaps someone has created an Ansible playbook that calculates all the routing rules and weights for this setup but I have not actually looked for it.
That said I can layer things on top of Wireguard, OpenVPN and Strongswan that accomplish similar goals such as using HAproxy but then protocol support is limited whereas a dynamic mesh in Tinc allows all TCP/UDP for my needs.
You can run dynamic routing protocols such as OSPF or iBGP over Wireguard. It's not built in, but that's a feature, not a bug—I vastly prefer software that does one thing and does it well.
I have a full mesh of Wireguard tunnels configured between home/office/datacenters/laptop, and run bird[0] on the VPN endpoints to direct traffic between them.
tinc's "anycast" support is pretty spiffy. i have three servers in different geographic regions acting as nameservers for my "internal" network. tinc ensures the one with the lowest latency gets the request
We solve this (for non-technical colleagues) by keeping the key in terraform (via my open source provider OJFord/wireguard - accepts either a public key for out-of-state key, or generates one for you). Then we can just provide users who don't know or care about keys a file to import into the wg app.
(Spoofing other users if you already have access to our tf state isn't a vector we care about.. even if we logged user info for audit, that kind of access would let you fake that and worse anyway.)
Maybe it's not as flashy to set up from a non-technical-end-user perspective, but it's easy; it's just wireguard & terraform, both of which we're using anyway.
> Despite Headscale's unofficial status, Tailscale seems to be fully supportive of its efforts; Tailscale has coordinated with Headscale's creator on API changes and hired one of Headscale's maintainers.
I have noticed an interesting change psychology arising from behavior such as this. I am more likely to use Tailscale (at the very least professionally, if not personally) instead of the free/OSS version because of this goodwill. Another example is Aeotec, who produce Z-Wave appliances. Aeotec's cooperation with the community (in terms of firmware) gives me significantly more confidence in the longevity of their devices.
Sadly, I don't think this psychology is ever going to become pervasive. People like what they already like.
I agree. It probably helps make the decision because of how easy it would be to fall back on the FOSS version if needed, but for now its worth offloading the setup/hosting for the relatively small fee.
I'll definitely check out Headscale, I have similar infrastructure setup with pfsense running wg on a VPS that connects to my pfsense box at home. I have other VPS that connect to the cloud pfsense box and routes setup to the home box so I essentially have an extended LAN. This seems promising as it will remove the pain of configuring additional clients.
106 comments
[ 0.17 ms ] story [ 179 ms ] thread“The WireGuard private key is stored in the memory of the Pritunl client background service and also in the WireGuard configuration file. WireGuard uses a connection-less design and this private key could be used by an attacker to hijack the connection even if multi-factor authentication is used. In high security environments it is important to consider that OpenVPN connections with multi-factor authentication will not have these weaknesses. For this reason the server will quickly revoke WireGuard keys of inactive clients to limit the possibility of this occurring”
Does anyone know how others like Tailscale address this issue?
[1] https://github.com/WireGuard/wgctrl-go [2] https://github.com/pritunl/pritunl/blob/f82528ff2b7250965faf...
Because these keys aren’t the short life, in-memory session keys[1], but auth keys. Knowing this single key effectively bypasses any MFA you may have.
Seems like Tailscale has 180 days by default[2], which feels a bit too long for a person who expects MFA to be more proactive than this. Sure you can change the default to 1 day, but how many users know it’s possible or would even think to change that?
Compare that with OpenVPN where you can force every single auth attempt to use a password plus TOTP code for instance.
1. https://www.wireguard.com/protocol/
2. https://tailscale.com/kb/1028/key-expiry/
Wireguard has none of that, not even the notion of a user. There are just keys in a special (unsupported by anything else) format that are assigned an IP address statically in a file. Oh, and the frigging software writes into that config file if you change anything.
Wireguard is a nightmare for any attempt at sane system administration.
It’s quite simple really: WireGuard is a building block. TFA mentions several systems built on top of WireGuard, that enables sophisticated handling of users/roles, authentication, ACLs, etc.
However, the system on top of WireGuard cannot just spit out a key to the user and call it a day.
The key (sorry…) is to make the system a) verify the identity of the users via an IdP (e.g. Okta or something similar) and then b) distribute short-lived keys, that can be revoked.
If one reads how Tailscale handles user authentication and key rotation, one will notice that they have a solid system in place for handling the keys and the product is much more sophisticated than OpenVPN.
I haven’t studied the approach of their competitors (e.g. Firezone) so I can’t comment on that.
References/suggested reading: https://tailscale.com/kb/1028/key-expiry/ ⦁ https://tailscale.com/blog/tailscale-key-management/ ⦁ https://tailscale.com/customers/gini/ ⦁ https://tailscale.com/kb/1009/protect-ssh-servers/
https://web.archive.org/web/20210919013400/https://community...
OpenVPN is simply bad at networking irrespective of any security considerations. (Wireguard, AFAICT, does the right thing with regard to MTU and is much simpler as a result. OpenVPN seems to go out of its way to be wrong.)
There's too many headers that are too big. If you do a simple L2 tunnel, you have three options: jumbo frames, packet fragmentation, or custom hacks. None are great.
> Linux has built in L2 tunneling, sans encryption
IIRC, because the extra header for the encryption layer pushes the MTU over 1500.
I'm using that in production with Babel (managing dynamic routes) with great success. Tinc had been solid for us for years, but once I actually payed attention to the performance hit, it was worth a bit of hassle to make it work over wireguard.
But more importantly, you can't just count lines of code as if they're all equivalent. There's a trusted core of code that is more important than the rest of the code, and WireGuard's trusted code is microscopic compared to OpenVPN. That's the right word in this case: "microscopic". It's some of the easiest code in the whole kernel to read, even given the cryptography.
Do you have some evidence for that or is it just speculation?
"But more importantly, you can't just count lines of code as if they're all equivalent."
You're right but the Wireguard white paper conclusion claims an advantage for Wireguard based solely upon the lines of code needed to implement.
OpenVPN, Wireguard and IPsec all have their advantages and disadvantages. I have and will use all 3 where appropriate based upon them.
Further, that is not what the WireGuard paper concludes. For instance: the paper makes a note of the fact that WireGuard is designed to be implemented without dynamic memory allocation, which is not a function of lines of code (in fact, it probably adds lines of code).
You do you, but as a practitioner in this space, I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice. You might disagree, but I think you'd be in the minority of security engineers on the point. Feel free to ask around! The codebases for OpenVPN and the IPSECs are reviled.
The Wireguard paper makes notes of many things including the lines of code needed to implement.
"I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice."
Life is complicated and those type of concerns are almost always in play which means OpenVPN and IPsec are also always in play. Wireguard is great where it is a fit but there are characteristics of Wireguard which also make it the more complicated and fragile solution in some circumstances.
- Logging of peer IPs when they initially connect or change (yes, you can do this with module flags, but it should come out of the box).
- Tieing WireGuard private keys to a source IP. As far as I know the endpoint flag does not enforce an IP, a peer can use a different one and still connect.
- More control over DNS resolution for endpoints. I want WireGuard to periodically refresh the endpoint IP when I change networks, for instance.
Out of curiosity, why do you want this?
It'd definitely be nice if wg-quick and the official apps supported it, though.
Alternatively if your client is Linux, there is:
https://github.com/WireGuard/wireguard-tools/tree/master/con...
I may have a critical server that only comes from 1-2 known, static, IPs.
Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my super important server by mistake. I would prefer it simply wasn’t able to connect.
You need a firewall rule anyway to let the wg traffic through.
WG was built to handle roaming, and the FW can do a great job of filtering by address already, so it makes sense to not bloat wg with extra code to me.
Remember your WG service could be terminating many tunnels from many different sources. Some yes roaming may be valid. Others not. There is no way in WG to selectively disable roaming for some keys but not others. This may be an intentional design decision in WG but I would argue it’s a poor one due to the above.
I consider the behavior a feature, allows for seamless roaming. You should not trust the IPs anyway, that's what the keys are for.
Yes WireGuard roams, which is the right behavior usually. What's your use case where an otherwise valid encrypted packet should be rejected based on source ip? Could you use ufw?
1) Client-server, where the client is behind NAT and the server is publicly available at some DNS. The client specifies the server by hostname as the endpoint, and the server doesn't bother specifying an endpoint. Client roams when they switch networks, server roams when they roll over the server, everybody is happy.
2) Peer-to-peer, where the nodes are directly addressable by IP address, whether by public IP or private virtual private IP. In this case, the node dialing in sets an endpoint of the node being dialed, and the node being dialed doesn't bother specifying an endpoint. Thereafter node identity is verified by private key and nodes can fully roam within the firewall-limited subnet.
In every case I've seen, roaming by default is the right choice.
These are oversights, and it's OK for software to have them, but they need to get added in the future. Requiring users to layer this stuff on top of WireGuard creates security footguns. WireGuard's implementation isn't set in stone, it should be improved.
https://news.ycombinator.com/item?id=33263746
It's magical. It's well on the way towards being a critical piece of infrastructure in my mind.
https://github.com/tailscale/tailscale/issues/5431
I think the problem is though that the iOS client doesn't support configuring this option in the profile (whether installed via configurator or MDM) either.
I'm also using it to SSH into my home PC. No need to open router ports, configure dynamic IP, or whatever. Just setup tailscale, and I can simply do ssh user@homepc thanks to MagicDNS.
There’s no way to troubleshoot. A bunch of forum posters reported the same issue after an update, but no solution for a few months.
What's the bug? I hadn't heard about this.
Metrics show no drop in iOS control plane connections.
https://forum.tailscale.com/t/difficulty-with-ios-tailscale-...
Other posts had some troubleshooting guidance that wasnt effective. Note that it only failed on iOS. Still using it on my Debian boxes.
If you could point me at anything I would be very grateful. I’m using some other VPN container now that i don’t like!
Right now the thing that's stopping me is the lack of Split-DNS. I'd even be happy if I could configure this in the official client, I've only got a handful of devices so distributing the configuration by hand is fine. My IKEv2/IPSec set up does this perfectly, and using MDM profiles lets me set up connect-on-demand. WireGuard already does connect-on-demand and my limited testing suggests that it works well enough.
I don't want to use Tailscale since I'd like to keep everything self-hosted. It sounds like Headscale is almost there - it just needs the iOS client to be able to point to an arbitrary endpoint.
Wireguard itself will always consider authentication, dns, routing, etc. out of scope which IMO is really for the best
On the official client I can specify DNS servers for a particular connection, so one "easy" solution would be to specify domains that need to go to that set of DNS servers. e.g., when connected to home use 192.168.x.y to resolve *.blah, otherwise use the system resolvers.
The big hurdle is understanding the concept of search domain vs routing domain and the interaction with resolved and NetworkManager.
My preferred ideal dream setup would be if the Tinc open source VPN had integration with OpenLDAP for ID management and could leverage Wireguard for speed. I am not a proper developer so I can only wish for such a thing or maybe pay someone to make this. Tinc has awesome user-space dynamic mesh routing but lacks user management and is slow compared to Strongswan/OpenVPN. Wireguard is fast. OpenLDAP can back-end ID management for just about anything, especially when combining it with oauth/saml and can be integrated into just about anything and that works for me because I am a fan of decentralized and/or distributed systems.
[1] - https://www.tinc-vpn.org/
[Edit] Answering my own question. Custom SAML providers are only supported with the Enterprise edition. [1]
[1] - https://tailscale.com/kb/1119/sso-saml-oidc/
FWIW, tailscale is technically not free once more than 1 user, its a commercial service at the end of the day not some self-hosted open source application. They have extremely generous fair use policy in my experience and won't bill for a small number of users though. This means custom SSO is likely only a real issue for paying customers to begin with, although I can understand the frustration for the few users who do want it on the free tier.
> https://tailscale.com/pricing/
I like these more traditional VPN style use tools for Wireguard, but you can always use the lower level version itself, if you’re comfortable with the configuration limitations.
That is how I use Tinc today. I briefly tried Wireguard but it works very much like OpenVPN and Strongswan in that it does not have dynamic mesh routing. Privacy advantages aside, the dynamic mesh routing I get from Tinc works around internet outages, albeit slower than I would like but a 2 minute routing outage is still better than {n} time it takes for ISP's to manually work around fiber breaks and datacenter network changes gone-wrong. But that is just my preference, it certainly isn't for everyone. I could probably accomplish this in Wireguard using weighted routing table rules but that gets complicated and messy very fast and I just lazy enough to avoid this. Perhaps someone has created an Ansible playbook that calculates all the routing rules and weights for this setup but I have not actually looked for it.
That said I can layer things on top of Wireguard, OpenVPN and Strongswan that accomplish similar goals such as using HAproxy but then protocol support is limited whereas a dynamic mesh in Tinc allows all TCP/UDP for my needs.
I have a full mesh of Wireguard tunnels configured between home/office/datacenters/laptop, and run bird[0] on the VPN endpoints to direct traffic between them.
[0] https://bird.network.cz/
https://github.com/tonarino/innernet
https://github.com/angristan/wireguard-install
Needless to say, Wireguard is preferred over other VPNs. Far less code.
https://pages.nist.gov/800-63-3/
(Spoofing other users if you already have access to our tf state isn't a vector we care about.. even if we logged user info for audit, that kind of access would let you fake that and worse anyway.)
Maybe it's not as flashy to set up from a non-technical-end-user perspective, but it's easy; it's just wireguard & terraform, both of which we're using anyway.
I have noticed an interesting change psychology arising from behavior such as this. I am more likely to use Tailscale (at the very least professionally, if not personally) instead of the free/OSS version because of this goodwill. Another example is Aeotec, who produce Z-Wave appliances. Aeotec's cooperation with the community (in terms of firmware) gives me significantly more confidence in the longevity of their devices.
Sadly, I don't think this psychology is ever going to become pervasive. People like what they already like.