Hi, I just tested out WG for the first time on my CU195 build. I’ve never used WG anywhere else prior to this. Some comments:
-it took me a minute to figure out I needed to fill in the Endpoint and Client Pool fields. Isn’t all this auto-populated in IPFire’s OpenVPN implementation?
-I was shocked there is no password as a 2nd factor. If the .conf file gets lost or stolen, there is nothing stopping someone from making a full VPN connection to your server with zero effort.
-DNS didn’t seem to be working. My RDP session wouldn’t connect with hostname. Once I switched it to the device’s IP address, I could connect via RDP.
-It does seem significantly faster. I did a quick test with transferring a file over both OVPN and WG and both Windows estimates and my stopwatch said the transfer was significantly faster.
-I am assuming that I will need to manually update QoS to account for WG’s traffic. I did not see any ports or services added to my VPN Class after setting up WG.
Bravo to the team for getting another option implemented! I have no doubt that kinks will be smoothed as we move forward and I can see this option being preferred over OVPN soon!
I had to change my endpoint field from the hostname to our public IP. It seems this would be a safer default than hostname? Could the client pool field eventually be auto-filled with a different IP range than OVPN?
After some googling, I see that people have made this point already. But it can be an “implementer option”. The way it currently is, I would have to change my practice at our workplace from leaving the OVPN config file in the user’s possession to making sure it is deleted from any and all systems. I consider this a dangerous practice and as it currently stands, I’d only use this personally and stick with OVPN for business use.
I didn’t spend a lot of time with this, but I found it odd that my RDP config, which works fine with OVPN, would not connect until I edited the config to change the hostname to it’s IP. Has anyone tested this out yet?
Time permitting, I will do some more extensive speed comparisons and report back in this thread.
This wasn’t hard to do, and I took care of it, but it might be something to consider updating in future builds, to automatically update QoS settings when WG is set up. Maybe that’s not practical?
thank you for your feedback. Let’s go through this bit by bit…
I don’t think that automatically populating essential parts of the network architecture are a good idea. With OpenVPN, we inherited it. But it simply generates a random subnet and won’t check if it is being used elsewhere. Chances are that there will be a collision.
Well, so this is a point that has been raised by many people before, and I don’t really know how to explain my own position on this. So let me try:
WireGuard is a very simple protocol. That does not mean badly designed, or that the design is falling short of something. It was simply designed to be as lightweight as possible. The goal was to have a much smaller code base that can be reviewed much easier than for example IPsec or OpenVPN. And with such a small code base comes less features. Static keys only, no cipher negotiation, no IP address negotiation, no pushing of DNS and time servers and so on.
If you want all those things you will have to use IPsec or OpenVPN, because WireGuard does not have and will never have any of these.
You can only go one way. Either simple, or have the complex code bases.
In 2020, I wrote a longer post about this and that I think that WireGuard will not replace IPsec and OpenVPN in such environments where all those features are needed. After all it wasn’t like that the designers of IPsec and OpenVPN where trying to completely bloat their solutions.
Exactly. The credentials will be stored in the client in plain text. There are no passwords that protect the connection or certificates like OpenVPN can do, or there won’t be any 2FA.
This is some configuration issue then. Either you have not configured a DNS server, or the DNS server is not reachable through the tunnel due to firewall rules.
That massively depends on the hardware. Today, there will be a blog post on the IPFire blog with a couple of benchmarks that show how fast WireGuard can actually be when it comes to throughput.
Yes, since it uses random ports, we cannot really suggest any default configuration.
We cannot populate the field with the current public IP. Too many people have ISPs that randomise IP addresses and we have no way to know whether you are one of those people or not. I just hope that people are giving their firewall a properly, globally resolvable FQDN. This is a requirement for IPsec already to make the host certificate authentication work.
There is no way to implement things on top of WireGuard. The protocol itself does not have any extensions that we could plug into. We could now either fork the protocol or we could lay things on top of it and build our own suite of clients. That would however be a nightmare and completely not suitable for anyone.
If you need those features, you will have to stick to OpenVPN.
I have. The domain suffix is given via OpenVPN-Config. WG does not seem to provide this. To solve this, you have to manually enter the DNS suffix in the IPV4 protocol in the WG network connection.
Thank you! Simply copying the contents of Local VPN Hostname/IP: from the OpenVPN page and pasting it into the Endpoint field on the Wireguard page did the trick for future connections. Of course, updating the .conf file was the way to do it on my existing connection.
Sorry, yes. I made the other change first, thinking that’s what you meant. After making that change, I tested from a different system that was onsite, but on a guest network and my RDP shortcut worked.
When I tested from a different system from home later, it did not work til I added both the FQDN of the DNS server to the WG conf file AND used the FQDN in RDP.
