Wireguard, Gateways and Routing. Completely lost and slowly going insane!

[Chaoticmess]

I'm so lost with this I'm not even sure about the right specific questions to ask in order to get back the information I need.

The best question I can think of at this point is to first check to see if what I'm trying to do is even possible and then go from there.

I have Opnsense installed on a computer. It has 2 NIC's in it. The first is configured as a WAN (IP:192.168.0.168 with a Gateway IP of 192.168.0.1 which connects to a router with internet access from my ISP) and the second is configured as a LAN(IP:192.168.2.1) which is what I want to act as a gateway to my Wireguard VPN for other computers on the that LAN.

I also have another computer on the same LAN with an IP of 192.168.2.10. Let's call it PC1, running Windows 10.

I need PC1 to have the network settings of say IP:192.168.2.10, Subnet:255.255.255.0, DNS:192.168.2.1 whereby it connects over the LAN network to the Opnsense box's LAN IP which acts as a gateway to the Wireguard VPN's internet access.

Is this possible to do without installing Wireguard software on PC1?

I've tried to follow and implement so many setup guides but none seem to work or let me do what I need.

Trying to get internet access through the Opnsense box from PC1 has proved frustratingly elusive. I could do it fine with Openvpn. The gateway was setup automatically, I could set the NAT:Outbound rule and then even add a floating block rule with NO_WAN_EGRESS giving a kill switch.

Is this simply not possible with Wireguard in its current state? That seems to be the main question I keep coming back to after reading many guides talking about installing an app on an Android or Iphone. I don't want to install apps or software on my PC I just want it to connect to the Opnsense box as a gateway through the Wireguard connection like I could with Openvpn.

I think I've managed to get as far as setting up a gateway that when adding a monitoring IP seems to suggest the Wireguard connection is being made. I just can't then get it to be accessible via PC1. See attached pic that I've hopefully attached.

[Gauss23]

Please send a screenshot of outbound NAT rules and of the rules for the 192.168.2.0/24 interface.

[Chaoticmess]

Please see attached screenshots. Hopefully they are the ones you requested.

[Gauss23]

Are you able to do a packet capture on the relevant interfaces while trying to push traffic through that gateway?

Please provide your WireGuard config (without security relevant parts). Local and endpoint.

And please show:
System: Routes: Status

[Chaoticmess]

I'm not sure how I would go about doing the packet capture?

Here are the rest of the screenshots you asked for though. Please see attachments.

I assume at this point it is possible to do what I need Wireguard/Opnsense to do?

I also assume my firewall rules look ok since you didn't suggest any changes to them?

If so what I really need to know is answers to a bunch of questions like:

If this is the config settings I get:

# TorGuard WireGuard Config
[Interface]
PrivateKey = IB-REMOVEDFORSECURITY-=
ListenPort = 51820
DNS = 1.1.1.1
Address = 10.xx.xx.xx/24

[Peer]
PublicKey = iz-REMOVEDFORSECURITY-=
AllowedIPs = 0.0.0.0/0
Endpoint = 109.xxx.xxx.xx:1443
PersistentKeepalive = 25

Do I need to put the Private key AND Public key in the Local settings page or do I just put the Public key in the Endpoint page and only the Private key in the Local page?

I've tried to do it with both but neither way seemed to help but it would be nice to know for sure which one it actually is.

Looking at the List Configuration tab I get this:

interface: wg0
  public key: vc-REMOVEDFORSECURITY-=
  private key: (hidden)
  listening port: 51820

peer: iz-REMOVEDFORSECURITY-=
  endpoint: 109.xxx.xxx.xx:1443
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 10.98 KiB sent
  persistent keepalive: every 25 seconds

This has me asking 2 questions. The first one is if it's normal for the received transfer to be 0 B?

The second one is if it's normal for the Public key to be different from the one I put in from the config settings I received from my VPN provider?

Additionally when I look at the Handshakes tab I get this:

wg0   iz-REMOVEDFORSECURITY-=   0

My question is if it's normal for the 0 to be at the end? In other screenshots I've seen in some guides it has a long number after it, yet I don't seem to get that.

It makes me wonder if I have a connection working after all which is where I feel like I'm going round in circles with no idea if what I'm doing is right because I don't have anything I KNOW is working to build upon.

I've been focusing on the firewall rules since I got an online status with a monitoring IP clearly displaying some sort of connection is active. Yet the above gives me doubt leaving me feeling lost as to knowing what is and isn't working.

[Gauss23]

You maybe should leave the private IPs visible for us, otherwise it's hard to help. Public IPs can be hidden.

What happens if you uncheck "disable routes"? Then make a screenshot of System:Routes:Status again. Maybe you're sending the packets to the wrong gateway.

[Greelan]

You don't put the same public key in both local and endpoint. The local public key corresponds to the local private key (and would have been autogenerated when you created the local config). The local public key is what you give to the peer (Torguard in your case?). The endpoint public key is what you are given by the peer (Torguard).

Your traffic stats suggest that no VPN connection is being made - the thing about WG is that it doesn't expressly tell you if a connection has failed; I guess a short codebase doesn't leave room for error reporting lol.

BTW, you can packet capture under Interfaces->Diagnostics->Packet Capture.

[Patrick M. Hausen]

@Greelan you are technically correct, but for the connection/error message part, IMHO.

There is no connection in WG. The whole thing is stateless much like GRE or IPIP. The software could log something like "received packet could not be decapsulated - key mismatch?" or similar.

[Greelan]

Loose language, my bad. My point was simply it is not always immediately obvious that a handshake has failed

[Patrick M. Hausen]

Yes, but again: there is no handshake. Each packet is "VPNed" individually. Completely stateless.