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

[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:51820Does 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.