The problem has always been getting outside of the tunnel, setting up the tunnel is simple. It seems that no matter what I do, I’m always stuck in the tunnel’s subnet.
I haven’t gone that deep into it, because generally by then I’m frustrated and have given up haha, I’ve done the basics like netcat, pings and sending a dummy file while watching the normal log level. When I feel like tinkering again I guess I’ll have to take a deeper dive.
How are packets from your internal LAN getting routed to the WireGuard container?
When running it in docker I’ve let the engine set up the internal routes (172.xx.xx.xx/24 to 192.168.1.0/24) and of course the route from my LAN to WAN is already setup. There is no mention of having to manually define routes when using a container, it says “it’s the easiest way to setup wireguard” which, to me, means you should have to do less “leg work”.
Normally in a home environment you would run it on your router to make this a loot simpler.
Yeah, that’s why I decided to ditch the container, and do it on my router since support for it is built into the UI, but once again, nothing…
I’ve allowed all subnets (0.0.0.0/0) and explicitly defined them as well to no avail.
why didnt you read the docs?
I have, no need to be an ass.
Agreed, PiVPN makes it too easy. Im up and running within 5 minutes and PiVPN also detects Pi-Hole and incorporates that too if you want.
That is the downside of a protocol that is connectionless.
The VPN UI of most systems assume a VPN that has has a connected and disconnected state. But wireguard has a state of the tunnel interface up + configured or not up. Looking at the latest handshake is usually what you want. I kinda wish the UI would make that more obvious.
At least one person agrees with me haha Everyone else is like “you’re dumb, it’s easier”. The WireGuard logs in the official Android app are also terrible compared to that of OpenVPN. OpenVPN will tell you exactly what the issue is, meanwhile the WireGuard logs are just like “Trying handshake again…timed out…trying handshake again…timed out” ad infinitum.
That’s UDP and not a fault of wireguard.
Nope, I’ve read a ton though. I’ll give it a watch.
Thanks! I think I’ll just stick with OpenVPN for now since it works and I don’t feel like beating my head against the wall right now since I have other things to worry about.
It sounds like you are trying to route all traffic over WireGuard, but you make no mention of configuring the routing on the Linux host.
I’ve setup the routes manually in the past and got nothing either 
Since you mentioned you are running OPNSense, I’d recommend running WireGuard there. Follow this guide: WireGuard Road Warrior Setup — OPNsense documentation You need to pay attention to Step 5, specifically Step 5B.
I followed that, but 5B is only necessary if you’re using IPv6, which I’m not. To quote the info box “If an interface has already been assigned under Step 5(a), then it is not necessary for IPv4 traffic, and is only necessary for IPv6 traffic if the tunnel uses IPv6 ULAs (IPv6 GUAs don’t need NAT).”
If you want any routing beyond that, you need to set up the routing in the way appropriate to the host running WireGuard.
Pretty much everything I’ve seen says that tools like wg-quick already setup the routes for you, or the instructions I’ve followed explicitly show you how to setup the routes.
So, the “quick and easy” part of WireGuard seems to be complete bullshit IMO because OpenVPN already does this for you. The only issues I’ve ever had with OpenVPN is the SSL certs, which are just a PITA in the general regardless of the tech, and those can be disabled.
Thanks for trying, though.
I’ve never had performance issues with OpenVPN, but then again I’m usually not doing anything more than browsing an internal site.
Actually you don’t need wg-quick at all. Read the docs.
Sounds like a routing problem not necessarily a Wireguard issue. OpenVPN automatically sets up NAT routing when you use the “server” directive. Wireguard doesn’t do that, you specifically have to add a “PostUp” to configure your firewall to do the necessary NAT routing. Also depending on which wireguard implementation you use, routing tables may or may not be automatically configured as needed to send traffic through the tunnel.
If all else fails, just use OpenVPN. There’s nothing wrong with it if it serves your purposes. Also you can continue to be the envy of all the Wireguard users that chose Wireguard because OpenVPN was too complicated for them.
Funny how op didn’t touch this thread. They thought they could come here and LARP “Linux Systems Engineer” and we’d be all “yes ur very smart and correct we don’t know why it won’t work wg not good”
I’m always stuck in the tunnel’s subnet.
Which almost certainly means your problem is routing. If the tunnel is established, and you can access ping the tunnel IP of the remote device, but nothing beyond that, something is broke with routing, or you have a firewall that is blocking things.
PS if you want more help you could possible add a post here. Try posting your configurations, network setup, route tables and so on.
No you obviously didn’t Mr engineer. You obviously didn’t read my reply either because I spelled out why what you tried didn’t work. I will not be helping on this anymore. You’re a Linux systems engineer you can figure it out or go back to open vpn.
Yes I know. I’m just saying it makes debugging trickier. When it works its awesome though
It really helped me. I pause the video and use left and right arrows to follow along.
Sorry, I should have said 5A, not 5B. In the highlighted box under 5A:
Second, it automatically adds an IPv4 outbound NAT rule, which will allow the tunnel to access IPv4 IPs outside of the local network (if that is desired), without needing to manually add a rule.
The important part is making sure there is an outbound NAT rule.
Pretty much everything I’ve seen says that tools like wg-quick already setup the routes for you, or the instructions I’ve followed explicitly show you how to setup the routes.
First, wg-quick is utility to help you manage WireGuard connections, it’s not a part of WireGuard itself. It’s not necessary at all, but does make things easier.
Second, wg-quick does not set up any routing for you. You still have to create and add the routing rules yourself.
What wg-quick does is allow you to automatically execute some commands immediately after the WireGuard interface comes up by using the PostUp line in the config file. This doesn’t have to be a iptables command. It could be a command to mount a shared network drive. It could be a command to ping a server. It could be a command to launch a web browser. PostUp and PreDown aren’t tied to routing.
You CAN use them to make changes to the routing tables. This is what most examples show. Then it takes care of activating and deactivating those routing rules when you use wg-quick to manage the interface. It makes it a lot easier to manage, but it also reinforces the misconception that the routing is part of WireGuard. They are separate things, put together in one file for convenience. And it’s not actually part of WireGuard at all, it’s a feature of the convenience tool “wg-quick”.
So, the “quick and easy” part of WireGuard seems to be complete bullshit IMO because OpenVPN already does this for you. The only issues I’ve ever had with OpenVPN is the SSL certs, which are just a PITA in the general regardless of the tech, and those can be disabled.
I have used OpenVPN and IPSec for almost 20 years. WireGuard, to me, is much easier to work with than either. And it is a LOT faster, especially faster than OpenVPN.
The one thing I struggled with at first was shedding some of my pre-conceived notions about VPNs. I’ve seen lots of comments in here from people who seem to be struggling because they seem to share some of those same misconceptions I had at first. It’s easy make things hard when you think of a VPN as this huge, feature rich, monolithic, all-encompassing thing that includes the kitchen sink. People expect WireGuard to be like that. It’s just not.
WireGuard is much, much simpler than that. As I mentioned before, WireGuard probably shouldn’t be considered a VPN at all (Who’s with me on trying to popularize the acronym VPT?). All it does is create virtual network interfaces, then create a secure tunnel between those interfaces. How you configure those interfaces to interact with the other interfaces, real and/or virtual, is left up to you. It’s beyond the scope of what WireGuard attempts to do.
Think of WireGuard in terms of physical hardware. Think of it like adding a network interface to two computers, and running a single ethernet cable between them. Let’s say the interface name is wg0. Configure the IPs on each end so they can talk to one another. Congratulations, you’ve just replicated WireGuard in physical hardware. It’s really, conceptually, that simple.
What you do with wg0 from here, including routing, is up to you.
This is very different from the likes of OpenVPN, where all the configuration, with all it’s features, and all the bells and whistles, is all put in one place. OpenVPN and IPSec tend to be deeply integrated and take charge of the network stack.
WireGuard doesn’t. It just creates a tunnel between virtual devices.
If you’ve got a successful connection from one WireGuard system to another, you’re 75% there. All you need to do is add the outbound NAT and routing.
I found a good reference for a DIY server: https://www.stavros.io/posts/how-to-configure-wireguard/
Look under “Accessing your home LAN” or “Forwarding all your traffic through” depending on your goal. Just 3 lines in a config file, and barely over a page describing how it works. The OpenVPN config file alone is bigger than the whole article. I don’t know how anyone can say OPenVPN is easier than adding 2 lines in a config file and editing one other line.