Wireguard Client Router Setup Help

[LIGISTX]

I am attempting to set up an Ubuntu server wireguard VPN client router via a VM under ESXi in my homelab to better understand how this works; eventual deployment would be on my raspberry pi to allow devices connected to said pi to be routed through the VPN; basically a portable router that forces every device connected to it to be routed back to my server (also lives on my homelab) used when I travel for work. For current testing, I have a Ubuntu server VM set up at a family members house so I can have an alternate public IP to verify things work as expected.

Test setup:
Local LAN - 192.168.1.1
WG Server - 10.0.0.1
Virtual LAN for testing within my homelab - 192.168.2.1
Remote LAN 192.168.86.1
WG Server on an Ubuntu Server VM
WG Client on an Ubuntu Server VM

I have a wireguard connection set up, handshakes, public IP shows correct on my WG Client

Current server setup is:

 

[Interface]
PrivateKey=<server-private-key>
Address=<10.0.0.1>/<8>
SaveConfig=true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <eth0> -j MASQUERADE;
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o <eth1> -j MASQUERADE; 
ListenPort =51820

 

 

Current client setup is:

[Interface]
Address = 10.0.0.2/8
SaveConfig = true
ListenPort = xxxxx
PrivateKey = xxxxxxxxxxx

[Peer]
PublicKey = xxxxxxxxxxxxxx
AllowedIPs = 0.0.0.0/0
Endpoint = <server's IP><Port>
PersistentKeepalive = 30

 

Once I have wireguard set up and working - which I do believe it is, its pretty easy to set up based on the above, I moved onto setup of my secondary interface which will be 10.0.0.2 and will receive DHCP and use the router I set up within the WG Client VM. I set this up via: https://medium.com/@exesse/how-to-ma...ts-fd40b7bfec9

With this second interface working, I spin up an ubuntu desktop VM on my homelab connected to the same virtual network as the WG Client second interface is connected to, DHCP works as expected, and I am even able to get iffy internet on the ubuntu desktop VM. I can google things, I can watch youtube, but things just don't quite work right, I can't download and install chrome for example, it tries, it hangs, it tries some more, but just doesn't really work. Speed tests do run very near line speed though...

I assume packets are not being routed through to the wireguard interface correctly, or something somewhere is not being translated. I though the "allowwedIP's being 0.0.0.0/0 would mean all traffic through the WG Client would be forced over the WG interface, but that is proving not to really work. I have tried some random iptables settings as well, but nothing really changes anything. I have seen the fact wireguard works with namespaces, but I am not quite sure how that works or how I would set that up for my needs. I know enough to know enough, but clearly not enough to get this working as intended.

Any ideas, or guides that could be followed for this exact situation? I have been at this for a couple days now and just can't get my head around it.

[heimdali]

Is it a good idea to have the VLAN in the same network as the server?  What is the masquerading actually doing in this case?

 

[LIGISTX]

1 hour ago, heimdali said:

Is it a good idea to have the VLAN in the same network as the server?  What is the masquerading actually doing in this case?

 

If I understand the question correctly, the vlan is just for testing on the simulated "away from home" network. The wireguard server is at a physically separate location, and I have a wireguard client and "simulated ubuntu desktop device" on the same vlan to test if my routing is actually working. The client and the server are on two different public IP's, in physically distant places. Hopefully that makes sense.

 

Basically, I flipped my entire deployment around for testing purposes. I am connected to a server outside my house, with the simulated "away from home" setup running under ESXi.

[heimdali]

It just feels not right that the server and the VLAN should be on the same network, especially considering the masquerading.  And shouldn't the masquerading be on the same interface?  Like I don't see why PostDown would remove masquerading from eth1 after it was put in place in PostUp for eth0.

 

What if you fix the interfaces for masquerading and put the VLAN on a different network?

 

[WereCatf]

4 hours ago, LIGISTX said:

<10.0.0.1>/<8>

That should probably be /24, not /8. I mean, you're reserving the entire 10.x.x.x for the wg-interface?

 

4 hours ago, LIGISTX said:

10.0.0.2

This is probably the reason for your issues. I mean, the wg-interface already defines a 10.x.x.x - network and now you set up another one in the same address-space?

4 hours ago, LIGISTX said:

Address = <client-ip-address>/<subnet>

Just to clarify this one: it should be a /24.

[heimdali]

What's the difference between 10.0.0.1/24 and 10.0.0.2/24?  Or 10.0.0.1/8 and 10.0.0.2/8?  Or 10.0.0.1/8 and 10.0.0.2/24?

 

They're all in the same network and that seems wrong.

 

[Sir Asvald]

4 hours ago, heimdali said:

What's the difference between 10.0.0.1/24 and 10.0.0.2/24?  Or 10.0.0.1/8 and 10.0.0.2/8?  Or 10.0.0.1/8 and 10.0.0.2/24?

They're all in the same network and that seems wrong.

 

Nothing wrong? There is a huge difference between a /24 and an /8 subnet.. the /24 you get 253 usable addresses while the /8 gives you 16.7 million.. Who needs 16.7M ip addresses for their home network?

[heimdali]

Right --- the point is that all the addresses are on the same network which probably prevents his setup from working correctly.

 

[LIGISTX]

 

8 hours ago, heimdali said:

It just feels not right that the server and the VLAN should be on the same network, especially considering the masquerading.  And shouldn't the masquerading be on the same interface?  Like I don't see why PostDown would remove masquerading from eth1 after it was put in place in PostUp for eth0.

 

What if you fix the interfaces for masquerading and put the VLAN on a different network?

 

Maybe I am still misunderstanding here, but the server is and client are not on the same network. The server is in a different city... on local network 192.168.86.1, client is on 192.168.1.1, both with different public IP's. I have a vlan setup in esxi to put a test setup on a different subnet in order to test if things are working. MY WG client has 3 interfaces, eth0 going to local 192.168.1.1, the tunnel itself, and then the "test" subnet which I have as 10.0.02.

 

I think that means I am good here - as far as masquerading goes. But also, I obviously don't fully understand how this all works so I am just trying to make sure I

the topology at least.

 

8 hours ago, WereCatf said:

That should probably be /24, not /8. I mean, you're reserving the entire 10.x.x.x for the wg-interface?

 

This is probably the reason for your issues. I mean, the wg-interface already defines a 10.x.x.x - network and now you set up another one in the same address-space?

Just to clarify this one: it should be a /24.

Ok, so my lack of network knowledge here is clearly showing. I must have incorrectly understood the basics, I didn't realize 10.0.0.1 and 10.0.0.2 are in the same address space. I can see how that would make it hard for the router to correctly route traffic if that is the case. So, a simple first thing to test would be to change my wg client's router settings from 10.0.0.2 to say 11.0.0.1? I am off to work for now, but I will test these settings later, and I will edit the server and client's to your recommendations. Also, I had a misscopy, my client is set up as: (I will edit the original post as well).

 

[Interface]
Address = 10.0.0.2/8
SaveConfig = true
ListenPort = xxxxx
PrivateKey = xxxxxxxxxxx

[Peer]
PublicKey = xxxxxxxxxxxxxx
AllowedIPs = 0.0.0.0/0
Endpoint = <server's IP><Port>
PersistentKeepalive = 30

 

8 hours ago, heimdali said:

What's the difference between 10.0.0.1/24 and 10.0.0.2/24?  Or 10.0.0.1/8 and 10.0.0.2/8?  Or 10.0.0.1/8 and 10.0.0.2/24?

 

They're all in the same network and that seems wrong.

 

That seems like a valid point. I believe I misunderstood how this works.

 

 

-----

To everyone, I guess I have a few bits of confusion. I create an interface on the wg server side, currently: Address=<10.0.0.1>/<8>. I also setup an interface on the client side, currently: Address=<10.0.0.2>/<8>. Based on the guide I followed, that should be fine, but that is in fact not fine?

 

Also, im so sorry, I noted down the wrong setting for the vlan test side of things, the wg client config is Address=<10.0.0.2>/<8>, but in my 00-installer-config.yaml which is how I am setting up the wg client router, I do have a 192.168.2.1 address, so my virtual ubuntu desktop client (used for test) is getting a 192.168.2.x IP.

 

For reference, this is the wireguard setup tutorial I am using: https://www.the-digital-life.com/en/wireguard-installation-and-configuration/. According to the guide, which I think does in fact work, my IP's should be setup fine? But I have no problem changing them to try some stuff out.

[WereCatf]

1 hour ago, LIGISTX said:

Address=<10.0.0.1>/<8>. I also setup an interface on the client side, currently: Address=<10.0.0.2>/<8>. Based on the guide I followed, that should be fine, but that is in fact not fine?

It should be /24, not /8. The mask is wrong. Also, yes, Address=10.0.0.1/24 on the server, Address=10.0.0.2/24 on the client and AllowedIPs=0.0.0.0/0 on the client.

 

With PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <eth0> -j MASQUERADE; on the server, this would send all IPv4 - traffic through the server's eth0. Just make sure eth0 is not in the 10.0.0.x - address-space and that you don't have the 10.0.0.x address-space defined in your router, either. If you do, you'll need to choose a different network, like e.g. 10.0.2.x, ie. 10.0.2.1/24 on the server and 10.0.2.2/24 on the client for Wireguard. I'll repeat this: the 10.0.0.x has to be used only by Wireguard.

 

Do note that this doesn't send DNS-traffic over Wireguard or any IPv6-traffic. Also, that "guide" is shit.

[heimdali]

PostUp _adds_ an iptables rule (for when the tunnel is up?).  PostDown is apparently _intended to_ delete that rule (when the tunnel is brought down?).  That does not work because the rule added by PostUp involves eth0 and PostDown involves eth1.  That means PostDown tries to delete a rule that doesn't exist.

 

At least that's how I'm reading this.  I think you need to let the routing aside at first and do that later when the tunnel is working.

 

[LIGISTX]

14 minutes ago, heimdali said:

PostUp _adds_ an iptables rule (for when the tunnel is up?).  PostDown is apparently _intended to_ delete that rule (when the tunnel is brought down?).  That does not work because the rule added by PostUp involves eth0 and PostDown involves eth1.  That means PostDown tries to delete a rule that doesn't exist.

 

At least that's how I'm reading this.  I think you need to let the routing aside at first and do that later when the tunnel is working.

 

Oh gosh, you are correct. I believe I typoed that in my post.... I do believe in my actual config they are both eth0. I agree, they should be the same. Sorry for the confusion. I will confirm when I am home. 

 

1 hour ago, WereCatf said:

It should be /24, not /8. The mask is wrong. Also, yes, Address=10.0.0.1/24 on the server, Address=10.0.0.2/24 on the client and AllowedIPs=0.0.0.0/0 on the client.

 

With PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o <eth0> -j MASQUERADE; on the server, this would send all IPv4 - traffic through the server's eth0. Just make sure eth0 is not in the 10.0.0.x - address-space and that you don't have the 10.0.0.x address-space defined in your router, either. If you do, you'll need to choose a different network, like e.g. 10.0.2.x, ie. 10.0.2.1/24 on the server and 10.0.2.2/24 on the client for Wireguard. I'll repeat this: the 10.0.0.x has to be used only by Wireguard.

 

Do note that this doesn't send DNS-traffic over Wireguard or any IPv6-traffic. Also, that "guide" is shit.

Ok, that helps my understanding. I will make these edits this evening. Also, to further my understanding, why is /24 correct and not /8? I am not fully understanding that. 
 

Also, I do want to send DNS traffic over the tunnel; I want to send literally everything over the tunnel. My intent is for the devices on the router side of my WG client to have 0 way of knowing it’s not in my home network. What is required to set that up? (Currently this is flipped, my server is remote and client is local, so with current test setup I want my my client and all things behind it to think they are physically on the remote public IP, all traffic routed through the tunnel). 

 

Also, I’m sad to know that guide is shit    It’s hard to actually learn things when the internet is full of lots of meh info, and less good info. Also, I’m rather bad at reading man pages, they just don’t do it for my brain.

 

Thank you so much for the help. I will try these edits later and will report back

[WereCatf]

1 hour ago, LIGISTX said:

Also, to further my understanding, why is /24 correct and not /8? I am not fully understanding that.

It's called CIDR-notation and, well, an IPv4 - address is 32 bits long with each section separated by a dot being 8 bits, like e.g. in 192.168.1.2 you have 192, which is 8 bits, then 168, which is another 8 bits, 1, which is again 8 bits and then 2, which is also 8 bits. The /24 tells the system that the first 24 bits read from the left to the right are important and define the network, while the last 8 bits are free to be used for interfaces. If this explanation doesn't make sense, I suggest googling CIDR-notation or watching a longer Youtube-video on it. I'm too tired to think straight anymore, sorry.

 

As for DNS, you typically would only have to add a DNS=theaddressofthednsserverhere to your client's configuration-file under the [Interface] - section, but that didn't work for me under Ubuntu. Ubuntu uses Systemd and its DNS-resolver, whereas the wg-quick - script would use the openresolv - package (ie. apt install openresolv on the client), so I had to add PostUp = systemd-resolve -i wg0 --set-dns=dnsserverhere --set-domain=~. in the client's configuration-file instead to set the DNS in a way that's compatible with Systemd. I have no idea if Raspbian uses Systemd's resolver or not, but if you have the app systemd-resolve then it probably does. (Server-side you don't have to do anything to get DNS working.)

 

As for IPv6: my ISP doesn't provide IPv6, so I haven't had any reason to mess around with it and I am just about to head to bed, so you'll have to research that by yourself or wait until tomorrow for me to wake up. That said, here's a link that seems a lot better than the one you used before and this one also sets up IPv6 over Wireguard, so it should get you up to speed: https://stanislas.blog/2019/01/how-to-setup-vpn-server-wireguard-nat-ipv6/

[LIGISTX]

1 hour ago, WereCatf said:

It's called CIDR-notation and, well, an IPv4 - address is 32 bits long with each section separated by a dot being 8 bits, like e.g. in 192.168.1.2 you have 192, which is 8 bits, then 168, which is another 8 bits, 1, which is again 8 bits and then 2, which is also 8 bits. The /24 tells the system that the first 24 bits read from the left to the right are important and define the network, while the last 8 bits are free to be used for interfaces. If this explanation doesn't make sense, I suggest googling CIDR-notation or watching a longer Youtube-video on it. I'm too tired to think straight anymore, sorry.

 

As for DNS, you typically would only have to add a DNS=theaddressofthednsserverhere to your client's configuration-file under the [Interface] - section, but that didn't work for me under Ubuntu. Ubuntu uses Systemd and its DNS-resolver, whereas the wg-quick - script would use the openresolv - package (ie. apt install openresolv on the client), so I had to add PostUp = systemd-resolve -i wg0 --set-dns=dnsserverhere --set-domain=~. in the client's configuration-file instead to set the DNS in a way that's compatible with Systemd. I have no idea if Raspbian uses Systemd's resolver or not, but if you have the app systemd-resolve then it probably does. (Server-side you don't have to do anything to get DNS working.)

 

As for IPv6: my ISP doesn't provide IPv6, so I haven't had any reason to mess around with it and I am just about to head to bed, so you'll have to research that by yourself or wait until tomorrow for me to wake up. That said, here's a link that seems a lot better than the one you used before and this one also sets up IPv6 over Wireguard, so it should get you up to speed: https://stanislas.blog/2019/01/how-to-setup-vpn-server-wireguard-nat-ipv6/

Thanks for the info and the link, reading through it that seems very thorough and helpful. Quick statement about my DNS “question” previously, I don’t so much mind where my client gets its DNS, I just didn’t want DNS leaks. It looks like if properly configured it won’t leak, so I’ll likely just use 8.8.8.8 and 8.8.4.4 which for my needs will be fine.

 

Additionally, if I understand this correctly, this will provide ipv4 and ipv6 routing, so I shouldn’t have any ipv6 leaks, correct?

 

I will copy his settings later tonight and will report back what happens. I have a feeling I have an issue with my client side routing as I have it acting as a router as well, but one step at a time

[LIGISTX]

@WereCatf ok, I applied the settings used in the guide you provided, it didn't improve anything unfortunately :/.

 

Server settings:

[Interface]
Address = 10.66.66.1/24
Address = fd42:42:42::1/64
SaveConfig = true
PostUp = iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o ens33 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o ens33 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -o ens33 -j MASQUERADE
ListenPort = <port>
PrivateKey = <privatekey>

[Peer]
PublicKey = <pubkey>
AllowedIPs = 10.66.66.2/32, fd42:42:42::2/128
Endpoint = xxxxxxx

Client settings:

[Interface]
Address = 10.66.66.2/24
Address = fd42:42:42::2/64
SaveConfig = true
ListenPort = <port>
PrivateKey = <privatekey>

[Peer]
PublicKey = <pubkey>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <IP>:<port>
PersistentKeepalive = 30

my dhcpd.conf for the router I have set up on the wg client is:

option domain-name-servers 8.8.8.8, 8.8.4.4;

default-lease-time 600;
max-lease-time 7200;

ddns-update-style none;
authoritative;
log-facility local7;
subnet 192.168.1.0 netmask 255.255.255.0 {
     range 192.168.1.101 192.168.1.200;
     option subnet-mask 255.255.255.0;
     option routers 192.168.1.1;
}

and my 00-insatller-config.yaml is:

# This is the network config written by 'subiquity'
network:
  ethernets:
    ens160:
      dhcp4: true
    ens192:
       addresses:
       - 192.168.1.1/24
       dhcp4: false
       nameservers:
           addresses:
           - 8.8.8.8
           - 8.8.4.4
  version: 2

with a 

sudo iptables -t nat -A POSTROUTING -o ens160 -j MASQUERADE

to nat the router I have created. (should this be 192? The guide I found has this as 160.... hopefully thats correct?)

 

DHCP is working correctly, my ubuntu desktop VM gets 192.168.1.101 as expected, default route is 192.168.1.1, DNS is 8.8.8.8 and 8.8.4.4:

 

But things just don't work right still. I can get to the internet, but things are incredibly sluggish and non-responsive, and things just feel broken. I can't download chrome via firefox for example, it tries, hangs, tries, hangs a lot more. General website loading is incredibly slow and lagy, I am really not sure what is going on. I assume I am not correctly sending traffic from the router through the tunnel.... Any ideas?

[WereCatf]

3 hours ago, LIGISTX said:

(should this be 192? The guide I found has this as 160.... hopefully thats correct?

That depends entirely on the interfaces you have. You can't just copy someone else's interface-settings and expect them to work. Do you have a network-interface called ens160? If not, then it's obviously not correct.

 

3 hours ago, LIGISTX said:

DHCP is working correctly, my ubuntu desktop VM

Why don't you just focus on getting the traffic on your Wireguard-client working correctly first? You keep jumping ahead before you've verified that even the first step is working right.

 

Does the wg-client send its traffic over the tunnel? Does it have good Internet-connectivity? What's the output of route -n on it?

[LIGISTX]

2 minutes ago, WereCatf said:

That depends entirely on the interfaces you have. You can't just copy someone else's interface-settings and expect them to work. Do you have a network-interface called ens160? If not, then it's obviously not correct.

 

Why don't you just focus on getting the traffic on your Wireguard-client working correctly first? You keep jumping ahead before you've verified that even the first step is working right.

 

Does the wg-client send its traffic over the tunnel? Does it have good Internet-connectivity? What's the output of route -n on it?

I do have ens 160 and 192. I did copy the guide, but my VM has the same interface names. I have ens160 as my LAN side interface 190.168.21.1, I have ens192 as my "test environment router side" 192.168.1.1, and wgo0 as 10.66.66.2.

 

route -n gives me:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.21.1    0.0.0.0         UG    100    0        0 ens160
10.66.66.0      0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 ens192
192.168.21.0    0.0.0.0         255.255.255.0   U     0      0        0 ens160
192.168.21.1    0.0.0.0         255.255.255.255 UH    100    0        0 ens160

 

I can use the command wg as I attempt to watch youtube and such and see the amount of data increment as it goes, things just are not working correctly, but I do see data flowing over the tunnel. I am not sure how to test if the internet works "normally" in the wg client as its headless, I am not sure how to go about doing actual "testing" in that environment beyond pings and traceroutes. 

 

If I am reading things correctly, it looks like my default gateway is 192.168.21.1? Should the default gateway not be the wg0 interface? Hopefully this means more to you then myself.

[WereCatf]

5 minutes ago, LIGISTX said:

route -n gives me:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.21.1    0.0.0.0         UG    100    0        0 ens160
10.66.66.0      0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 ens192
192.168.21.0    0.0.0.0         255.255.255.0   U     0      0        0 ens160
192.168.21.1    0.0.0.0         255.255.255.255 UH    100    0        0 ens160

 

Your routes are all wrong. The default gateway should be the wg-server's IP-address, ie. 10.66.66.1, and using wg0 as the interface for it to send all traffic over the tunnel.

[LIGISTX]

6 minutes ago, WereCatf said:

Your routes are all wrong. The default gateway should be the wg-server's IP-address, ie. 10.66.66.1, and using wg0 as the interface for it to send all traffic over the tunnel.

how do I edit them to reflect that?

[WereCatf]

Just now, LIGISTX said:

how do I edit them to reflect that?

Well, the command to set the default route would be route add default gw 10.66.66.1 wg0 but that should already be done by the script that brings wg0 up anyways, so there's something wonky going on in your setup.

[LIGISTX]

5 minutes ago, WereCatf said:

Well, the command to set the default route would be route add default gw 10.66.66.1 wg0 but that should already be done by the script that brings wg0 up anyways, so there's something wonky going on in your setup.

Hmm, not really sure what would be causing issue.....  my conf files are above and all seem to be set up correctly.

 

How does the client know to use 10.66.66.1 as the default route, there is nothing in the conf file to tell it that, unless it gets that from the handshake with the server?

[WereCatf]

Just now, LIGISTX said:

How does the client know to use 10.66.66.1 as the default route, there is nothing in the conf file to tell it that, unless it gets that from the handshake with the server?

But there is. The AllowedIPs - line tells it that that interface should be used as the default-route.

[LIGISTX]

1 minute ago, WereCatf said:

But there is. The AllowedIPs - line tells it that that interface should be used as the default-route.

The AllowedIPs = line in the client is 0.0.0.0/0, ::/0, so its just telling it to use the default route, no? I think that is correct.

 

Its showing anything on 10.66.66.0 should use interface wg0 which I think makes sense. Should 192.168.1.0's gateway be set to 10.66.66.0 or something similar? I agree its likely a routing issue here, thats what it "feels" like, I clearly just don't get this lol.

[WereCatf]

11 minutes ago, LIGISTX said:

Should 192.168.1.0's gateway be set to 10.66.66.0 or something similar?

No, leave it alone.

[LIGISTX]

6 minutes ago, WereCatf said:

No, leave it alone.

Well hopefully something here is illuminating. I’m headed to sleep, any idea where to go from here? Is there a way to see what iptable edits I have made as maybe as I would trying guides out I did inadvertently mess something up? Start fresh from a clean Ubuntu server VM? I could rather easily instal WG on another VM I have just to see what it does with default routing with route -n.

 

Any advice would be great. This has been driving me nuts for multiple days  

 

Again, thanks for the help! I usually give advice around here - hardware and hardware troubleshooting advice, it’s nice to see it from the other perspective; the help needed side.