Trying to configure wireguard, please help

Installing and Using OpenWrt
1

I have wireGuard running in my NAS and it works.

But now that OpenWRT supports it and has a luci interface, I want to move it to one of my OpenWRT routers.

The router were I configured it is a secondary router, not connected to WAN, but in the internal router.
The listening port would be 51820 and I have configured the gateway NAT to redirect traffic from internet on that UDP port to internal router (172.16.255.2) in that port.

The router addres is 172.16.255.2 being 172.16.0.0/16 the lan IP network (ther is other isolated network in 172.31.255.0.0/16).

The vpn adresses will be in the network 172.20.0.0/16 and the wireguard server in 172.20.255.1:51820.
The external IP from internet can be designated as casa.xxxx.xxxx:51820.

I have tried to configure the wireGuard interface, and I can connect and see there is traffic (I see the device connected in the router in status/wireGuard).
I can even access from the connected device to the luci interface of the router in http://172.16.255.2 but that is all: I cannot access other devices in the internal net after being connected.
So I suppose I have some missing firewall rule or something.

Let me show my config step by step:

This is the wireguard interface in the router.

image
image894×663 30.3 KB

I created a vgLAN zone for the firewall (may be it is not strictly neccesary, and could use LAN zone as I would like that connected devices have same behaviour as the ones directly connected to ethernet or wifi).
image
image888×210 14.5 KB

And this is the configuration of the peer:
image
image889×820 36.8 KB

This is the configuration of the client device for the test

image
image668×820 112 KB

The firewall in the router is as this:

image
image960×280 19 KB

And I have created a rule for incoming 51820 UDP connections (not necessary, I think as the connection to this router is already in the internal LAN, redirected from the main router, but just in case I move it to the main router).

image
image946×86 7.75 KB

What is wrong in this configuration that does not let me access other devices in the internal LAN?

2

What the LAN address - 192.168.1.0/24, correct?

If I'm translating correctly from my English version of the app...this network is not allowed.

If this is a VPN, permitted (allowed) IPs should be 0.0.0.0/0.

1 Like
3

mmm... If I understood well wireGuard documentation, there you should put addresses that should be redirected to the tunnel from the device.
In my case the addresses of the local LANs at home.

If you use 0.0.0.0/0 all traffic would be redirected to the tunnel, which makes no much sense for a device that is already connected to internet.

192.168.1.0/24 is not an address in my LAN, LAN network is 172.16.0.0/16 and there is other separate network (172.31.0.0/16) for iot devices that would be great to access from the vpn, too.

4

Enable temporarily masquerading on the lan zone to see if it will make a difference.

1 Like
5

Well I have tried several things.

I have activated masquerading in the zon, but it does not seem to work. I have not expected it, as I don't see the need of using NAT for a device that is connected to the LAN and has its properly formed IP address, I think it is more a matter of correct routing among the VPN IP network and the LAN network.

Why should need masquerading when each device in the internal network and the device in the VPN network has its own and unique IP?

I have tried to activate "route allowed IPs" in the peer config at the server, with no useful result.

I have tried configuring a static route among 172.20.0.0/16 and 17.16.0.0/16 with the result of not being able to access the router (and having to do a soft reset to eliminate the route and get it back to work).

So there is something wrong with this config, but I have read several times the way to connect a device to an internal LAN using wireGuard and it seems all correct.

Any idea of what is going on?

6

Enabling masquerading on the LAN zone hides the requests from the wireguard client behind the LAN IP address of the router. It would avoid two potential problems.

  1. Errors in routing between the lan and the wireguard networks.
  2. Lan client firewalls, not accepting connections outside their LAN.

You do not need additional static routes. Everything needed should be created automatically.

Connect the vpn client and check the wireguard status/routing table.

 wg show; ip route show dev wireguardlan # or whatever the interface name is

Start a traceroute from a lan device to the vpn client and vice versa.

1 Like
7

So I had misunderstood your guidance, I think.

You mean activating masquerading in the LAN zone not the WireGueard zone?

Won't it create other problems in the LAN zone? There is a NAS and other devices connected to that router and expecting to be connec from other devices in the LAN.

I will try, hope it won't make the router inaccesible again.

That is what I had expected that the routes were created automatically when needed.
Should I activate "route allowed IPs"?

With the original config, with route allowed IPs activated and no masquerafing this is the result of
wg show:

root@routerSalon:~# wg show
interface: wireGuardLAN
  public key: tN-XXXXXXX
  private key: (hidden)
  listening port: 51820

peer: 9B-XXXXXXX
  endpoint: 31.221.159.208:3419
  allowed ips: 172.20.0.3/32
  latest handshake: 22 seconds ago
  transfer: 856 B received, 1.01 KiB sent

And this the routes:

root@routerSalon:~# ip route show dev wireGuardLAN
172.20.0.0/16 dev wireGuardLAN scope link  src 172.20.255.1
172.20.0.3 dev wireGuardLAN scope link

I can access the router LAN IP (172.16.255.2) but not other devices in the lan like (172.16.255.1).

8

Now with masquarading:

interface: wireGuardLAN
  public key: tN-XXXXXX
  private key: (hidden)
  listening port: 51820

peer: 9B-XXXXX
  endpoint: 31.221.159.208:3419
  allowed ips: 172.20.0.3/32
  latest handshake: 1 minute, 52 seconds ago
  transfer: 63.22 KiB received, 547.23 KiB sent

root@routerSalon:~# ip route show dev wireGuardLAN
172.20.0.0/16 dev wireGuardLAN scope link  src 172.20.255.1
172.20.0.3 dev wireGuardLAN scope link

After activating masquerading in the LAN network, I can access other device like 172.16.255.1.

Is that the solution?

I don't think masquerading should be on for an internal lan zone, just for external zones (wan) with just one IP exposed, am I wrong?

But it may indicate some problem with routes configuration in my device.

9

Yes.

What is 172.16.255.1? Does it have a firewall? Is its default gateway set to 172.16.255.2?

If you can't find the cause of the problem and you are worried to enable masquerading on the lan zone, you could create a SNAT rule covering only the vpn client.

uci add firewall nat
uci set firewall.@nat[-1].name='WG-SNAT'
uci set firewall.@nat[-1].src='lan'
uci set firewall.@nat[-1].target='SNAT'
uci set firewall.@nat[-1].snat_ip='172.16.255.2'
uci set firewall.@nat[-1].proto='all'
uci set firewall.@nat[-1].src_ip='172.20.0.3'
uci commit firewall
fw3 restart
1 Like
10

172.16.255.1 is another router (the ISP router in this case) with a http interface accessible from any device in the internal lan.
It does not respond to pings either when you connect from the VPN (it does from a lan connected device).

But it is only an example: I cannot access the nas either.

The default gateway is the ISP router: 172.16.255.1. 172.16.255.2 is an access point and DHCP and DNS server, and I installed wireGuard there as it has openWRT.

I am about to change that and elimimnate the ISP router (let it just as internet gateway in bridge mode) and centralize everything in a new router (with DHCP, DNS and wireGuard installed in it and connected to the ISP router as gateway) and let 172.16.255.2 (the curren openWRT router) as just an access point and VLAN switch for other part of the home.
But configuration of wireGueard should be similar in the new router.

I do not know exactly how masquerading works. I understand it is just a NAT system.
But NAT seems the solution to the cases where you just have an IP that you have to share with all internal devices (typical the gateway to internet).

Here there is no such problem: each device has its own IP and is accesible from others (with the proper firewall and route config).

I can't see either what the problem is.

With the wireGuerd activated in the NAS there is no problem, it is working. But I prefer it on the router, as it seems the natural place and you only depend on that device working to get access. I the router does not work, you are not going to have access even if the NAS is working.
But the NAS is a complex system with many things that can fail and as such I have less confidence in the NAS being ON and working all the time.

Thank you for your help, you have helped me a lot.

When I receive the new router to put as main router, after configuring it as DHCP and DNS server and lan gateway, I will try to configure wireGuard in it and see if it works.

1 Like
12

In the meantime, to make it work without using masquerading or SNAT, you should add static routes in the ISP router, the NAS and all the other LAN devices that use 172.16.255.1 as a default gateway.

The destination network address must be the wireguard network and the next hop address - the OpenWrt device.

It is device and OS specific, but in general it should look like this:

ip route add 172.20.0.0/16 via 172.16.255.2

Also check the firewalls if any.

1 Like
13

let's see your complete configs.

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/firewall

As an aside, is there a reason you are using /16 networks? In the vast majority of cases, this isn't going to present a real problem, but it is typically an unnecessarily large subnet and increases the risk of a subnet overlap conflict either in an upstream network (say a road-warrior context) or simple mistakes in subnetting because the range is so huge. If you really have ~1M devices on the network, they should be using smaller subnets anyway as a means to control broadcast traffic and improve network efficiency. Most home/small business networks can fit comfortably in a /24 (254 hosts) or at worst at /23 (510) or /22 (1022). Using /24 networks also makes the visual identification of each subnet super easy, which is just an added bonus.

14

Well mainly, just a matter of organization.
For me is easier to remember which address do I assign to special devices.
Routers and other network devices I put them in 172.16.255.XXX, servers, web servers and so in 172.16.254.xxx, and ordinary devices with dhcp leases in 172.16.0-3.XXX.

I put another router with dhcp disabled but configured in leasing address in 172.16.4-7.xxx and if the primary fail, I can activate it quickly and at least have the devices connected to internet easily.

With a network just 255 address wide is more difficult to organize and separate devices by classes.

It should not affect in anyway the normal working of a network (if net masks are correct).

Here are the asked files:

onfig interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdf3:d760:bc14::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '60'
        option ipaddr '172.16.255.2'
        option netmask '255.255.0.0'
        option gateway '172.16.255.1'
        list dns '208.67.222.222'
        list dns '208.67.220.220'

config interface 'wan'
        option device 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0'

config interface 'wireGuardLAN'
        option proto 'wireguard'
        option listen_port '51820'
        option private_key 'ACXXXXXXXXXXXXXXXXXXXXXX='
        list addresses '172.20.255.1/16'

config wireguard_wireGuardLAN
        option description 'movilFernando'
        option public_key '9BXXXXXXXXXXXXXXXXXX='
        list allowed_ips '172.20.0.3/32'
        option route_allowed_ips '1'

And firewall:

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'

In this router many of the rules that are set for wan zone do not affect, as it has no wan port, nothing is connected to the wan interface or assigned to wan zone.

15

I do not see the network interface wireGuardLAN associated with any firewall zones. It would make sense to associate this with the lan zone.

Since this OpenWrt router is not acting as the main gateway, you must have a static route installed on the upstream router. This should be
172.20.0.0/16 via 172.16.255.2 (installed on 172.16.255.1)

Let's also take a look at the remote peer configuration, and also the output of wg show

Unrelated to the WG side of things...

my opinion on the large subnet

I guess there is some logic to this, but IMO a bit extreme. I personally organize using the last octet in a human readable fashion. So for example:
10.0.1.1 - 10.0.1.19: critical network infrastructure (router, switches, APs, VPN appliance, etc.)
10.0.1.20 - 10.0.1.39: servers
10.0.1.40 - 10.0.1.59: cameras
10.0.1.60 - 10.0.1.79: media devices
...
10.0.1.100 - 10.0.1.199: DHCP for general purpose devices, etc.
and so on.

Classes are a deprecated way of describing networks/subnets. (CIDR is "classless inter-domain routing)
I don't know how big your network is, but I personally think that 255 addresses can be split into logical groups, but to each their own in terms of how they want to organize their networks.

I will point out that the extreme size of your network means that there is the risk of a conflict when you are connecting (with WG) from a remote network that could potentially use the 172.16.0.0/12 network range. The larger your subnet, the more likely you are to run into this issue since the even a /24 in some remote location (or smaller) might just happen to overlap your network and cause issues with the ability to route to your own network.

But all of that said, this is my opinion -- although it is unconventional, there's nothing technically wrong with what you are doing in your organizational scheme, so feel free to disregard my opinions on this matter.

1 Like
16

I do thank your opinions, as I am not so proficient in networks.

Well, I am old in this world of networks.

I install my first IP network (by pure neccesity) in 1990. But I am not an expert in networks or have any specialized training in it. Just pure need.

So my concepts are old, and things have changed a lot since I learned the basics, and my language about it may be outdated too.
Thank for your clarification.
The only reason of doing as I do, is that (when I had an 24 domain address like 192.168.1.0/24) I used the latest IPs (form .250 up) to network devices and from .200 for servers and the like.
As I added devices, printers, routers, services for testing things in dockers, etc, it begin to be more difficult to remember which address range I uso for each thing (and in router and devices I only had 4 adresses).
So for the new era I decided to use a wider IP network, and it is easy to assign each type a different "subclass" liek 172.16.255.XXX for routers just because it meets the way we write IP address in decimal octets.
So I don't have to remember if I assign the range to devices from 1 to 19 or 1 to 30.
Each "subclass" has a range of 255 and there are a lot of subclasses I can use if need arrives, as 255 devices are way more than what I can probably have in a home.

By the way 10.0.0.0/8 is even a wider class A network.

But as you say, I never understood well why classes were defined at all,, as the important thing is how you assign the mask to it, and whether that range of addresses are private (thrown away by the routers and never populated outside the local net) or public (internet wide addressable).

But if it is more common to use 10.0.0.0 and cause less probable conflicts, the right moment to change that is right now that I am redisigning all.

I can use 10.0.0.XXX/16 for general devices, 10.0.255.XXX/16 for routers and the like, etc.

As it is a ClassA /8 I can define 10.1.XXX.XXX/16 as a separate network for IOT devices and 10.2.XXX.XXX/16 for VPN wireguard each with different DHCP servers if DHCP is needed in that network.

Would it be a better and more standard way of using IP addresses?
Or for the vpn is better to use 172.16.xxx.xxx?

If you connect from another net IP address on that network should not be populated to yours, they should all go through a router and the intermediate IP addresses, so there should not be a problem if the to separate nets have the same private addresses.
The problem I can imagine is if the vpn uses the same IP range that you are using internally.

So if vpns use 172.16-31.XXX.XXX/12 probably I should use that for my VPN and steer the internal IP network away from that addresses and move it to 10.0.0.0.

Well I have done so many test that probably right now I have misconfigured that firewall rules.
The wireGuardLAN firewall was configured to accept traffic from lan as source and be able to route traffic to lan as destination only. Reject input, accept output an reject forward.

I tried to create a static route like you say, but I did something wrong, as the router turned unreacheble and had to boot in failsafe mode.

As my new main router has arrived and it will be the gateway, 172.16.255.1 and be the DHCP, DNS and wrireGuard server, it will have a slightly different configuration, and may be it is better I begin with wireGuard in it from scratch and see if it works.

17

Sadly quite a lot of ISPs (especially cellular ones) abuse the 10.0.0.0/8 network for their own needs, so this is quite probe to overlapping.

1 Like
18

So which are the private IP ranges that are private?

10.0.0.0 us abused, 172.16-31.0.0 too, which one is the correct with more tan 255 contiguous addresses?

You said above that you were using 10.0.1.XXX that is in the range of abused networks by cellular devices.

19

IMO, this is no different than if you use parts of a really big subnet (so 172.16.255.x being routers, 172.16.250.x for cameras, or whatever your scheme). if you are grouping devices into address ranges based on the function, you still have to have some logical mapping of numbers to device type. So what goes in 1-19 and 20-39 is no different than defining what goes in each 3rd octet (say a.b.255.d or a.b.250.d) -- you still need a mechanism to keep those organized because it's not like there is a specific rule or industry convention around this. At the end of the day, they're just numbers, and you connect the numbers and functional groupings with some method -- memory, a spreadsheet, a database, etc.

Yes. 16.7M+ hosts fit in a /8.

I think that you are misunderstanding my point...
There are several common ranges used in home and small business networks that adhere to RFC1918 (which sets aside 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 for private networks). For example, a huge number of consumer routers use 192.168.1.0/24, and also popular is 192.168.0.0/24, 192.168.2.0/24 and 10.0.0.0/24, 10.0.1.0/24... just to name a few that are frequently used (there are other common ranges, too). In general, there is nothing wrong with using these ranges.

The only time that you'll likely have an issue with the common ranges is if you are trying to connect via VPN from some remove location back to your home. If that remote location happens to use the same (or overlapping) subnet, in which case the VPN will not work properly. That is why using an uncommon subnet (still within the RFC1918 defined ranges) is often recommended -- it just reduces the probability of a conflict/overlap.

Now, as your subnet gets larger, there is a greater risk of overlap. So, for example, if you were to define your network as 192.168.0.0/23, that actually includes all of the addresses for 192.168.0.0/24 and 192.168.1.0/24. Therefore, creating at /23 means that you have increased the chance of a collision of address spaces when you are at a remote location. Your VPN won't work properly if that remote location uses either of those /24 subnets. As you go larger, the problem gets worse. So if you were to define 10.0.0.0/8 for your home network, that would mean that if you are at a location with a network that has a network anywhere in the 10.0.0.0/8 range (even if it is a /24 or smaller) would have the potential to conflict. Silly analogy: If I ask about the probability of a house being available for sale, the larger the search area, the more likely something will be on the market. If use a very small scope (let's say a specific random address), the probability is low. If I take that address and say "anything in that neighborhood" the probability increases... up to the city or county level, or the entire country -- the larger my search area, the more the probability increases until I hit 100%. In the case of networking with the intent of remote access via VPN, you want your own subnet to be as small as possible and relatively uncommon so that the probability of being in a location that happens to use that same (or overlapping) subnet is very small.

A large part of the reason I am suggesting that you use a smaller subnet (say a /24, or if you really need larger, maybe a /23) is to reduce the probability of an overlap when you are remote. Beyond that -- personal opinion -- I just find /24 networks to be particularly easy to work with.

The 172.16.0.0/12 space is fairly uncommon for home use, but is more prevalent in small business environments. There is no 'perfect' range to use for your network with respect to VPNs, but try to avoid the most popular ones and you'll probably be good. The 172.16 subnets are probably a good choice in general... just use smaller ones and you'll hopefully not overlap with any other networks.

It is best to look at CIDR (the /xx notation) instead of using the old "classful" network definitions (A, B, C). Classful network nomenclature is no longer used. CIDR simply uses the subnet size (/24, /16, etc.) to define network, and it is much more useful in modern routing and networking discussions.

Probably easiest if you post the latest firewall configuration for review again.

Which router did you set with the static route? This should have been done on your main router, not the VPN one.

Yes, probably best to start fresh. Will this new router be running OpenWrt?
When you set everything up, consider the things I said about using smaller subnets and a different mental model for how things are logically organized. It is, of course, up to you how you do this, but it is worth giving some thought to this before you start restructuring your network.

1 Like
20

Yes the new router will be running openWRT: I want all my routers and network devices at home running openWRT when possible, as it is so flexible and lets me make changes or adapt to future network changes and technologies.
Even ir that supposes a slight drop in performance with respect to the stock firmware (may be sometimes there is that drop in performance, for example with new routers wit ACX or in aspects like beamforming).
For example: with my old tplink, I can now use a WPA3 authentification if I want, just upgrading openWRT. I am sure tplink does not provide that funcionality with the original firmware. It has long abandoned firmware upgrades for that router.

(By the way: Happy christmas to everybody and specially to you and many thanks for your time and answers)

I think I have mastered what you say about a too wide network.

There is no problem when you interconnect two networks with same IP addresses through routing in internet.
I can have 192.168.0.1 in may PC in my private net and connect to a server in another net with same IP, as long as they connect through routers and there is a NAT beetween (there is allways a NAT when you interconnect private networks, or the servers in the other net has a public unique IP address).

The problem arrives when you use a VPN.
If i am in a network outside home (a friend's network) and he has the default config for home routers I will have given a local IP as 192.168.0.2 for example, and when I create the VPN to home and try to connect to my home server with an address like 192.168.0.1, for example (if I have left the default config) there would be a collision, as I cannot create routes for accessing my net through VPN without destroying the routes that provide me local access to my friend's network.

So when interconnecting networks through VPN there are 3 network address involved: the IP addresses in the source network, the IP address in the destination network and the IP addresses used in the tunnel itself.
Any collision in addresses (combination of IP and mask) will create a proble and don't let you do the connection.

So the narrower your network less probability of colliding.
So selecting a non so usual IP network for your home network and for the tunnel itself is a good idea too (192.168.0.XXX or 192.168.1.XXX won't be a good idea as are the defaults in many routers).

Now lets go to the point of selecting an appropiate network for my home and vpn in order to reduce the probability of collision.
But I would like to have a network with more than 254 address in order to be able to organize IPs given to devices by class.

I am thinking of 10 bits for the IP range, that would provide 1023 addresses for the devices, more than needed in a home network. So it would be a /22 "class" network.

That let me have 4 ranges of devices to logically separate the adresses (but in the same network, just as a reminder for me) with 254 devices in each, using the 2 upper bits of the 10bits.

So:

  • computers and ordinary leases would be in 0.XXX (0-254) range.
    This is the range that will be assigned by the DHCP server with more than enough leases for the number of devices you can get at home.
    The other adresses in other ranges will be assigned manually or using DHCP with reserved leases based in MAC.
  • Routers, gateways, switches and so in 3.XXX (768-1022 range, 1023 would be all 1's and as so is the broadcast address of the net).
  • Servers and docker services and the like in 1.XXX (256-511).
  • Printers, scanners or other devices like that in 2.XXX (512-767) (I would like to put here the mobiles and tablets too, but don't know how to configure DHCP to assign ranges based on the type of devices, so they would be in the

Thus I would have enough space in each range to assign new devices to any of the categories. And let me easily remember the type of device looking at its address in decimal format.

Now the time to select a network /22 range.
Being a home network the usual network range would be something beginning by 192.168.XXX.XXX.

There is a whole /16 bit of private IP adresses there, from 192.168.0.0 to 192.168.255.255.
So it is supposed I can select a /22 subrange in that /16 range to assign to my nework.
But most places and IPv4 network calculators list that network range as being /24 class C network.
I don't know if there may be a problem using a /22 bit network there.

In order to reduce collisions with usual assigned IP networks like 192.168.0.xxx or 192.168.1.xxxx I can select something less usual like 192.168.180.0/22.
So:

  • standard devices would be 192.168.180.XXX.
  • routers, gateways, switches and the like: 192.168.183.XXX
  • servers and services: 192.168.181.XXX
  • printers, etc: 192.182.XXX

But as said I don't know if there can be problems using 192.168.0.0 as a class wider then the class C /24.

And there would be collision problemes with other nets that are class C, so using a /22 class instead of /16 does not make any difference in the goal of eluding collitions, I think.

If I am in a home that uses the typical 192.168.1.0/24 network (configured in so many routers), I think I will have problems too as the 1 will be interpreted in my network as part of the device adresses and not the network address).
One route will try to stablish a /24 network and other a /22.

Won't there be problems with that?

Selecting 192.168.180.0/22 as my network will have problem for sure with class C networks from 192.168.180-183.0 but that is expected, as that ranges are internally used in my network.
At least ther wont be problems with other networks like 192.168.126.0/24.

May be it is better to do the same but using a 10.0.0.0/8 network narrowing it to a /22 network (instead of trying to widen what usually is treaten like a /24 class C network) and selecting a not so usual and evident network, like 10.211.164/22 and having so:

  • routers 10.211.167.xxx
  • standard leases: 10.211.164.XXX
  • services: 10.211.165.XXX
  • printers and the like: 10.211.165.XXX

I think this solution will be better, and less prone to collitions when being connected to other private network and trying to connect home, and with addresses as easy to remember as the usual 192.168.xxx.xxx.

For the VPN network to stablish the wireGuard connection, I think I should use just a 172.16-31.0.0 net treated like a /24 class C like 172.20.20.0/24 with the server in 172.20.20.1 being the server and devices with upgoing address, as there cannot be so many devices connected and the address is only used to stablishg the link.

21

The ranges you have proposed (192.168.180-183.0/22, 10.211.164-167.0/22, 17.20.20.0/24) are all (probably) uncommon enough that it is fairly unlikely that you'll have a conflict when you are on a remote network trying to connect via WG back to your home network. No guarantees, of course, because you never know what people/businesses are using for their LANs, but I think you should be fine.

A few things here...
First, please stop using the old "class" nomenclature. This terminology has been deprecated. Instead, just simply use the CIDR notation -- i.e. /24, /22, etc.).

Here, as well, you are really organizing things using the 3rd octet, essentially using one large /22 nework with /24 human-level organizational structures. The term "class" should be retired.

Next, using non /24 networks is probably not going to be an issue with anything modern.
It is possible that some very old or very poorly designed products may choke on non /24 networks. This is especially true if it has a hardcoded subnet mask (that is not not user settable and/or if it doesn't respect the subnet mask issued by a DHCP server). Since /24 is the most common for home networks, some really old devices for the consumer market (or those built by engineers/companies who don't understand networking) might just assume that /24 networks are the only thing type will ever connect to. However, this is unlikely to really be an issue these days.

FWIW, businesses may also use /24, but may also use larger, or possibly even smaller networks. Even a business with say 10K devices will rarely use really big subnets for all the devices -- using multiple smaller networks will improve network performance by managing broadcast domains (when dealing with very large numbers of devices), and also can be useful for logical organization and/or security.

No. Basically, the WG interface acts more as a P2P type connection, between which any specified traffic is tunneled. If you set it to tunnel all traffic, it will send everything through the tunnel, regardless of the size of the subnets in question. If you send only specific addresses or subnets, those will go through the tunnel while the others won't.

  • sending all (i.e. allowed IPs = 0.0.0.0/0) from the 'client' peer is useful if you want to mask your actual current IP/location -- making all the traffic appear as if it is originating from the 'server' peer (i.e. your home or a commercial VPN, etc.). This can be good for dealing with geo-ip restrictions or ensuring local privacy when you're on a public network (i.e. the cafe network admins can't peer into your traffic).
  • sending a specific set of addresses or subnets (i.e. allowed IPs = 192.168.180.0/22) is useful to enable remote access to that network without sending other internet traffic through the tunnel).
  • If you happen to be on a remote network (i.e. physically local to you at the time you are away from home) with the same/overlapping subnet as your home network, there can be issues with the local device properly managing the routing through the tunnel because there can be ambiguity as to which network a specific resource is on (i.e. is it on the "local" network you're connected to at that moment, or it it on the network through the VPN tunnel?).
  • The sizes of each network (your home and the remote network that is 'local' to you at that moment) do not matter, as long as they don't overlap. The smaller the networks, the less likely they are to overlap. You can only control your own network, of course.

Anyway, when you have your new router installed and everything configured at the basic networking level, you can then try setting up WG. If you have trouble, come back with the complete /etc/config/network and /etc/config/firewall files as well as the remote peer config (i.e. from the laptop or phone or whatever).

1 Like