[SOLVED] Unable to set allowed IPs to '0.0.0.0' for wireguard client

[cookiemonster]

WG net the tunnel address is 10.0.0.1/24 and the peer is allowed to that instance.

The peer config is this:

Code Select Expand

[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?

[Patrick M. Hausen]

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.

[cookiemonster]

Ah you are still seeing the failed attempt with it. It is set to AllowedIPs = 10.0.0.4/32. See earlier post please

[cookiemonster]

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?

[chemlud]

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)

[Patrick M. Hausen]

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 ;)

[Patrick M. Hausen]

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.

[cookiemonster]

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.

[tiermutter]

For Windows see post #7 regarding default routing...

[chemlud]

How about simply trying?

[cookiemonster]

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.

[cookiemonster]

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.

[Patrick M. Hausen]

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.

[cookiemonster]

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?

[Patrick M. Hausen]

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.