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
Allowed IPs must not overlap. Is that the case?
Change the allowed IP's to the actual subnets instead of the /8
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
Not wrong but you have the whole /8. That can cause problems.
Use the actual subnets and add it on the 2nd site also.
Allowed IPs is the network/prefix WireGuard routes to the other side of the tunnel. Hence they must not overlap for multiple peers.
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?
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.
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.
Example.
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.
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).
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."
Quote from: Greelan on January 15, 2023, 10:52:01 PM
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.
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.
Quote from: Greelan on January 15, 2023, 11:24:57 PM
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.
Then you shouldn't have said "That won't work". :)
So,
if I understand right:
peer: 1
endpoint: 10.98.0.12:51820
allowed ips: 10.98.0.12/32
persistent keepalive: every 25 seconds
peer: 2
endpoint: 10.98.0.11:51820
allowed ips: 10.98.0.11/32
persistent keepalive: every 25 seconds
should work (10.98.0.0/24 is only used for WG peers).
So far so good. Now I have a new effect:
10.98.0.11 can ping 10.11.1.1 (Endpoint of VPN), but not access it's Webpage.
If peer 2 is the only peer, and allowed ips: 10.0.0.0/8 is used this works.
Any hints?
Have you added firewall rules for WG on OPNsense?
Quote from: Demusman on January 15, 2023, 11:30:16 PM
Then you shouldn't have said "That won't work". :)
This is
really how you want to spend your time?
Yes, in and out everything allowed.
BTW, access to 10.1.1.0/24 works fine ...
What's the config on that peer itself?
Quote from: cds on January 15, 2023, 11:31:20 PM
So,
if I understand right:
peer: 1
endpoint: 10.98.0.12:51820
allowed ips: 10.98.0.12/32
persistent keepalive: every 25 seconds
peer: 2
endpoint: 10.98.0.11:51820
allowed ips: 10.98.0.11/32
persistent keepalive: every 25 seconds
should work (10.98.0.0/24 is only used for WG peers).
So far so good. Now I have a new effect:
10.98.0.11 can ping 10.11.1.1 (Endpoint of VPN), but not access it's Webpage.
If peer 2 is the only peer, and allowed ips: 10.0.0.0/8 is used this works.
Any hints?
You're still not allowing any of your subnets through the tunnel. You won't be able to access anything outside the tunnel.
Quote from: Greelan on January 15, 2023, 11:37:27 PM
Quote from: Demusman on January 15, 2023, 11:30:16 PM
Then you shouldn't have said "That won't work". :)
This is really how you want to spend your time?
Just pointing out that you gave some misinformation and instead of you just admitting that, you make an excuse.
Am I wrong?
Quote from: Demusman on January 16, 2023, 12:02:50 AM
Am I wrong?
Yes.
If you want to talk about misinformation, your most recent post will cause confusion. The OP doesn't need to add the local networks to the allowed IPs in the endpoint configs on OPNsense. The OP does however need to add them to the peer allowed IPs on the peers themselves - so that the peers know that they access 10.0.0.0/8 at the OPNsense end via the tunnel. See my earlier comments. This is why I asked to see the WG configs on the peers themselves.
Ok. Have it your way.
peer: 1
endpoint: 10.98.0.12:51820
allowed ips: 10.98.0.12/32
persistent keepalive: every 25 seconds
peer: 2
endpoint: 10.98.0.11:51820
allowed ips: 10.98.0.11/32
persistent keepalive: every 25 seconds
BTW, OP, you don't need to specify an endpoint IP and port in the endpoint configs on OPNsense, if the peers are the ones initiating connections to OPNsense rather than the other way around.
If OPNsense is initiating connections to the peers, then you need to specify a public IP and port that they are accessible on, rather than the tunnel IP.
Good cleanup.
;D