Wireguard works differently..
If a packet isnt properly encrypted for the peer or data is not signed by a known peer, the packet is dropped.
Wireguard doesnt answer anything if these 2 requirements are not met.
See the protocol: https://www.wireguard.com/protocol/#dos-mitigation
> the server does not even respond at all to an unauthorized client; it is silent and invisible
>Instinctively, that feels very wrong and sounds like just anyone can brute force/monkey their own config file if they knew enough information.
Sure, good luck brute-forcing the 32 byte private key matching a public key for one of the configured peers on the server.
I'll call you back in a few thousand years to check how you're doing.
Read the official white paper if you actually want to understand how it works, instead of letting strangers on the internet explain it to you.
Like the webpage says, Wireguard is still pre-release software, and hasn't undergone proper security auditing. It may have exploitable security vulnerabilities, and the protocol may be subject to change.
I find it useful as a VPN tunneling method, but for the moment, I never use it for unencrypted traffic that I wouldn't be happy sending over the open Internet.
> Methodology...
And continues to list nothing of the client hardware or software setup, network type, speed and throughput or anything else of use. I see around 900Mbps from all the commercial VPN providers I've tried over WireGuard (Mullvad, OVPN, AzireVPN, NordVPN, PIA...) so that's not in doubt. It would be nice to actually explain the setup and variables if you're going to bother including a methodology at all.
Wireguard is a VPN protocol. It's not a VPN provider (like Mullvad/etc). Wireguard is the idiom/algorithm used by your PC to talk to another peer, that peer might be another device owned by you, or not. For peers to find each other, they must connect to an endpoint.
Also, wireguard doesn't really have the concept of servers, it only really knows keys, peers, endpoints, and which packets are allowed from which key (allowedIPs). So your question 'make one server' doesn't really make sense.
So in order to actually use Wireguard you need some endpoint to sent your packets to, you can either host your own (DigitalOcean/Linode/AWS/home pc). Or pay a VPN provider.
If you want to tunnel past your ISP, then obviously your home PC can't be the exit peer/endpoint, you will need to host an peer outside your ISP's network (like a VPS provider), or pay a VPN provider for a ready-made solution.
So the 'server' you've described would work, but it wouldn't do anything useful (if your goal is tunneling past your ISP).
If your goal is accessing your home LAN securely from the internet, then the configuration would actually be usefull.
--
That being said, please question if you really need VPN, the internet seems flooded with shills blindingly recommending using a VPN without ever explaining the implications of using a VPN, or that it only really moves the issue a step further (so you must trust the VPN provider). In most cases, you don't need a VPN.
--
Feel free to ask if you have any other questions.
There is some room for a CPU Exhaustion attack. My guess would be that you’d have to hit a well-provisioned server with several Gb of traffic consistently to trigger that. There’s some mitigation around that type of attack built in; when a server is under load it will defer handshake processing and use a cookie instead which is apparently less CPU-intensive. I can’t say I fully understand it but it’s pretty well documented under the DOS Mitigation section of the protocol documentation.
As suggested in other posts, also using port 123/UDP (NTP) and 563/UDP (NNTPS) work for me. I have a primary Wireguard server (port-forwarded via 123/UDP) and a secondary one (port-forwarded via 563/UDP) and have been able to use the tunnel when connected to a public WiFi that was even blocking my NordVPN NordLynx and OpenVPN (both TCP and UDP) connections.
It's not because it's part of 14 eyes that it's a no go. Sweden has strong privacy laws and they don't even have gag orders so even if Mullvad receive any complaint they can tell their users if they are globally monitored or if some servers are. Since they take NO personal information (random generated number), 14 eyes is really not a bad thing at all.
Read the whitepaper and documentation made by the Wireguard creator it explains everything you need to know about Wireguard in great details.
Maybe if you could explains your use case and how you intended to use Wireguard folks on here can guide you in the right direction.
Consider donating to the project! It's the best way to show your appreciation and make sure the project can continue.
edit: and if you're using it for your business it might be tax deductible, depending on your jurisdiction ;)
Jason, fantastic work as usual. Been using on Win10 (21H1) x64 Pro for Workstations and Enterprise since WireGuardNT 0.1 without issues. Very stable, much better throughput than Wintun (on gigabit WAN), and lower latency. No problems. Tested with multiple endpoints (my own VPS, Mullvad, OVPN, etc) and in 24/7 use.
One thing to consider is why you want to use a VPN. If you are doing things that a government might consider illegal and want to hide it from them, then you should be worried about whether the NSA (or equivalent for other governments) can decrypt traffic and whether the provider is in one of the xxx-eyes countries because it makes it easier to intercept the traffic. In this case you should probably use OpenVPN which has encryption and code that has been audited by security experts. As I understand it, WireGuard has had some auditing done but nothing to the level that OpenVPN has undergone.
On the other hand if you are like me and using a VPN to hide yourself from non-governmental entities (e.g. Google, Amazon, etc) as well as anonymize the traffic through your ISP so they can't throttle traffic based on destination or protocol, or monitor the traffic to use it for advertising, then WireGuard is probably just fine and the VPN being in an xxx-eyes country probably doesn't make a difference. ISPs are not going to have the resources to decrypt WireGuard traffic even if there is a subtle bug that hasn't yet been found in the algorithm. Also commercial entities are not affected by whether they are in a xxx-eyes country or not. For these kinds of issues my opinion is that you should worry much more about whether you trust the VPN service provider or not.
For the record, I have been using WG on Mullvad for quite a while and before that OpenVPN. Primarily on Linux but a little bit on Windows and I have been very happy with it. The primary complaint I had with OpenVPN was connection times. If I suspended my laptop and then restored it, OpenVPN could take up to 30 seconds to restore the connection while WireGuard is basically instantaneous. Throughput is not really an issue for me but I did run some tests and WireGuard is definitely faster.
>The Mullvad/OVPN solution (A) seems intuitive, but it's almost too simple — why does default WireGuard store the mapping for so long if that's not required for "Mullvad-level" performance?
It's not related to performance at all and your guess is pretty accurate.
Wireguard itself is an encrypted tunnel solution, not a privacy VPN solution. If you build a tunnel between two servers it's very reasonable to want traffic to be able to flow starting in either direction. In order for this to happen, both servers need to keep track of the other server's address. Otherwise at least one of them won't be able to ship out new packets.
For a privacy VPN situation you probably only care about traffic in one "direction" (towards the Internet) and that's why there's a need to add these infrastructures that break the bidirectional nature of a persistent tunnel
Official WireGuard App supports exporting "excluded app", which is the "ExcludedApplications" in the configuration file.
ExcludedApplications = tv.danmaku.bili, com.sonelli.juicessh,
com.microsoft.rdc.android
If you need global exclusion, you can use an app called Viscerion.
That's what I was thinking, you're the kind of person who doesn't want to be reflective. By the way, you are recommending right ? I've just browsed their privacy policy page and found that:
>We log customer's IP address, VPN session connect and disconnect time,
amount of traffic transferred. All these session logs are stored on a
secure (fully encrypted) server in a non-disclosed location and are
deleted on a daily basis.
Nice, it's out of 14 eyes but they log, even if it's only on a day basis it's still at risk at any time and should not be logged at all. That's strange that a 14 eyes VPN like Mullvad doesn't log anything, not 14 eyes based VPN a no go ?
What Swedophone said is the way. You then set the default gateway in table 1 to the ip of the wireguard peer on the other end of the tunnel and voila. All traffic for those hosts in table 1 is now going via there.
Tutorial here: https://openwrt.org/docs/guide-user/network/routing/examples/pbr_iproute2
Make sure you set allowedips of the peer on the router to 0.0.0.0/0, but disable the automatic route creation and add a route for the wireguard peer on the other side yourself. You have to set 0.0.0.0/0 because otherwise it wouldn't allow traffic for all ips, but you don't want it to create a default route for the whole system.
And by setting a priority on the routing table lower than the local table your hosts can still talk to each other on the lan.
> Is this how Wireguard works out-of-the-box
No. Wireguard is about creating a VPN tunnel. How NAT is implemented is entirely up to the person running the 'server'.
> I'm using Windscribe's Wireguard VPN.
You are using a VPN provider that does NAT, and the NAT is apparently setup with a range of multiple outgoing IP addresses. It is a way NAT can be commonly configured. At least normal for anyone with tons of clients behind a NAT.
> Is there a way to keep the same IP address for every connection?
Run your own wireguard server on a VPS.
Pay for a static IP? It is apparently something Windscribe offers?
Use a different provider?
> In which case you need the kernel headers for the kernel.
That is the key part right there which you need to do. Then build Wireguard for whatever kernel you have.
Start with something like this:
apt search linux-headers-$(uname -r)
Here is a link that will help: https://howtoinstall.co/en/linux-headers-2.6-xen-amd64
Once you get your kernel headers installed, build Wireguard. See here: https://www.wireguard.com/compilation/
You should specify what OS/platform and WireGuard version you're on. Processor scheduling is very specific to the operating system.
I presume you've read: https://www.wireguard.com/performance/ (top Google hit for "WireGuard CPU scheduling."
On one of My Linux systems I see
540416 ? I< 0:00 _ [wg-crypt-wg0] 962101 ? I 0:00 _ [kworker/2:2-wg-crypt-wg0] 962335 ? I 0:00 _ [kworker/6:1-wg-crypt-wg0] 962337 ? I 0:00 _ [kworker/5:2-wg-crypt-wg0] 962340 ? I 0:00 _ [kworker/7:2-wg-crypt-wg0]
... which are "kernel threads" and should be eligible for scheduling on multiple CPUs. Presumably these each handle some of the encryption/description (perhaps round robin peers assigned to each). There's probably just one thread (per interface) for dispatching the packets to these peer handling threads. So that thread could be the bottleneck if the CPUs are handling the encryption at a high enough rate. But you would have to read the source code (to the kernel patches) to learn how the scheduling actually works.
For example it might be that every thread can handle all peers and the interface dispatcher just round. robins each packet among them. I have no idea what would be more efficient --- for example in drivers with zero-copy then the hardware -> CPU affinity might be better than any SMP gains would be.
You didn't specify your OS, so I'm gonna asume you are using some linux distro.
The keyword you wanna search for is 'network namespace' or 'netns'.
Wireguard's official website has some docs on it, you can adapt it to suit needs.
And what exactly didnt work? Did you check traffic-flow e.g. with tcpdump or wireshark?
I'd create 2 interfqces on the VPS, one for my private net and one for mullvad.
I wont explain how to setup wireguard.. so lets skip to the routing.
Now. it depends on if you want to forward all of your server through muvad or only your VPN-client.
All is a little bit easier. Mullvad-Wireguard-config has to have AllowedIPs = 0.0.0.0/0, this will route everything through mullvad.
Now. you have to enable ip-forwarding in your kernel. Its somewhere in , just google, i wont explain this.
Now firewalling: You need to masquerade the traffic to the mullvad interface, so it always has the mullvad-client-ip.
Pretty streightforward: Add a PostUp to the mullvad-wireguard-config: PostUp = iptables -t nat -A POSTROUTING -o %i -j MASQERADE
And if you need to, set needed firewall rules to allow traffic between the interfaces (i wont explain this, the default is to allow anything anyways, not good, but thats on you)
Egypt. I have tried providers like DO, Linode and the likes as well as NexusBytes.
Mullvad WG used to work a couple of months ago but I haven't had the chance to try it in the past 2 months. It used to vary from one ISP to the other but I mean, at work the IT guy was able to block WG before any ISP did that here.
I believe if Stunnel or something similar could work with WG then it would be more ideal than looking for a provider that hasn't been blocked yet.
Ofc if you know any small provider that I could try let me know.
In my opinion it would be cleaner/easier to manage to have a separate wireguard interface. I recently set this up where my personal devices connect via WG to the OpenWRT router and end up being part of the LAN firewall zone. The Mullvad WG interface is in a separate firewall zone and I actually do not have it set the default route, but rather use the VPN Policy Routing package to only route specific devices/subnets out via Mullvad.
I have tried to get this setup working for so long that I will make sure to post full working configuration once I get it to work, so others don't have to go through this. I have started to also suspect the Mullvad config. Will have to try without those rules and if it works then try to implement them back in a way that I get killswitch but also this setup working.
Thanks. I've just combined bits and parts of several other scripts and added few lines of my own code.
Also to make it clear you want all clients connected to your server to use the PiHole as their DNS? And unlike in my setup, you want local machines to access internet through the VPN as well?
If you only want one process to be routed through Mullvad you should use a network namespace. There's a good explaination on the website should probably be 0.0.0.0/0 since you want to route internet-bound traffic via it.
I'm mostly using wireguard to access my home network from outside. Also used it to bridge services together where communications were not encrypted or where wireguard guarantees faster transfers.
​
You really didn't look very hard, first result when searching for 'wireguard provider' gives you azirevpn. They let you use their wireguard servers for free for the time being to test their infrastructure, so that is cool. Private Internet Access has plans for wireguard but I guess they wait at least until it's upstreamed in the linux kernel.
Yeah, you can read his Mullvad review here: https://thatoneprivacysite.net/blog/mullvad-review/ - which was done before WireGuard was a thing and even then they got the "TOPG Choice" badge (and are actually the only ones to do so to this day according to the VPN provider table).
And also see: https://www.privacytools.io/providers/vpn/
Mullvad's actual primary differentiator is their anonymous accounts - not WireGuard.
I didn’t really understand your question but what you have to do is to install pihole on that server, make it listen on your wg interface, and use that server’s wg IP as the DNS for your wg peers.
You can do that with the DNS entry in the wg config file of each peer.
After that, you can use the command I mentioned above to create new hostnames for each IP.
Or even openwrt - wg doesn't need a lot of CPU oomph compared to OpenVPN for example, so you may be surprised at throughput on a discarded wifi router if you have one lying around that can take OpenWRT.
https://openwrt.org/toh/start search through that for your discarded devices and look for a compatible one. Then check the device page itself though once you find one you own - some devices can be easily flashed from the stock web interface, other need TTL serial, JTAG or a tftp server, to varying degrees of "it's too hard" for a first-time OpenWRT user.
The advantage of using an unused AP or router is low power (and therfore heat), space, the use of spare ports as a switch and possibly extra wifi. Cost (zero if lying aorund doing nothing) is a minor factor in my experience.
Tip: don;t bother with anything that requires a custom build and aim for a minimum of 8MB flash, 64MB RAM even for a experimental test. Fine for playing with OpenWRT for a first install and maybe light-use wg too but better to have 16MB flash and 128MB RAM for future versions of OpenWRT.
To my slight dismay the size of the default mainstream install of OpenWRT is now 8MB ROM/64MB RAM. Dismay because I have access to hundreds of 4/32 devices at my emploi that just cry out for OpenWRT to fix their stock firmware problems. (yes, I know i can build compact images with no GUI, but noone will pay me time for it)
And yes, Raspberry Pi wg instances are very popular, especially when combined with things like pihole or MQTT/smart home packages.
You definitely don't need beefy 19" rackmount servers with multi-processors and banks of RAM :) a 400MHz single core and 64MB RAM is a workable wg solution for anyone on ADSL or slower VDSL on OpenWRT in many cases.
Don't go crazy or spend beer money. The world is in a crisis. Beer is a vital resource so use it wisely.
Clients (not only Wireguars, but in general) prefer IPv4 over IPv6 if the only address they have is a ULA. You should assign GUA addresses inside your VPN instead, without masquerading.
Linode's website says that you can request a routed range:
> Additional IPv6 Addresses
> If a single IPv6 address isn’t sufficient for your application, additional IPv6 addresses can be requested by opening up a support ticket. Additional IPv6 addresses are provided through large address blocks, also called routed ranges or pools. From these ranges, you can manually configure individual IPv6 addresses on your Linode. See the Linux Static IP Configuration for instructions.
I wasn't suggesting to give up DoH or to use a wrapper.
With the first suggestion, I guess HTTPS certificates could be an issue like you suggest.
With the second one, verification of the HTTPS certificate still might work. My guess was that 1.1.1.1 would only be used to resolve DNS.adguard.com. Then all further DNS lookups would go through that with DoH. But this is just guessing!
I don't know what app you use for your DoH setup. Is it just certain apps such as Firefox, or a system-wide DNS setting? Desktop Firefox DoH seems to work for me behind Wireguard (with DNS set to 1.1.1.1 in the Wireguard client config).
I just learned that there is actually both DoH and DoT, and the second only requires an IP. That might be an option for you too.
I use Tasker with microg without issues. There are some actions for integrating with Google Drive that I personally have no use for, and therefore haven't tested, but I'm fairly certain they won't work.
Yeah that should be possible, but not with only setting up Wireguard configurations. Routing comes into place with this setup. You could try to tackle this with policy based routing (PBR).
On the VPS:
echo "200 vpn" >> /etc/iproute2/rt_tables ip route add default via <home_wireguard_server> dev wg0 table vpn ip rule add from <vps_wireguard_client_subnet_or_ip> table vpn
Command explanation:
With the 1st command we create a new routing table called "vpn".
With the 2nd command we add a default route to route every traffic in that routing table to your home wireguard server
With the 3rd command we add a matching pattern based on the source address (from
) to put the traffic in the correct routing table.
There are also other ways to tackle this, but I'd do it with PBR because I'm familiar with it.
​
Edit: other ways to do it: https://www.wireguard.com/netns/#routing-all-your-traffic
I believe the easiest and most secure solution would be to use namespaces. Adding different interfaces into namespaces makes it easier to separate the different interfaces as well as make sure the users traffic doesn't exit in any other than your wireguard.
You could follow the steps here: https://www.wireguard.com/netns/
​
Here is a basic example of a setup on your Raspberry (I haven't tried this out myself like this time but I have a similar setup at home):
ip netns add physical ip netns add wg0 iw phy phy0 set netns name physical ip -n physical link add wg0 type wireguard ip -n physical wg0 link set wg0 netns wg0
ip netns exec physical dhcpcd wlan0 ip netns exec physical wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf # or wherever your wlan config file is... ip netns exec wg0 wg setconf wg0 /etc/wireguard/wg0.conf ip netns exec wg0 ip addr add 10.2.4.5/32 dev wg0 # insert your ip address here, you have to disable that line in your wg0.conf file as well ip -n wg0 link set wg0 up ip -n wg0 link add eth0 ip -n wg0 link set eth0 netns 1 ip route add default dev eth0
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -I POSTROUTING -t nat -o eth0 -j MASQUERADE
Now everything coming in from eth0 is passed via wg0 which is going through your wifi connection.
> WireGuard configs are pointed to a vpn.domain.name address and work perfectly fine outside of my own LAN but will not connect inside which i kinda expected.
Actually, this should be working fine. If you don't run WireGuard on the router but rather a separate device - I imagine it has something to do with your port-forwarding only happening on the WAN interface. You should debug where the routing is going with this.
> Is there any way of making this scenario work automatically outside of me grabbing their tablets every time we leave and turning on WireGuard?
You could use the Tasker integration, so that WireGuard activates when you leave your home WiFi network.
>Next question i have. I believe i understand how the authentication works with the two public keys in the config.
The config has your client private key and server public key to be able to encrypt packets for it.
> Basically they are verified by the private keys on the server?
Likewise, your server only has its private key but the clients public keys to be able to identify them.
> Interface being first? Then peer inside tunnel? Can someone break down this better for me? Im more curious then second guessing anything.
I would suggest reading the "Simple key interface" section of the home page.
> [...] Debian
Did you follow https://www.wireguard.com/install/#debian-module-tools ?
Can you find the latest version on the mirrors? It's a pure maze to navigate, so I have no idea where to look for it.
Is this your server instance? Just create the device and set an ip address manually.
Look at this link for details:
I recently had a problem with a free wifi hotspot. They blocked UDP traffic.
I found out by switching to OpenVPN in the Private Internet Access app (from Wireguard protocol). This didnt work, so I switched OpenVPN from UDP to TCP and it instantly started working.
Maybe this is your problem too?
Local Routing and Wireguard are separate items. The host and docker containers should already be able to communicate before setting up wireguard. The only routing needed when wireguard is up is changing the default route to send outbound traffic through the VPN. Presuming your transmission container has it's own IP on the local network of 192.168.1.14 the iptables DNAT line is the only additional thing needed to setup port forwarding on the local machine. Having incoming port forward working from the internet requires that Torguard is either giving you a public IP address as your wireguard local endpoint address or is forwarding the ports of a public IP address to your given wireguard local endpoint address.
If you had a working port forward setup on this same machine/setup with openvpn and wireguard is the only change, the issue is likely on the Torguard side where they are not sending traffic for a dedicated ip address to your wireguard endpoint.
I gotta keep it short for now. I'll maybe later add some more explanations...
Try this: add the following lines to your config:
PostUp = ip -4 rule add from xxx table main PostUp = ip -6 rule add from yyy table main PreDown = ip -4 rule del from xxx table main PreDown = ip -6 rule del from yyy table main
where you replace "xxx" with the public IPv4 and "yyy" with the public static IPv6 you got assigned to your "real" internet-facing network interface.
This should reestablish TCP connectivity.
Btw: To make sure outgoing traffic goes through Mullvad, you would add some kind of kill switch rule to your firewall. Be sure to not block outgoing packets that belong to an incoming connection.
Also checkout network namespaces. You could isolate things this way.
You can flash something custom like OpenWRT
GL-iNET has several small travel routers that come with WireGuard client and server software built in. I have one and it works ok, but the speed of the client is slower than if I had the client turned off on the router and used the WireGuard client from my computer's operating system instead. Of course, to use the client, you'll need a server to attach to, therefore you'd need to set up your own Virtual Private Server (VPS) on a hosting platform/cloud service somewhere or get a service like NordVPN or Mullvad that supports WireGuard.
Huawei E3372h-320 (2020), LTE/4G 150 Mbps USB Dongle, Unlocked to any network, (Genuine UK Warranty stock)- White https://smile.amazon.co.uk/dp/B085RDTZMP/ref=cm_sw_r_cp_api_glt_fabc_VP64Q53MYGNMBJRP8DSB
I personally have not tried this, but it's just a matter of forwarding all traffic from your wireguard server and to a wireguard capable provider. Like Mullvad. I bet there is someone on r/homelab whos done it already.
I can saturate a gigabit connection using PIA wireguard. Its nuts.
They support basically every device you can think of.
Pay for a VPN service, like Mullvad
Follow their instructions to get CONF file
Look for VPN options on phone to enabled the required VPN for everything
Continue paying for service
For the Mullvad client you'll want to follow these instructions: , create a new private/public key pair, get IP to use with Mullvad, add WireGuard interface. When adding the WGInterface do not enable "Route Allowed IPs", you'll probably need to use a different WG listen port than default 51820 as I suspect you may have already used that for your other WG interface. You'll want to install the packages "luci-app-vpn-policy-routing" & "vpn-policy-routing". You'll probably need to reboot the router before the new wireguard interface comes up. Then in the new "VPN->VPN policy routing" menu define which LAN-clients/subnets you want to route out through the new WG interface. All of the packages work with 19.07.x
Not yet possible in the general sense. In some specific cases, sure: I have a Mullvad WireGuard tunnel setup on my router, and use their SOCKS proxies along with Firefox's Container Proxy addon to send just certain sites or browser tabs through it. I also set the IP TOS field in Transmission and use policy routing to send all torrent traffic through the same tunnel (again, on my router.)
I looked at what would be involved in implementing something app level a couple years ago, and while it's definitely possible via the old NKE API, NKE was already being deprecated in favor of the new NetworkExtension API so seemed like a waste of effort. At the time, "per-app VPN" was an iOS-only concept in NetworkExtension; looks like the docs now say it's also possible for Mac App Store apps[1] so maybe there's been some progress on that front, not sure.
\1] [_tunnel_provider
Here's my test, from South East USA to Montreal via Mullvad. The only noticeable dip is with latency. So bad for video gaming, more than fine for literally everything else.
WG STATE | LATENCY | DOWN | UP | PACKET LOSS |
---|---|---|---|---|
ON | 50 | 248 | 23 | 0.00% |
ON | 51 | 230 | 7 | 13.50% |
OFF | 9 | 274 | 11 | 3.30% |
OFF | 9 | 248 | 23 | 0.90% |
Glinet makes travel routers that run Wireguard. They're a bit more professional than a raspberry pi.
https://smile.amazon.com/dp/B07GBXMBQF/ref=cm_sw_r_cp_apa_i_UC4MFbD9TKNKG
I gave a few of those out to employees, they create a wireless network that connects them straight to WG. You can also hard wire them. It's not a bad setup.
There would not be an open port on my router, but an open port on my VPS server that forwards all connections to my server at home through the VPN tunnel. Same way that Mullvad's port forwarding works where you can make a service accessible over WAN through the Mullvad server's IP which would open a port on the server, but without opening a port in the home router
My main purpose of using VPN is to be seen as if I live in certain country, ideally live in the same location using same or similar IP. I sometimes travel and I want to avoid being locked out by certain sites, including Google. Lol, you won't believe, but I lost access to several of my gmail accounts in last 6 months or so. Google just blocked access to them even if I give the correct password, because I didn't have a phone number registered with it before I changed my IP. From this year, Google started going after people who use VPN with random IPs and those who have multiple gmails, and don't use two factor authorization (as always, they want to know more about you as easily as possible, your current phone number, your other emails, your real IPs so make it easier to spy/sell data or track you). Because of losing access to my gmails, I cannot access the accounts in various sites any more, I have to create new accounts. Now, I'm trying to switch to other email providers, kind of diversifying.
Another reason is that my paid VPN's IPs started to have bad reports, I guess, and many sites I use started to verify me before giving access. I never had this many issues with them in the past and I don't think it will resolve in the future. I'm using ExpressVPN. You can imagine how bad it is with other paid VPNs as ExpressVPN is top-notch (I tested most of them, telling from my experience)
Also, when it comes to casually accessing sites from random locations, I don't think I would pay for such service. There are free VPNs that provide access from many random locations around the world when you want to hide your identity. To be even more secure, I would use Tor. But my purpose is quite opposite.
Anyway, I'm just experimenting with own VPN. I may not end up switching, but it's good to know my options.
Here's my conf for a Raspberry Pi client connecting to Mullvad servers:
>root@rpi:/etc/wireguard# cat
>
>[Interface]
>
>PrivateKey = xxxxxxxxxxxxxxxxxxxx
>
>Address = 10.11.11.11/32
>
>DNS = 193.193.193.193
>
>PostUp = ip route add 10.10.0.0/16 dev eth0
>
>PreDown = ip route del 10.10.0.0/16 dev eth0
>
>[Peer]
>
>PublicKey = xxxxxxxxxxxxxxxxxxxx
>
>AllowedIPs = 0.0.0.0/0,::0/0
>
>Endpoint = 11.11.11.11:51111
​
The important part:
>PostUp = ip route add 10.10.0.0/16 dev eth0
>
>PreDown = ip route del 10.10.0.0/16 dev eth0
​
Pretty much all the IPs have been replaced, not that it matters to you. In this example, my private network would be 10.10.0.0/16, but for anyone who might be finding this example via search engine, it's 192.168.1.0/24 for most people.
I've automated wireguard with tasker. But not with the official wireguard client. Use Viscerion instead. https://play.google.com/store/apps/details?id=me.msfjarvis.viscerion
So I understand is that you use a VPN provider, say NordVPN, but can view your local devices when away from home when connected to Nord?
When home you have changed on the physical devices to use your PiHole DNS but connected to as an example NordVPN?
I do not think this is possible away from home, this would be a dns leak if the provider let you use another dns that is not theirs. The whole point of the VPN is to not let any information out.
I do not think it matters how many allowedips you add there is no routing to your home network when outside of your home network since this is a 3rd party VPN service.
You would need to setup your own VPN at home for this to work.
>I guess I need to add a firewall rule on OpenWrt, but I couldn't figure out how to do it correctly.
The guide uses masquerade since I guess you only get one usable IPv4 address from Mullvad. You would need to add a port forward as usual on OpenWrt in this case. You can also use tcpdump to check if you receive any traffic on the port. tcpdump -i wginterface -n port <PORT>
Mullvad ( offers wireguard service and I haven't seen anything bad about their privacy policies. I've been using it for a few months and haven't run into major problems. They have a pretty simple setup and it seems to just work. It's 5 Euros a month for up to 5 clients.
No worries. Yeah you're right, some of the privacy VPN's have various implementations of split tunneling. I think Mullvad is another. Some of them seem to only allow you to exclude applications from the VPN tunnel.
TunnlTo allows you to add your own WireGuard server and alternatively you could add your existing privacy WireGuard VPN profile to TunnlTo as some of them allow you to download the client config.
Hmm interesting. I have been doing some digging to see if there are any reports of DNS leaks when using the NextDNS app. From what I have found when setup correctly (NextDNS) it should actually do what it says and route all DNS to them. But you said this is what you already did?
I did find a few posts from people saying they were seeing DNS leaks, and the one thing they all had in common was using NextDNS in conjunction with a VPN app.
I would suggest trying one piece at at a time. In your Settings, disable NextDNS completely, and then also remove all VPN profiles created by Mullvad. For good measure uninstall both apps.
Re-Install only NextDNS, and get it setup properly. Then use just that for a bit and verify if its working correctly. According to several posts and articles you should not see any leaks. I usually use to help.
(Also worth noting if you see "Misaka Network, Inc" when doing a leak test that is ok. They are one of the datacenters used by NextDNS)
Once your confident that NextDNS is working correctly, then re-install Mullvad and set it back up. If the Mullvad app has DNS settings, then of course try and set it up the way youd prefer first. If it works great.
If you start seeing leaks again, then the first thing I would try is seeing if there is an option to use the systems DNS (which should now be nextDNS anyway). This would "technically" mean you'd be leaking all DNS traffic outside of the VPN tunnel. However, I'm not sure it would matter too much in this case since NextDNS uses encrypted DNS. Though this would mean NextDNS would see your IP instead of your Mullvad your already trusting Mullvad with your IP anyway. I assume the goal is preventing your ISP from seeing your traffic.
I chose the way of installing the NextDNS app and using it thur system wide dns implementation. Then add Mullvad thru Wireguard configuration.
I used the Mullvad app and use the vpn with NextDNS in the dns option they let you use. But it would not be on demand like Wireguard does for some reason
I mentioned this below, but there is a known bug in iOS that can cause this to happen. That may very well be your issue. Link here for the report.
But you mentioned that your using NextDNS. Im curious, did you setup NextDNS in the Mullvad app or did you install the NextDNS app? Im not familiar with Mullvad, but many other VPNs allow you to select your preffered DNS in the app.
If you only selected NextDNS in the Mullvad app, then that will be the DNS that is used for any traffic that goes through the VPN. But I would imagine that any traffic that happens to sneak around your VPN will still hit your iPhones default DNS provider (likely whatever your ISP/Carrier provided).
But if you install the NextDNS app it will change your iPhones DNS server system wide. I wonder if that would possibly help with the leaks? This way the VPN is using NextDNS, but any traffic outside the tunnel should also be using NextDNS too. You'd still technically have a DNS leak, but at least the leaks are going to the same DNS server.
Im actually interested in knowing because I've been considering using NextDNS myself.
What remote device are you connecting to your home network from? Android phones don't allow multiple VPNs to be active concurrently. A laptop with Linux should be just fine - the Wireguard tunnel to home will go via the Mullvad tunnel to the internet. I don't have any Windows or Apple devices so I've never tested those.
You can also configure Mullvad (Wireguard) so that it ignores certain IP address ranges, but the configuration gets pretty complicated.
That's a good reference link, thanks. I am currently trying to set up a connection to Mullvad from the home router, but I will also setup a server to access the home network later. Doesn't seem to cover performance issues though.
Since you are connecting to a VPN service which means that the Allowed IPs must be set to 0.0.0.0/0. This puts the wireguard network interface as the default route for all the network traffic. We expect this issue to happen if you ssh remotely (outside your LAN) because the incoming and outgoing interfaces get mixed up. However, in the routing table, local LAN usually has a higher priority than the default route, so this issue shouldn't happen (unless you have modified the routing table yourself).
On the other hand, you have added those iptables rules, which seem to reject the traffic from LAN. Why did you add these? Is it part of Mullvad config? Can you try again after removing these rules?
I switched from, um, forgot, to Mullvad and have been very happy there.
I don't know if WG can log to be sure what is going on. I just know from their side they were killing my sessions after XX minutes of idle.
Create a Wireguard config on the Mullvad page to download and be used with wg-quick
.
Then, add
FwMark = 1234
to the interface section of both your configs (Mullvad+VPS).
This takes advantage of the policy-routing that wg-quick
installs in case there's an AllowedIPs = 0.0.0.0/0
. Now, the UDP packets created by both Wireguard interfaces will bypass any new Wireguard default routes.
When using the Mullvad CLI:
default via 192.168.1.1 dev enp5s0 onlink10.0.0.0/24 dev wg0 scope link10.64.0.1 dev wg-mullvad proto static172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown172.18.0.0/16 dev br-c0cac759d359 proto kernel scope link src 172.18.0.1172.19.0.0/16 dev br-752cef9954f6 proto kernel scope link src 172.19.0.1 linkdown172.20.0.0/16 dev br-9739ec2cea95 proto kernel scope link src 172.20.0.1 linkdown172.21.0.0/16 dev br-6f6fef3d36ea proto kernel scope link src 172.21.0.1172.23.0.0/16 dev br-a3c61d5d4779 proto kernel scope link src 172.23.0.1172.24.0.0/16 dev br-c0e28d548ebc proto kernel scope link src 172.24.0.1 linkdown192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.123192.168.160.0/20 dev br-008cb222ecff proto kernel scope link src 192.168.160.1
(wg0
is the config for the VPS)
---
Using a Mullvad-provided Wireguard config:
default via 192.168.1.1 dev enp5s0 onlink10.0.0.0/24 dev wg0 scope link172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown172.18.0.0/16 dev br-c0cac759d359 proto kernel scope link src 172.18.0.1172.19.0.0/16 dev br-752cef9954f6 proto kernel scope link src 172.19.0.1 linkdown172.20.0.0/16 dev br-9739ec2cea95 proto kernel scope link src 172.20.0.1 linkdown172.21.0.0/16 dev br-6f6fef3d36ea proto kernel scope link src 172.21.0.1172.23.0.0/16 dev br-a3c61d5d4779 proto kernel scope link src 172.23.0.1172.24.0.0/16 dev br-c0e28d548ebc proto kernel scope link src 172.24.0.1 linkdown192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.123192.168.160.0/20 dev br-008cb222ecff proto kernel scope link src 192.168.160.1
Other than PIA and Mullvad, I have tested WireGuard on 3 different VPSs from different providers in Germany on 3 different ISPs and 3 different data centers in Iran and none of the 18 combinations worked. Talked to a support person from one of the data centers in Iran and they confirmed it's an infrustructural type of firewall.
I also have this same issue! I have NordVPN running in docker, and was trying to VPN to docker at home from outside to have access to the local network and would love to benefit from the running VPN too!
Where you able to find a way to do it?
You could go with something like this https://www.amazon.com/-/en/dp/B082VZP76P/ It's fairly low power consuming but has more than enough horse power for your needs. I run my WireGuard Server besides several Docker Containers on it and the through put is really good.
Used business micro form factor PCs from Dell, HP or Lenovo are in the same price range from Amazon and of course eBay.
Things like this: https://www.amazon.com/Dell-OptiPlex-i5-6500T-Certified-Refurbished/dp/B079G4T9PF/ref=sr_1_8?
Nice. Thanks a lot. So using Mullvad GUI for connecting to server is fine and it automatically uses wired guard? Or doni open WireGuard and use one of their servers without touching Mullvad? Mullvad shows list of countries/cities but WireGuard only shows servers with letters/numbers that I don’t really understand what I’m connecting to. Obv the first 2 letters are the country so I default to anything with US in the beginning. That the best way to do it? Also, my vpn hardwired speeds are about 4-500. Which is great but obv half of what non vpn is. Regardless, it’s only being used for torrents and my downloads in Qbit are only like 10-20mpps or so. Even with hundreds of seeds.
Also. Kind of different topic but I’m wondering exactly how to use a hardwired Xbox to connect to vpn occasionally when wanting to mess around with some “bot lobbies” for fun. I’d obv use vpn on router correct ? If so, vpn WireGuard toggled on? Or vpn fusion? I do NOT want any other hardwired Ethernet devices to go on VPN; it’s unnecessary and I feel it can mess things up like steaming off Nvidea shield, my Plex server or my NAS. I have a lot of stuff on my network and smart devices too (hue and Arlo bridge) are hardwired to Ethernet as well.
It was a 2 hour pain to get some of these IoT on then network once I upgraded to the AX-88u router.
Obv the router is more than what I thought I’d be getting compared to my 3 year old amplify HD (which was relatively ok) but the ASUS blows thing thing out of the ballpark, especially with range of 5g network in my 2 story house.
Sorry for the extremely long winded reply, just had cold brew lol
I suspect u/yes_control_group also wants to access local resources on the home network.
Otherwise I agree, it makes a bit more sense to just pay Mullvad 5 euros/month for a solid vpn if the only use case is safety on public wifi.
This is exactly how I did it. Piehole and wireguard on a raspi while the raspi was the client of Mullvad. Additionally, this bypasses the connection limit of Mullvad since technically it's always only one.
Seeing the same issue here. I haven’t customised any of the settings, so persistent keepalive is off. Whether I’m connecting to my home VPN or Mullvad, I see the same sort of battery drain across different iOS devices.
Nextcloud server is on my desktop, implemented in a separate virtual environment. My VPN is a paid subscription (IVPN) with the wg0 interface also in a separate virtual environment, which I use on my desktop as a gateway to the outside internet. I can make as many wg interfaces and/or VMs as I need to on this machine.
However, it's my cell phone client that I'm uncertain about. I already have my VPN on this device through wireguard (same usecase, all my traffic is tunneled through the VPN). I read that you can't have more than one wg interface on Android (GrapheneOS) without going root level.
So my idea then, was to add a second peer to the wg interface on the cell phone, with an Endpoint IP at my home desktop. That's still not ideal, because I would prefer that all my traffic tunnel through the VPN first. Hypothetically, I could do one of the following ... - Set up ssl on my Nextcloud server without wg, and maintain my existing VPN tunnel - Stop using wg on my cell for the VPN, and use it only for Nextcloud. - I might also have the ability to use the multi-accounts feature on Graphene to create a series of gateways.
I'm under the impression that Wireguard is a superior form of tunneling and encryption than OpenVPN or SSL. I also enjoy the simplicity and modularity of key management. For these reasons I'm trying to use wg for both.
Thanks for the supplementary info.
> Why do you feel you need a separate interface? ... I'm not familiar with ivpn, but do they have their own app?
They do have an app, but like any properly implemented Wireguard VPN, it's not required and you can use the Wireguard client. I prefer to use their app, because of the convenience of viewing/switching servers, and a few extra options it offers.
IVPN is awesome. Top notch documentation on VPNs and privacy/anonymity. Very honest about limitations. They were also the first provider to accept Monero. I've had Mullvad as well, and I think technically their specs are slightly better, but extra lengths IVPN goes to, to help people understand what a VPN can/can't do, just gives that extra confidence that they're the least likely out there to be a honeypot. Altho Mullvad has good rep as well.
> Not sure if you can support multiple concurrent peers on android wireguard
You can, I've already been playing with the official Wireguard Android app.
> What about purchasing a VPS and setting up a Wireguard server there?
I've considered it, but I'd prefer to avoid if possible. Extra costs, manual setup/maintenance, potential lack of robustness/redundancy in the case of outages.
I'm thinking now, that I'll try to play with the routing tables on the client side. See if I can route the Nextcloud peer info, to the IVPN IP address.
I still have the same Issue , No IP Forwarding
If i manually edit the IPs at the Devices i want to use the VPN , do I need to use the Mullvad DNS ? Because I used 8.8.8.8 or doesnt matter?
Well perhaps I spoke too soon! I regenerated the ProtonVPN config and reinput the config into OpenWRT and everything seems to be working now!
And Yes, the ProtonVPN DNS needed to be added as Pihole's upstream DNS
If your PiHole is behind the OpenWRT router and uses it to access the internet, when you configure Proton VPN, it will start using it to access the internet, so you should configure PiHole to use Proton VPN's DNS.
However, I'm not sure that once you setup Proton VPN, the OpenWRT router won't be able to talk to your iPhone. I'm not 100% sure on how to make a routing rule to allow the WireGuard interface your iPhone talks to not use ProtonVPN but use your native internet connection, but you are going to need to do it.
Hey there, I'm having the same issue. Also trying to get Wireguard to run on my RPi with LibreElec, and by the looks of it your VPN provider is also Mullvad. I setup a mullvad.config file exactly as you did, and stored it in /storage/.config/wireguard/ on the RPi, but after rebooting the RPi I don't see any new VPN service when I enter command "connmanctl services":
LibreELEC:~ # connmanctl services
*AO Wired ethernet_b827ebe5f984_cable
​
Did you figure it out in the end? Any help would be appreciated.
Hi,
The best way to do this would be to set up two wireguard tunnels.
That would be the best set-up, I know it's possible there's some writeup on the net.
Sorry I can't help on your specific case, hope you will find my comment somehow useful.
So you would need the Mullvad server config to look something like:
[Interface] Address = 10.10.0.1 PrivateKey = <server's privatekey> ListenPort = 51820 # you will need to forward this port (UDP) on your router
[Peer] PublicKey = <client's publickey> AllowedIPs = 10.10.0.2/32, 192.168.1.0/24 #AllowedIPs = 0.0.0.0/0 would also work
Without something like that there is no reason for the Mullvad server to route other traffic over that peer connection.
There is a way to do this for free.
Oracle offer a free compute server which you can configure to run PiVPN wireguard on a static IP and then you can edit the configs yourself. No Mullvad subscription required
No, not that I'm aware of. The config I provided earlier is the only thing that's visible.
But wouldn't it be possible to somehow have the Mullvad config. as-is, and then redirect the incoming traffic from that peer to a separate WG instance? Or is that not how it works?
Thanks for the detailed response!
I realize now that my wording was a bit off; I'm actually behind CG-NAT, so I don't have a static/public IP address _at all_. Mullvad allows me to forward a port from one of their public URLs to my server - which requires me to have WG set up on it. This in effect gives me a "public" IP. DDNS then helps with the fact that the Mullvad URL might change from time to time, though.
The config from Mullvad looks like this:
```
[Interface]
PrivateKey = <my Mullvad private key>
Address =
DNS = .x.x
[Peer]
PublicKey = <my Mullvad public key>
AllowedIPs = 0.0.0.0/0
Endpoint = :51820
```
What I'm wondering is how I can get the config from Mullvad to work with a config similar to what you provided?
(Sorry for the vague/broad questions. I'm really a noob at this stuff...)
This is why people use VPN services. The torrent can be tracked to the VPN provider’s IP. A good provider then has no logging (and the better ones no customer info even like Mullvad) of their customer IPs so things can’t be traced through them.
I guess you solved it already.
The problem seems to be that you don't have a more specific route(s) for your VLAN(s) in the main routing table which is why the default route is used for this and with Mullvad you basically installed a second default route.
The alternative to changing the AllowedIPs is to just add a more specific route to the main table since this has priority over whatever table 55111
contains (you've set it up like that using ip rule
).
Not an immediate answer to your dual-WireGuard setup - but an alternative to think about:
I also wanted to access my home machines easily whilst being on Mullvad and what I ended up doing was just creating an SSH jumpbox at home with public key authentication... on IPv6.
Every single Mullvad server has IPv6 connectivity - literally pick any server of theirs and SSH right into your home. Just need to check if your home ISP has support for it too.
Wireguard isn't a free VPN, it's a VPN protocol.
I think you are comparing something like NordVPN with wireguard which is not the same thing.
Wireguard is the programing a VPN sits on top of. So for example, NordVPN uses wireguard as its back-end system, You pay NordVPN money. You get their app and it makes a wireguard connection between you and their servers.
Or the case what a lot of people use it here for is to get home whilst out and about. I have a wireguard server at home and I use the Wireguard app on my laptop to get home when i'm not, so I can access all my shit OR im on something like cafe wifi and I don't trust it I can tunnel home. However, If I torrent its like I would be torrenting on a computer at home.
Also worth noting, With wireguard you can consider it in 2 parts.
First part is the back end support. This is all the code that makes it work.
The second part is the GUI. This can be the Wireguard app or even a 3rd party company like NordVPN that use the wireguard protocol wrapped up in their own app. They will still use the same backend code that is baked into the Linux and Android kernel, just a different front end.
​
comparing to cars again, It's like the Toyota GT86 and the Subaru BRZ. They are both the same car with the same Engine, same chassis, same transmission etc (backend code) but the have a different body kit and paint colour. (Front end GUI)
I used wireguard and it worked fine. I've also used ExpressVPN as a backup when I first set up wireguard and didn't trust it if it would work or not and that one worked too. I have wireguard setup on a raspberry pi 2 at home and went to a heavily monitored and sanctioned middle eastern countries and they both worked. I was even able to join video calls on Hangout but without my own cam turned on (internet wasn't fast enough).
I feel like I know where you might going to haha
This is where the point about lots of VPNs accepting crypto comes in. Mullvad would be an example. They don't require any such information.
As for the routing, I say client side only with good reason. What I'm essentially doing is setting up three VPN gateways (as docker containers) that all use each other as their internet gateways. That way we're connecting to wireguard via wireguard via wireguard. So no need for server side config.
You can only download as fast as the sender can upload, but the client's upload is irrelevant here. So in OP's case, with 300/300 in the US, his download limit from any client in Europe (or anywhere else) would be 300Mbps. That being the upload of the peer sending the data. The 40Mbps doesn't factor into the equation, unless he's trying to upload data back through the tunnel.
For example, at home I have a 1000/50 connection. Running WG as a server at home and connecting to it when away, I can 'download' on the remote device at up to 50Mbps (the sender's upstream limit). However, when running WG as a client at home, for example connecting to Mullvad, I can download at 1Gbps because that's my download limit, and Mullvad have 10Gbps servers which can saturate my line. I hope that helps clarify things.
Basically, a packet leaving Wireguard and going out on to the internet adds 40 bytes + 20 bytes for IPv4 and 40 bytes for IPv6. So you should look at the interface through which you're connected to the Edgerouter and subtract 80 bytes, or 60 if you're sure you'll never connect over IPv6.
1420 is based on the standard MTU of 1500 minus 80. It's possible your MTU is lower if you're connected over PPPoE and your ISP doesn't support RFC 4638, for example. I'd expect Mullvad is taking another 40 just to play it safe, not many network conditions would have a bare MTU of lower than 1460.
>Why does Mullvad set theirs lower?
Some cloud environments use MTU lower than 1500, which means WireGuard should be configured with MTU lower than 1420 (dual-stack ipv4/ipv6). You should ask Mullvad for their reason.
I use IPv6 in IPv4 (6in4) which adds an additional IPv4 header (20 bytes) myself, which means I need to use MTU 1400 with WireGuard
For posterity, since this post shows up in search results, you can allow LAN access when using Mullvad Wireguard configs by modifying their PostUp
and PreDown
iptables rules sections:
PostUp = iptables -I OUTPUT ! -o %i ! -d 192.168.1.0/24 -m mark ! --mark $(wg show
%i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables
\-I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype !
\--dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i ! -d 192.168.1.0/24 -m mark ! --mark $(wg show %i
fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D
OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype !
\--dst-type LOCAL -j REJECT
The key change here is ! -d 192.168.1.0/24
, which will ensure the iptables rule does not REJECT
packets destined for LAN addresses of the form 192.168.1.*
. Modify as needed to suit your LAN IP ranges.
So can you verify that the DNS server is getting set correctly when you're connected to the Wireguard network? I'd assume that you'll be able to see that in settings under the network configuration. I'm not as familiar with Android but maybe something like a DNS lookup app might help troubleshoot by being able to try some manual lookups to your DNS server when connected to see the output. I found this app when googling so no idea if it really works but the full response would be useful when doing a lookup against the DNS server. That should tell if it is a wireguard connection issue or if the client can talk to the DNS server and is just getting rejected.
I’ve got my pfSense box on Virgin Media in UK connected to Mullvad WireGuard VPN and I get about 400Mbps download from a 1Gbps Virgin Media connection. I suspect I’d get more but I think my pfSense CPU is my bottleneck.
I hadn’t heard VM didn’t play nice with UDP and this surprises me.