WireGuard VPN not functioning despite following guide precisely

Started by strongthany, October 27, 2023, 05:11:11 PM

Previous topic - Next topic
I have been trying to get wireguard set up on my DEC695 and despite following the road warrior guide as close as possible I can't get it functioning the way I want. I can connect to the VPN and access the internet at large fine, but I am unable to access my lab on the LAN. I have included screenshots of my config settings, and can provide more upon request, but at this point I'm not sure what is going wrong.

Client config:
[Interface]
PrivateKey = ClientPrivateKey
Address = 10.0.2.2/32

[Peer]
PublicKey = PublicKeyFromFirewall
AllowedIPs = 0.0.0.0/0
Endpoint = PUBLIC.IP.ADDRESS:51820

Shouldn't

Address = 10.0.2.2/32

Match your actual network size (not /32)?


Cheers,
Franco

Quote from: franco on October 27, 2023, 05:37:40 PM
Shouldn't

Address = 10.0.2.2/32

Match your actual network size (not /32)?
---------------------------------
I have had it match before, doing /24, but the issue persists all the same. I can change it though should that be the better way to do it going forward.

I have changed my local config to the following:

[Interface]
PrivateKey = ClientPrivateKey
Address = 10.0.2.2/24

[Peer]
PublicKey = PublicKeyFromFirewall
AllowedIPs = 0.0.0.0/0
Endpoint = PUBLIC.IP.ADDRESS:51820

Quote from: franco on October 27, 2023, 05:37:40 PM
Shouldn't

Address = 10.0.2.2/32

Match your actual network size (not /32)?

Since it's a point to point link it is quite common practice to use /32 on the clients and e.g. /24 on the server, specifically in a typical star topology with one server and many clients.

@strongthany you posted your firewall rules but the WireGuard config on the OPNsense would be much more interesting and probably relevant.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Ok, description is a little unclear where the LAN is.


Cheers,
Franco

@patrick fair point, I only had space for 4 uploads though so I tried to pick what I thought might be most useful. I do want to note that the connection does work in the sense I am able to connect to the internet, just not resources on the lan, such as my home server.

On the status tab of the wireguard settings on the firewall, this is what it states:

interface: wg1
  public key: PUBLICKEY(can confirm it's the same key as on my laptop)
  private key: (hidden)
  listening port: 51820

peer: hash of peer, not sure if this is safe to post or not.
  allowed ips: 10.0.2.2/32

In my eyes your configuration and firewall rules look fine.

To further troubleshoot, ping a device on your LAN from your client and tcpdump on the wg1 interface to see if the traffic gets to the firewall.

tcpdump -i wg1 proto ICMP -n
always
Afterwards do a tcpdump on your LAN interface to see if the ICMP echo request gets there, and if an ICMP echo reply is generated.

Turn on logging on the firewall rule that allows the traffic on the wireguard interface and check if the traffic matches in "Firewall: Log Files: Live View"

This will help to get closer to the error.

EDIT:
- In the [Interface] section of wireguard, there should be /24 or /64 on the firewall. For point to point it can also be /32 and /128 on the client as Patrick said.
- In the [peer] section of wireguard, on the opnsense there should be /32 for the allowed IP. On the client, it can be either the 0.0.0.0/0 for a full tunnel, or something like 10.0.2.0/24, 192.168.1.0/24 for a split tunnel.


Hardware:
DEC740

@Monviech So I did what you said...kind of. I ran a packet capture via the web ui instead. I have included a screenshot of the settings I ran. Note I also ran the test again with the protocol as any and another test with promiscuous on and off. In all situations, the packet capture turned out empty. On my laptop I would connect to the VPN while connected to a hot spot on my phone, then ping the IP address for my DNS server and then for the firewall itself. In both cases I was not able to reach the resource. I was however able to ping google and able to access the internet through Firefox.

Theory: am I even connecting to the VPN properly. When I go to whatismyipaddress dot com I see that my mobile carrier is my ISP, which is different for that of my home. I think this theory holds some water, as if there was an error we would see SOMETHING in the packet capture.


If you have IPv6 on your mobile device, and only define an ipv4 full tunnel with 0.0.0.0/0, your device still prefers ipv6 to go to websites. For a really full tunnel you would need ::/0 in allowed IPs on the client in addition.

But then you would need a dual stack wireguard tunnel with GUAs in addition to the private IPv4 address.

For troubleshooting purposes, don't use 0.0.0.0/0 on the client, just use 10.0.2.0/24 as allowed IPs and try to ping 10.0.2.1.

Edit: Also create an any any any rule on the Wireguard (Group) interface. I don't trust the wireguard net alias for troubleshooting purposes.
Hardware:
DEC740

I changed the IP to 10.0.2.0/24 but when I try pinging like suggested I get this:

ping 10.0.2.1
PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data.
z^C
--- 10.0.2.1 ping statistics ---
36 packets transmitted, 0 received, 100% packet loss, time 35541ms

What would I need to add to ensure that it can still work with IPv6? My ISP only gives me a IPV4 address.

What does the handshake say on the client side. Is it 0bytes received and 100+ bytes sent? Or is it 100+ bytes received and 100+ bytes sent?

Also please add any any any firewall rules to the Wireguard (Group for troubleshooting purposes.

For a full tunnel you need "0.0.0.0/0, ::/0" on the client in allowed IPs. IPv6 simply wont work then, but you dont have traffic outside the tunnel.
Hardware:
DEC740

WG-UP
Warning: `/etc/wireguard/wg0.conf' is world accessible
  • ip link add wg0 type wireguard
  • wg setconf wg0 /dev/fd/63
  • ip -4 address add 10.0.2.2/24 dev wg0
  • ip link set mtu 1420 up dev wg0
    interface: wg0
      public key: publickey
      private key: (hidden)
      listening port: 57081

    peer: z1vcnYO+25OXVTxTDmoBby6n6beXVUDtRhQr0LyEomA=
      endpoint: public.ip.address:51820
      allowed ips: 10.0.2.0/24


    I have included a screenshot of firewall rules for wireguard(group). There previously was none but I decided to recreate the single rule I had in the regular wireguard firewall rule.

    I also noticed that when connected I can't ping IPv4 addresses, namely that I can't ping cloudflare's DNS address.

    ping www.google.com
    PING www.google.com(yo-in-f106.1e100.net (2607:f8b0:4002:c0f::6a)) 56 data bytes
    64 bytes from yo-in-f106.1e100.net (2607:f8b0:4002:c0f::6a): icmp_seq=1 ttl=108 time=65.8 ms
    64 bytes from yo-in-f106.1e100.net (2607:f8b0:4002:c0f::6a): icmp_seq=2 ttl=108 time=71.5 ms
    64 bytes from yo-in-f106.1e100.net (2607:f8b0:4002:c0f::6a): icmp_seq=3 ttl=108 time=87.3 ms
    ^C
    --- www.google.com ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2003ms
    rtt min/avg/max/mdev = 65.752/74.863/87.317/9.115 ms
    ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    ^C
    --- 1.1.1.1 ping statistics ---
    17 packets transmitted, 0 received, 100% packet loss, time 16382ms

I really want to know about your client, if it has more than 0 bytes in "received".

Cause if it has 0 bytes in received the handshake failed. That means the keys dont match, or the opnsense doesnt get the handshake paket.
Hardware:
DEC740

I'm not sure I follow. When I WG-UP(alias to sudo wg-quick up wg1 ; sudo wg) on my client(my laptop) it shows you what I just sent. When I run ping from the client(my laptop) all pings fail to reach out. But from the way the WG-UP command looks it seems to complete the tunnel. additionally when I go to VPN --> WireGuard --> Handshake I see the following:

wg1   pubkey-on-firewall-endpoint   1698437456

So I can compare and be sure, what is the paring of the keys supposed to be between the local tab, endpoints tab, and the client(my laptop)? I feel like I have it correct but I'm not going to rule out me messing something up there.


For your reference, this is how a working wireguard connection on a linux client looks:

root@ip212:~# wg
interface: wg0
  public key: XXXX
  private key: (hidden)
  listening port: 51820

peer: XXXX
  endpoint: XXXXXX:51820
  allowed ips: 10.4.4.0/24, 172.16.0.20/32

root@ip212:~# ping 10.4.4.1
PING 10.4.4.1 (10.4.4.1) 56(84) bytes of data.
64 bytes from 10.4.4.1: icmp_seq=1 ttl=64 time=26.5 ms
64 bytes from 10.4.4.1: icmp_seq=2 ttl=64 time=12.7 ms
^C
--- 10.4.4.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 12.674/19.572/26.470/6.898 ms
root@ip212:~# wg
interface: wg0
  public key: XXXX
  private key: (hidden)
  listening port: 51820

peer: XXXX
  endpoint: XXXXX:51820
  allowed ips: 10.4.4.0/24, 172.16.0.20/32
  latest handshake: 2 seconds ago
  transfer: 380 B received, 404 B sent


Here you can see, that when you invoke "wg" there is no transfer the first time. Wireguard is not chatty, it waits for traffic to initialize the first handshake. Thats when after I sent the ping, the transfer shows B received and B sent. That means the handshake completed and the traffic flows.

EDIT: Also whats important to know, wireguard is stateless. It doesn't "know" that it's connected, or on, unlike IPsec. Wireguard only throws packets at the endpoint specified. If the private/public keys match, and the endpoint is configured to allow the packet through the firewall onto its socket, a handshake occurs.
Hardware:
DEC740