Wireguard with multiple Endpoints not working

[cds]

Hi there,

after having a working Wireguard config with one Endpoint so far I started to add more to the same "local" point.

I can't get this working - if add more than one endpoint the config gets screwed.
The config for each endpoint is - beside IP and keys - identical.
When I add the 2nd endpoint, "allowed IPs" of the 1st one is shown as NONE - in config page this is correctly set.
Adding a 3rd endpoint results in even 2 showing in the config at all.

Any ideas?

interface: wg1
  public key: XXXXXXXXXXXXX=
  private key: (hidden)
  listening port: 51820

peer: 1
  endpoint: 10.98.0.12:51820
  allowed ips: 10.0.0.0/8
  transfer: 0 B received, 7.23 KiB sent
  persistent keepalive: every 25 seconds

peer: 2
  endpoint: 10.98.0.11:51820
  allowed ips: (none)
  transfer: 0 B received, 6.07 KiB sent
  persistent keepalive: every 25 seconds

[Patrick M. Hausen]

Allowed IPs must not overlap. Is that the case?

[Demusman]

Change the allowed IP's to the actual subnets instead of the /8

[cds]

Maybe I have a missunderstanding on my side.

I understand "allowed IPs" are the IPs the client is allowed to access on the remote side.
Is this wrong?

Regards
CDS

[Demusman]

Not wrong but you have the whole /8. That can cause problems.
Use the actual subnets and add it on the 2nd site also.

[Patrick M. Hausen]

Allowed IPs is the network/prefix WireGuard routes to the other side of the tunnel. Hence they must not overlap for multiple peers.

[cds]

Somehow I still don't get it.

My complete network is 10.0.0.0/8 - consisting of the local LAN, some VLANs, some other VPN connections (via IPsec).

Which config is needed so each Wireguard client is allowed to reach any IP of this 10.0.0.0/8 network?

[Demusman]

What are your actual subnets?
Add them to allowed IPs.
10.1.1.0/24
10.2.0.0/25
etc.

And add the needed subnets to the other site.
The tunnel is needed as allowed everywhere.

[Greelan]

You've got to look at it from the perspective of the device on which you are configuring the peer config.

On OPNsense, usually you just want the peer (endpoint) tunnel IP to be the allowed IPs. Eg 10.98.0.11/32.

But on the peer device, you want to specify the allowed IPs to be whatever you want the device to access at the OPNsense end - in your case 10.0.0.0/8.

The other problem though with your setup is that it appears your tunnel IPs are overlapping with your local network - 10.98.x.x is within 10.0.0.0/8. That won't work. The tunnel subnet must be unique, ie not a subnet otherwise used on OPNsense.

[Demusman]

Example.

[Patrick M. Hausen]

The phrase "allowed IPs" is confusing. In reality what you put in "allowed IPs" is the network(s) that are on the other end of the tunnel. Is all of 10.0.0.0/8 at the other end of peer X? No. Put only the networks at the other end of the tunnel in there. Don't have the specifications overlap with either local networks or other peers.

Ignore that it is called "allowed IPs". Nothing to allow or deny here. It's a routing command. WireGuard will route all of these networks through the tunnel.

Edit ...

Actually overlap with local is ok, because of more specifics. Let's picture a typical enterprise hub and spoke topology.

So branch office A is 10.1/16, B is 10.2/16 and so on. The head office is 10.0/16.

Then at the head office put 10.1/16 into allowed_ips for peer A, 10.2/16 for peer B, etc.

At each branch office put 10/8 into allowed_ips.

Assuming proper firewall rules are in place now everyone will be able to communicate with everyone else.

"allowed_ips" means "route add ... --> this peer".

Why? Don't ask me. That's how WireGuard works, seemingly.

[Greelan]

I agree it can be confusing. I think the rationale behind the name is that it specifies what source IPs are "allowed" for packets coming from the relevant peer (which is the inverse of what destination IPs can be reached at that peer).

[Greelan]

As per the WG conceptual overview:

"In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list."

[Demusman]

The other problem though with your setup is that it appears your tunnel IPs are overlapping with your local network - 10.98.x.x is within 10.0.0.0/8. That won't work. The tunnel subnet must be unique, ie not a subnet otherwise used on OPNsense.

This doesn't mean they are overlapping.
He could be using a /30 out of the /8 as the tunnel. As long as that /30 isn't used elsewhere it would be fine.

[Greelan]

That's why I said "appears". We haven't been given the info on the subnets that have been otherwise configured on OPNsense. If 10.0.0.0/8 is just being used as a shorthand to pick up a bunch of otherwise unique subnets, then fine.

The real issue then is the allowed IPs that have configured in the OPNsense endpoint configs, as per my original comment.