I wonder if someone can give me a hand with this.
I am on OPNsense 23.7.12_5-amd64
Errors take the form of:
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/route -q -n add -'inet' '192.168.5.0/24' -interface 'wg1'' returned exit code '1', the output was ''
or
/usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command '/sbin/route -q -n add -'inet' '0.0.0.0' -interface 'wg1'' returned exit code '1', the output was ''
I have tried stopping the wireguard service first before modifying it but it is the same behaviour.
Those are the errors when changing or adding those networks to an already configured peer. Currently this peer has allowed ips of: 10.0.0.4/32 and works fine but I want to allow it to also reach my LAN which is 192.168.5.0/24. Also there are VLANs on it.
Clearly I have a setting somewhere that creates a bigger problem because when I change the allowed ips to 0.0.0.0/0, all my LAN clients start failing DNS queries. I'm nowhere near getting a handle on the problem.
Anyone ?
You are an experienced user, what's your educated guess for the chances that the next post reads: "Update to latest and then try again"?
thanks for the input chemlud. I am due to travel abroad for over a week in the next few days so I would like to fix this instead of dealing with more and bigger changes with a new OS version. Actually this is the reason I want to be able to reach my LAN for when I am away in case of need.
I reach my remote nets via WG, without any 0.0.0.0 involved... ;-)
And I also have another client without the 0.0.0.0 that can reach the LAN. Hence I fail to see why the other doesn't nor can make this change. For anyone thinking of helping, here is my OPN wg config:
/usr/local/etc/wireguard/wg1.conf
####################################################
# Interface settings, not used by `wg` #
# Only used for reference and detection of changes #
# in the configuration #
####################################################
# Address = 10.0.0.1/24
# DNS = 192.168.5.1
# MTU =
# disableroutes = 0
# gateway =
[Interface]
PrivateKey = {privatekey}
ListenPort = 51820
[Peer]
# friendly_name = mobile-8T-MN
PublicKey = {publickey1}
AllowedIPs = 10.0.0.2/32
[Peer]
# friendly_name = pluto
PublicKey = {publickey2}
AllowedIPs = 10.0.0.3/32
[Peer]
# friendly_name = saturn
PublicKey = {publickey3}
AllowedIPs = 10.0.0.4/32
The peer mobile-8T-MN can connect to OPN via wg and reach the LAN on 192.168.5.0/24 but the peer saturn can't and is the one I've been trying to add or change to 0.0.0.0/0 as a way to fix but I get that error.
Anyone with a thought of what I could try or where to look for a misconfiguration?
Did you add 0.0.0.0/0 in OPNsense peer config (allowed IPs) ?
This must go into client config (allowed IPs) since on server side this is the IP assigned to the client.
In other words...
SERVER SIDE:
[Peer]
AllowedIPs = IP assigned to VPN client
CLIENT SIDE:
[Peer]
AllowedIPs = IPs to be routed via VPN
For some OS you should not use 0.0.0.0/0 but 0.0.0.0/1, 128.0.0.0/1
Quote from: tiermutter on June 27, 2024, 12:32:41 PM
Did you add 0.0.0.0/0 in OPNsense peer config (allowed IPs) ?
This must go into client config (allowed IPs) since on server side this is the IP assigned to the client.
Well I did a little while ago again about 2 hrs ago. No errors in the wg log but when I came back to my next work call, the laptop was unable to get online. I had to stop wg and all was good again.
First how they're configured, then when changed to 0.0.0.0. This breaks my DNS on LAN it seems. No idea why. Happy for any ideas what to look for.
You must not put 0.0.0.0/0 into the peer's allowed IPs on the OPNsense side. That installs a route for 0.0.0.0/0 down the wireguard interface.
On the OPNsense side put only the tunnel address of the "client" with /32 in the allowed IPs field.
Ok so that's how it is set Patrick. How do I then make this client/peer be able to reach the LAN ?
On the client you configure 0.0.0.0/0 in allowed IPs.
That means the client will send everything through the tunnel.
Or, if you only want to reach the LAN while keeping Internet access local to wherever the client is, just add your LAN network and appropriate prefix length (/24?) in allowed IPs in the client.
Then all you need is a firewall rule on the wireguard interface or group permitting the client in.
> On the client you configure 0.0.0.0/0 in allowed IPs.
that's been set already client side.
>Then all you need is a firewall rule on the wireguard interface or group permitting the client in.
This is what might be missing but I have a blanket one for the whole wg net (please see pic):
Do I still need to create a per-client rule?
Plus currently-disabled LAN rule:
Looks good. For "WG net" to work - what is the tunnel address on the server/OPNsense side and what is the peer allowed IP (with /32) set to? The peer allowed IP matches the tunnel address on the client, right?
WG net the tunnel address is 10.0.0.1/24 and the peer is allowed to that instance.
The peer config is this:
[Interface]
Address = 10.0.0.4/32
PrivateKey = {privatekey}
[Peer]
PublicKey = {publickey}
#AllowedIPs = <Networks to which this client should have access>/<Netmask>
# // For example "10.11.0.0/24, 192.168.1.0/24"
# // | |
# // +--> The network area of the OPNsense WireGuard VPNs
# // |
# // +--> Network behind the firewall
AllowedIPs = 0.0.0.0/0
#Endpoint = <Public IP of the OPNsense firewall>:<WireGuard Port>
Endpoint = mydomain:51820
Does that look good?
I can connect fine. Just can't get to LAN from it.
Now I know 0.0.0.0 is not good on server side.
But if I put lan network i.e. 192.168.5.0/24 in the server side, I get an error on the wg server log. Is this also a wrong place to put it?
You must put 10.0.0.4/32 in peer allowed IPs on the OPNsense side. How often do we need to repeat that? ;)
Allowed IPs tells wireguard what is "on the other side of the connection". It's misnomed, IMHO, but that's what it is.
So on OPNsense side:
AllowedIPs = 10.0.0.4/32
--> Every packet with that destination goes in the tunnel. Every packet with that source is allowed to come out of the tunnel.
On the client side:
AllowedIPs = 0.0.0.0/0
--> Every packet with any destination address goes in the tunnel. Every packet with any source address is allowed out of the tunnel.
Apart from that - which are essentially routes, not filters - wireguard does not filter at all. It's a 100% transparent connection.
You apply firewall rules for access control once the tunnel is up and running.
Ah you are still seeing the failed attempt with it. It is set to AllowedIPs = 10.0.0.4/32. See earlier post please
So to recap.
On OPNsense side:
AllowedIPs = 10.0.0.4/32
On the client side:
AllowedIPs = 0.0.0.0/0
that's where I started. I can't access the LAN with it. This is the start.
As an attempt to fix, I changed to 0.0.0.0 and now I know it was the wrong move :)
What should I check next please? My rules are wrong maybe?
Add to allowedIPs on peer:
10.0.0.x/32 (i.e. IP of opnsense in tunnel), 192.168.a.b./24 (i.e. LAN(s) of the the opnsense)
How are you trying to "reach the LAN"? Ping? You have TCP/UDP in that rule for the WG interface - so ICMP will be blocked. ;)
- ping from your client
- do packets come out of the wg0 interface on OPNsense (tcpdump)?
- if the don't, do packets arrive on port 51820 on WAN (tcpdump)?
- if they don't, your client might be behind some firewall blocking the connection - BTW, you cannot test from inside the same OPNsense, hope that was obvious
- if packets do come in on WAN/51820 are reply packets leaving WAN towards your client?
- if they don't, the OPNsense side does not have a valid connection - are you allowing UDP/51820 in on WAN?
- etc. let's start with the basics ;)
Quote from: chemlud on June 27, 2024, 06:01:13 PM
Add to allowedIPs on peer:
10.0.0.x/32 (i.e. IP of opnsense in tunnel), 192.168.a.b./24 (i.e. LAN(s) of the the opnsense)
He's already got 0.0.0.0/0 in there - no need to add more specifics for a road warrior.
Quote from: Patrick M. Hausen on June 27, 2024, 06:02:18 PM
Quote from: chemlud on June 27, 2024, 06:01:13 PM
Add to allowedIPs on peer:
10.0.0.x/32 (i.e. IP of opnsense in tunnel), 192.168.a.b./24 (i.e. LAN(s) of the the opnsense)
He's already got 0.0.0.0/0 in there - no need to add more specifics for a road warrior.
Indeed was going to ask then how to tunnel all other addresses in that case.
For Windows see post #7 regarding default routing...
How about simply trying?
Quote from: Patrick M. Hausen on June 27, 2024, 06:01:42 PM
How are you trying to "reach the LAN"? Ping? You have TCP/UDP in that rule for the WG interface - so ICMP will be blocked. ;)
- ping from your client
- do packets come out of the wg0 interface on OPNsense (tcpdump)?
- if the don't, do packets arrive on port 51820 on WAN (tcpdump)?
- if they don't, your client might be behind some firewall blocking the connection - BTW, you cannot test from inside the same OPNsense, hope that was obvious
- if packets do come in on WAN/51820 are reply packets leaving WAN towards your client?
- if they don't, the OPNsense side does not have a valid connection - are you allowing UDP/51820 in on WAN?
- etc. let's start with the basics ;)
Not with ping but by trying to open http/https sites on the lan for instance OPN on 192.168.5.1:55443 or ssh to servers on default tcp:22.
I will start again with the basics tonight. Thanks for this.
Edit:
Methodology has been to disconnect the mobile phone from wifi and use cellular. Allow wifi tethering to it. Connect laptop vi wifi tethering to the phone. wg-quick up the wireguard client on the laptop. Try to open 192.168.5.1:55443 or 192.168.5.1:8080 (adguardhome) or ssh to another lan machine.
Quote from: tiermutter on June 27, 2024, 06:04:10 PM
For Windows see post #7 regarding default routing...
Thanks. This is a linux laptop and trying to connect by ssh to a LAN machine on tcp:22 or http/https pages to servers on LAN.
Does the system 192.168.5.1 have OPNsense as its default gateway? If it doesn't it does not know how to reach the WG network.
sorry Patrick I don't understand that.
Does it help if I post my OPN routes and interface assignments:
Also my LAN network is 192.168.5.0/24. It is a VLAN 100. The interface has address 192.168.5.1/24
Did you mean something else?
I was not aware that 192.168.5.1 is your OPNsense. I thought it was a different system on that network. Because that's what people frequently do with VPN - access the NAS or the Home Assistan in a secure manner.
Sorry for intrusion,
But, if you did correct your config for WG as was advised.
Do you see in live logs permit for the specific source and destinations being hit with permit?
Also this issue is only related to HTTP/s?
Did you do as well MSS clamping (Normalization)?
If you are connecting WG over cell, set on the client WG app [Interface] as well MTU 1390.
Regards,
S.
Using cellular / android I have no problems using default MTU, only on Windows / fiber and DSL I issued connectivity problems and solved it with 1293 (?) in client config.
Not saying it cant work with default MTU but there is a BUT.
I had the same but for cell network depending on ISP.
As I do a lot of traveling across the EU, I have seen instances where on some Cell providers the Default MTU didn't worked. Even if the WG tunnel was established and handshake was seen, keep-alive was working. The moment I wanted to access HTTP/s it basically wasn't working well.
In order to combat that lowering the MTU on the WG client in the APP helped. The value I provided is tested across half of the EU Cell providers.
Regards,
S.
Quote from: Seimus on June 28, 2024, 01:37:13 PM
Sorry for intrusion,
But, if you did correct your config for WG as was advised.
Do you see in live logs permit for the specific source and destinations being hit with permit?
Also this issue is only related to HTTP/s?
Did you do as well MSS clamping (Normalization)?
If you are connecting WG over cell, set on the client WG app [Interface] as well MTU 1390.
Regards,
S.
That's OK. I'm asking for help.
I will try this value 1390.
Quote from: tiermutter on June 28, 2024, 01:50:25 PM
Using cellular / android I have no problems using default MTU, only on Windows / fiber and DSL I issued connectivity problems and solved it with 1293 (?) in client config.
Thanks but no windows or dsl here. I could try the 1293 value though. Thanks.
I do wonder now that I have written my methodology if I have a flaw there.
QuoteMethodology has been to disconnect the mobile phone from wifi and use cellular. Allow wifi tethering to it. Connect laptop vi wifi tethering to the phone. wg-quick up the wireguard client on the laptop. Try to open 192.168.5.1:55443 or 192.168.5.1:8080 (adguardhome) or ssh to another lan machine.
So when I connect the mobile phone to the cellular network and the laptop wirelessly to it (wifi, personal hotspot), then the phone will need to nat the laptop. Although the laptop has its wg client set to allowedips=0.0.0.0 , would the NAT need something else to be bypassed by the tunneling via 0.0.0.0 ?
If yes, then though checked and I can continue with testing with these MTU values.
Well you NAT at L3, VPN such as WG is a bit higher right.
So you will NAT the IP of LAPTOP with the IP of the Phone. What is allowed in WG is basically telling what traffic destination should go via the tunnel. NAT considers only NATing the IP of the Laptop (source of the tunnel) itself as the WG header is encapsulated by the L3 header.
[IPv4] > [WG] > [Payload]
As for testing, why not to try WG on the phone over cell first. And then move the WG on the Laptop over Phone tether? One less headache in the middle.
Regards,
S.
Quote from: Seimus on June 28, 2024, 03:06:20 PM
Well you NAT at L3, VPN such as WG is a bit higher right.
So you will NAT the IP of LAPTOP with the IP of the Phone. What is allowed in WG is basically telling what traffic destination should go via the tunnel. NAT considers only NATing the IP of the Laptop (source of the tunnel) itself as the WG header is encapsulated by the L3 header.
[IPv4] > [WG] > [Payload]
As for testing, why not to try WG on the phone over cell first. And then move the WG on the Laptop over Phone tether? One less headache in the middle.
Regards,
S.
have done bud. On the phone only it works as expected. Once I thether the laptop to it, the laptop can't get to LAN, the problem I'm trying to understand and solve.
Indeed interesting!
Well at least this confirms the config is alright, the issue smells like a potential problem with the MTU.
So the next steps should be:
1. WG client on Laptop
2. Laptop connected to mobile via tether
3. Mobile on cell (LTE/5G) network
4. Change WG MTUs
5. Check if you hit rules, WAN rule for WG to be established
6. Check if you hit WG rule for traffic pass
Additionally maybe as well a capture on the WAN and WG interfaces to see whats going on.
There could be really a MTU overhead due to headers, cell networks can be wacky as I described. If the WG encrypted packet is somewhere on the path fragmented you could have such issues.
Regards,
S.
MTU is what a few have mentioned and I'm yet to test. The configs do seem right, and only the MTU changes are left to yet do from diagnosing so far. I did do some captures last night but I had to abandon it for other reason.
Will try again but with MTU changes.
Quote from: Seimus on June 28, 2024, 03:06:20 PM
Well you NAT at L3, VPN such as WG is a bit higher right.
...
Actually WG is layer 3
https://www.wireguard.com/papers/wireguard.pdf
Quote from: chemlud on June 28, 2024, 09:51:54 PM
Quote from: Seimus on June 28, 2024, 03:06:20 PM
Well you NAT at L3, VPN such as WG is a bit higher right.
...
Actually WG is layer 3
https://www.wireguard.com/papers/wireguard.pdf
Indeed ;)
Regards,
S.
Hi. I have made progress. First, I had the client misconfigured with the wrong server's public key, so without realising it, I was not establishing the wg tunnel. Or rather I did realise it at some point but going back to basics, allowed to solve that part.
So I can still by setting 0.0.0.0/0 on the client, route all outbound connections i.e. open internet successfully.
At least that is and allows me to focus on the original problem, unable to reach the LAN behind the OPN on 192.168.5.0/24
I set the logs on for all even default rules and that showed that the don't seem to be hitting the firewall. There are no blocks although I haven't done any more tcpdumps yet.
Before I go back to those, can someone please see if what I'm missing are network routes on the client?
When the wg tunnel is down, these are the routes on the client:
default via 192.168.4.1 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
192.168.4.0/22 dev wlp58s0 proto kernel scope link src 192.168.7.227 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Then when the wg tunnel is up, they are thus:
default via 192.168.4.1 dev wlp58s0 proto dhcp metric 600
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.4
169.254.0.0/16 dev virbr0 scope link metric 1000 linkdown
192.168.4.0/22 dev wlp58s0 proto kernel scope link src 192.168.7.227 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Wg up:
penguin@saturn:~$ curl https://192.168.5.1:55443
curl: (7) Failed to connect to 192.168.5.1 port 55443 after 3058 ms: No route to host
penguin@saturn:~$ ping 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
From 192.168.7.227 icmp_seq=1 Destination Host Unreachable
From 192.168.7.227 icmp_seq=2 Destination Host Unreachable
Firewall rule from wg to LAN is pass for all protocols on IPv4.
My spider senses are telling me the problem is client-side, not server side. Strenghtned by the other client (the mobile phone) with the same client settings on OPN works correctly. Naturally the client is different. Maybe the mobile client adds the appropriate routes. What do you think ?
There is no route for anything but 10.0.0.0/24 on the client that points to the tunnel. So obviously no destination on the other side of the tunnel can be reached.
Please post the client WG config again - minus private key, of course.
thanks Patrick. Here it is:[Interface]
Address = 10.0.0.4/24
PrivateKey = VMVMVMVMV
MTU = 1390
[Peer]
#PublicKey = AMAMAMAMAMNC
#This one below is the server's public key
PublicKey = ABABABAB
#AllowedIPs = <Networks to which this client should have access>/<Netmask>
# // For example "10.11.0.0/24, 192.168.1.0/24"
# // | |
# // +--> The network area of the OPNsense WireGuard VPNs
# // |
# // +--> Network behind the firewall
AllowedIPs = 0.0.0.0/0
#Endpoint = <Public IP of the OPNsense firewall>:<WireGuard Port>
Endpoint = mydynamicdns:51820
If that should be RA, the Address on the client is wrong, it should be /32 example from my client >
[Interface]
Address = 10.8.8.2/32
DNS = 10.0.0.14
MTU = 1390
PrivateKey = SUPERSECRFETPRIVATEKEY
[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = IP:51820
PublicKey = SUPERSECRFETPUBLICKEY
https://docs.opnsense.org/manual/how-tos/wireguard-client.html#step-2-configure-the-client-peer
https://docs.opnsense.org/manual/how-tos/wireguard-client.html#appendix-example-configurations
P.S. I loaded this config above into my Arch PC connected via Tether to the phone which was on Cell and I had full access to everything per my Rules on WG Interface specified in OPNsense.
Regards,
S.
thanks, that change to /24 was one done yesterday as another attempt to make it work.
I've changed it back to /32 and it is still giving me the trouble. At least I know that this way it "should work".
Also to remove the phone and cell network out of the equation for diagnostics purposes, I remembered I have another ISP data line in the house, so I've been connecting the laptop (the client in this exercise) to that wifi network. It is not a separate WAN into OPN.
I'm still stumped.
Cookie, out of curiosity, what Linux distro are you running on that laptop/PC you have the WG problem with?
Regards,
S.
Ubuntu linux desktop 22.04. kernel in use is 6.5.0-41-generic
wg-tools is v1.0.20210914
thanks Seimus
Cookie, when you bring up the Wireguard VPN up on your Ubuntu laptop, can you bring the tunnel up by the wg quick-up to see what is being configured?
Example >
sudo wg quick-up wg0
I guess you are bringing up the WG using network manager in network settings, this is another way to do it. It should print what is being configured on the network stack. And test the connection.
Regards,
S.
There is no available wg plugin for Network Manager on this Ubuntu version, so all is on command. Easy to show you :)
A bit of a run down of what is happening, especially with the routes before and after bringing the tunnel up:
penguin@saturn:~$ ip route
default via 192.168.5.1 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev wlp58s0 scope link metric 1000
192.168.5.0/24 dev wlp58s0 proto kernel scope link src 192.168.5.186 metric 600
penguin@saturn:~$ sudo wg-quick up wg0
[sudo] password for penguin:
wg-quick: `wg0' already exists
penguin@saturn:~$ sudo wg-quick down wg0
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] nft -f /dev/fd/63
penguin@saturn:~$ ip route
default via 192.168.5.1 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev wlp58s0 scope link metric 1000
192.168.5.0/24 dev wlp58s0 proto kernel scope link src 192.168.5.186 metric 600
penguin@saturn:~$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.4/32 dev wg0
[#] ip link set mtu 1390 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] nft -f /dev/fd/63
penguin@saturn:~$ ip route
default via 192.168.5.1 dev wlp58s0 proto dhcp metric 600
169.254.0.0/16 dev wlp58s0 scope link metric 1000
192.168.5.0/24 dev wlp58s0 proto kernel scope link src 192.168.5.186 metric 600
penguin@saturn:~$ nmcli --overview connection show wg0
connection.id: wg0
connection.uuid: 27491c38-6366-433b-913a-6728cdc79fb0
connection.type: wireguard
connection.interface-name: wg0
connection.autoconnect: no
connection.timestamp: 1719830174
ipv4.method: manual
ipv4.addresses: 10.0.0.4/32
ipv6.method: disabled
wireguard.private-key-flags: 0 (none)
wireguard.listen-port: 47700
GENERAL.NAME: wg0
GENERAL.UUID: 27491c38-6366-433b-913a-6728cdc79fb0
GENERAL.DEVICES: wg0
GENERAL.IP-IFACE: wg0
GENERAL.STATE: activated
GENERAL.DEFAULT: no
GENERAL.DEFAULT6: no
GENERAL.SPEC-OBJECT: --
GENERAL.VPN: no
GENERAL.DBUS-PATH: /org/freedesktop/NetworkManager/ActiveConnection/11
GENERAL.CON-PATH: /org/freedesktop/NetworkManager/Settings/15
GENERAL.ZONE: --
GENERAL.MASTER-PATH: --
IP4.ADDRESS[1]: 10.0.0.4/32
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 0.0.0.0, mt = 0, table=51820
penguin@saturn:~$ sudo wg showconf wg0
[Interface]
ListenPort = 47700
FwMark = 0xca6c
PrivateKey = AAAAA
[Peer]
PublicKey = BBBBB
AllowedIPs = 0.0.0.0/0
Endpoint = publicip:51820
This is extremely weird to me,
The config that is pushed when you bring the tunnel UP is correct, so if the rules & config of WG profiles itself, Addresses, Keys between client and OPN are correct this should just work.
I was asking about the wg-quick, because 22.04 has a BUG in the network manager that causes issue for WG.
https://www.reddit.com/r/Ubuntu/comments/wyjpkt/comment/intjnrs/
https://github.com/max-moser/network-manager-wireguard/issues/62
https://github.com/max-moser/network-manager-wireguard/issues/59
At this point, if the config is really correct my only idea would be try it in another distro if you can just for testing purposes (VM or something). To see if its related to Ubuntu specifically.
In regards of wg-tools I use the same version wg-tools is 1.0.20210914-2 on arch with KDE; I just import the profile via KDE in the system settings and it works.
Regards,
S.
Thanks for the input. It might in the end prompt me to upgrade OS version too.
Apologies for the late closure of the thread. I am away still but when I did try to connect, "it worked".
I am using the same mobile phone I was using in preparation with the difference that now it is actually roaming in another European country, not on its home mobile (cellular) network.
Perhaps for my own self reminder, the working config is as follows:
[Interface]
Address = 10.0.0.4/32
PrivateKey = AAAAAA
MTU = 1390
[Peer]
#PublicKey = BBBBBB
#This one below is the server's public key
PublicKey = CCCCC
#AllowedIPs = <Networks to which this client should have access>/<Netmask>
# // For example "10.11.0.0/24, 192.168.1.0/24"
# // | |
# // +--> The network area of the OPNsense WireGuard VPNs
# // |
# // +--> Network behind the firewall
AllowedIPs = 0.0.0.0/0
#Endpoint = <Public IP of the OPNsense firewall>:<WireGuard Port>
Endpoint = endpoint:port
Thanks to all the helpful souls that got me here.
Awesome,
Happy to see you got your working state conclusion.
Regards,
S.