[Solved] Wireguard setup

Started by abundantmuscle, February 04, 2023, 04:13:30 AM

Previous topic - Next topic
February 04, 2023, 04:13:30 AM Last Edit: February 05, 2023, 01:03:04 AM by abundantmuscle
Hey all hope one of you has some pointers for me or might spot a very obvious mistake I have made. I have setup both OpenVPN and IPSec tunnels etc before using pfSense and OPNsense and have never come across issues like this before. Well I have but nothing a firewall rule didn't fix.

I followed the road warrior guide including step 5 (creating the interface etc). My setup is an OPNsense box at home and 2 remote servers I wish to connect as peers to it. I setup everything according to the guide, the OPNsense box has the following networks on it:

192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
192.168.4.0/24


OPNsense is available on each CIDR above at .254. I want to be able to access the 2 peers from 192.168.1.0/24 and 192.168.3.0/24 and vice versa. I have setup the tunnel to use 10.10.42.254/24 as its CIDR. In OPNsense endpoints I have added both peers with the folllowing Allowed IPs:

Peer1: 10.10.42.1/32
Peer2: 10.10.42.2/32


In the Status tab I can see:

interface: wg1
  public key: [REMOVED]
  private key: (hidden)
  listening port: 51820

peer: [REMOVED]
  endpoint: X.X.X.X:58853
  allowed ips: 10.10.42.1/32
  transfer: 21.68 KiB received, 15.50 KiB sent
  persistent keepalive: every 30 seconds

peer: [REMOVED]
  endpoint: 46.4.23.90:39594
  allowed ips: 10.10.42.2/32
  transfer: 21.68 KiB received, 15.21 KiB sent
  persistent keepalive: every 30 seconds


I can also see the handshakes on the Handshakes tab in OPNsense. As for firewall rules, as per the guide I created one on the WG interface with source set to WG net and everything else as wildcard. My 192.168.1.0/24 and 192.168.3.0/24 also have a wildcard rule with their respective net addresses as the source. I have also tested with a fully wildcard rules in all interfaces. I have the wireguard port forwarded to my WAN as per the guide also.

Now for the peers (Both Ubuntu 22.04), they have the following config:

Peer1:
[Interface]
PrivateKey = [REMOVED]
Address = 10.10.42.1/32

[Peer]
PublicKey = [REMOVED]
AllowedIPs = 192.168.1.0/24, 192.168.3.0/24
Endpoint = [REMOVED]:51820
PersistentKeepalive = 30


Peer2:
[Interface]
PrivateKey = [REMOVED]
Address = 10.10.42.2/32

[Peer]
PublicKey = [REMOVED]
AllowedIPs = 192.168.1.0/24, 192.168.3.0/24
Endpoint = [REMOVED]:51820
PersistentKeepalive = 30


The result of route on both peers is:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         static.193.63.6 0.0.0.0         UG    0      0        0 enp35s0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0


What I can and can't do:
From the OPNsense box itself I can't ping either peer using their tunnel IP.
From machines on 192.168.1.0/24 and 192.168.3.0/24 I can ping the OPNsense tunnel IP (10.10.42.254).
From machines on 192.168.1.0/24 and 192.168.3.0/24 I can't ping either peer using their tunnel IP.
From the peers I can't ping the OPNsense box tunnel IP.
From the peers I can't ping the other peer.
From the peers I can't ping anything on 192.168.1.0/24 or 192.168.3.0/24.

Any tips or pointers, sorry about the long message but wanted to give as much information as possible.

It's not surprising at least that one peer can't ping another peer as the VPN subnet is not in allowed IPs on either peer.

Have you tried adding that?

I'm guessing, but wonder also whether having OPNsense on .254 rather than .1 has anything to with it

Yes, tried adding it, following you're comment, I have now added 10.10.42.0/24 to the AllowedIps in each peers config file. I have changed peer1 from 10.10.42.1 to 10.10.42.2 and changed peer2 from 10.10.42.2 to 10.10.42.3. I have changed the local tunnel address to 10.10.42.1/24.

Still the same results.

Quote from: abundantmuscle on February 04, 2023, 04:13:30 AM
In the Status tab I can see:

interface: wg1
  public key: [REMOVED]
  private key: (hidden)
  listening port: 51820

peer: [REMOVED]
  endpoint: X.X.X.X:58853
  allowed ips: 10.10.42.1/32
  transfer: 21.68 KiB received, 15.50 KiB sent
  persistent keepalive: every 30 seconds

peer: [REMOVED]
  endpoint: 46.4.23.90:39594
  allowed ips: 10.10.42.2/32
  transfer: 21.68 KiB received, 15.21 KiB sent
  persistent keepalive: every 30 seconds

Why are you using random ports for the peers? Just stick with the same as the tunnel.


Quote
Peer1:
[Interface]
PrivateKey = [REMOVED]
Address = 10.10.42.1/32

[Peer]
PublicKey = [REMOVED]
AllowedIPs = 192.168.1.0/24, 192.168.3.0/24
Endpoint = [REMOVED]:51820
PersistentKeepalive = 30


Peer2:
[Interface]
PrivateKey = [REMOVED]
Address = 10.10.42.2/32

[Peer]
PublicKey = [REMOVED]
AllowedIPs = 192.168.1.0/24, 192.168.3.0/24
Endpoint = [REMOVED]:51820
PersistentKeepalive = 30

Change the interface address on both peers to the actual subnet. ie /24.
A /32 will not let you browse anything.


Client port, that is the default (random) that wireguard uses unless one is explicitly set. Just to test I now have ListeningAddress in the interface section of the peers config - no change.

I changed the interface address to be in the /24 subnet (10.10.42.2/24 and 10.10.42.3/24), no change. I thought the idea with the interface address being /32 is because it would be a single IP while the peer section contains the AllowedIPs which are essentially the routes available after connection.

Anyway both changes made, still the same, no ping from OPNsense across the tunnel to the peers and vice versa, No ping to other networks from peers, no ping from peer to peer.

You want the "Interface Address" to be the actual tunnel subnet. You want the allowed IP to the the /32 for each client.

Just noticed you don't have the allowed IP's set correctly.
You're missing the LAN IP's on the client, and missing the tunnel IP's on the peers.
Wireguard terminology is so weird...
In opnsense, on the peers tab, add the LAN subnets to allowed.
In the client, on the peers tab, add the tunnel host address as a /32. So 10.10.42.1/32 (BTW, you could've kept it at .254, wouldn't make a difference)

Quote from: Demusman on February 04, 2023, 06:12:18 PM
In opnsense, on the peers tab, add the LAN subnets to allowed.

This is completely wrong. It will break routing within the LAN network, as OPNsense will route all packets destined for the LAN networks down the tunnel instead.

I suggest you research what "Allowed IPs" means in WireGuard.

Quote from: Demusman on February 04, 2023, 05:16:31 PM
Change the interface address on both peers to the actual subnet. ie /24.
A /32 will not let you browse anything.

This is also wrong. A /24 is only strictly needed on the peers if they are also routing traffic to other peers on the VPN network, ie acting as a hub like OPNsense is meant to in this case. They are not. Though changing it to /24 won't break anything in this case.

Quote from: Greelan on February 04, 2023, 07:40:42 PM
Quote from: Demusman on February 04, 2023, 05:16:31 PM
Change the interface address on both peers to the actual subnet. ie /24.
A /32 will not let you browse anything.

This is also wrong. A /24 is only strictly needed on the peers if they are also routing traffic to other peers on the VPN network, ie acting as a hub like OPNsense is meant to in this case. They are not. Though changing it to /24 won't break anything in this case.

Quote from: Greelan on February 04, 2023, 07:40:42 PM
Quote from: Demusman on February 04, 2023, 05:16:31 PM
Change the interface address on both peers to the actual subnet. ie /24.
A /32 will not let you browse anything.

This is also wrong. A /24 is only strictly needed on the peers if they are also routing traffic to other peers on the VPN network, ie acting as a hub like OPNsense is meant to in this case. They are not. Though changing it to /24 won't break anything in this case.

This is what I thought. Am I correct that I should use the /32 in the interfaces on the peer and just have the same /32 address listed in the allowed IPs on the OPNsense endpoints tab while having the networks behind OPNsense listed as the AllowedIPs in the peers config?

Yes, that should work.

I have exactly that setup for my phone and tablet to connect to OPNsense. And I can perform all the tests that you attempted (except my phone can't ping my tablet when both are connected to the VPN, because on each device I have not listed the VPN IP of the other in Allowed IPs - so all expected behaviour).

I wonder whether there are additional steps - routing, firewall, whatever - that you need to do on the Ubuntu peers that are otherwise handled automatically by the WG app on my phone and tablet.

I guess the next logical step so for me is to setup a 3rd peer (iPhone) and connect and see if the tests work if so at least then I know its some routing/iptables issue on the ubuntu peers. Will update in about 90 minutes once home and can test it.

BTW, I notice that your interface on OPNsense is wg1. Does that mean you have another WG interface for something else (wg0)? Could that be causing routing conflicts?

Quote from: Greelan on February 04, 2023, 07:34:02 PM
Quote from: Demusman on February 04, 2023, 06:12:18 PM
In opnsense, on the peers tab, add the LAN subnets to allowed.

This is completely wrong. It will break routing within the LAN network, as OPNsense will route all packets destined for the LAN networks down the tunnel instead.

I suggest you research what "Allowed IPs" means in WireGuard.

Not wrong. You have to tell it what networks are allowed to traverse the tunnel.
Works very well on multiple tunnels here.

February 04, 2023, 08:10:11 PM #13 Last Edit: February 04, 2023, 08:12:37 PM by Demusman
Quote from: Greelan on February 04, 2023, 07:40:42 PM
Quote from: Demusman on February 04, 2023, 05:16:31 PM
Change the interface address on both peers to the actual subnet. ie /24.
A /32 will not let you browse anything.

This is also wrong. A /24 is only strictly needed on the peers if they are also routing traffic to other peers on the VPN network, ie acting as a hub like OPNsense is meant to in this case. They are not. Though changing it to /24 won't break anything in this case.

It's not on the peers. It's on the peer interface.

https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html
Scroll down to client configuration.

February 04, 2023, 08:19:25 PM #14 Last Edit: February 04, 2023, 08:21:31 PM by Greelan
Quote from: Demusman on February 04, 2023, 08:09:35 PM
Not wrong. You have to tell it what networks are allowed to traverse the tunnel.
Works very well on multiple tunnels here.

As I said, you need to look into what Allowed IPs means. Allowed IPs on a peer (endpoint) config in OPNsense means (a) the DESTINATION IPs that can be reached at that peer, and (b) the converse, which is the SOURCE IPs that are allowed to come from that peer.

On the peers themselves (the Ubuntu hosts here), you would of course specify the LAN networks as Allowed IPs for the OPNsense peer endpoint (as the OP has done), because you want the devices to reach those IPs over the tunnel and receive traffic from them over the tunnel.