pfSense 23.01 problem with wireguard tunnel

Hi everybody,

I’m having a strange problem while configuring a wireguard tunnel on my SG6100.
I’ve configured my wireguard tunnel, and it seems working fine. I get connected to my firewall and can ping both the firewall wireguard ip at 172.16.2.1/29 and lan ip at 10.0.0.254/24.

I can’t ping 10.0.0.20 both directly from the tunnel interface in pfSense and connected with a wireguard peer even if the firewall rules seems right.

I can successfully ping other devices on the LAN network such as 10.0.0.60 etc…

The address I’m trying to ping it’s a truenas scale server.

Feedback appreciated.

Thanks
Nicola

I have a remote access video here, make sure you get firewall rules and allowed IP lists right.

Thanks for the fast relpy. I’ve used exacly your video to setup. I really appreciate your videos, they are one of the best things I’ve discovered to help me grow my knowledge.

The only different thing I’ve done is to assign the tunnel to a network.

The strange thing is that I can successfully ping other devices in the same network without any problem.

If I use trace route on the wireguard peer the comunication is sent to 172.16.2.1 which is the pfSense wireguard address, but it ends there.

Here is my rules for the two networks.
REMOTA which is the wireguard tunnel


UFFICIO which is my local network

Here are the ping reults when I try to ping 10.0.0.20 and 10.0.0.60 from 172.16.2.1.

PING 10.0.0.20 (10.0.0.20) from 172.16.2.1: 56 data bytes

--- 10.0.0.20 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
PING 10.0.0.60 (10.0.0.60) from 172.16.2.1: 56 data bytes
64 bytes from 10.0.0.60: icmp_seq=0 ttl=64 time=1.065 ms
64 bytes from 10.0.0.60: icmp_seq=1 ttl=64 time=0.641 ms
64 bytes from 10.0.0.60: icmp_seq=2 ttl=64 time=0.575 ms

--- 10.0.0.60 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.575/0.760/1.065/0.217 ms

Thank for the help.
Nicola

I am assuming that 10.0.0.20 is your TrueNAS Scale server, check the Kubernetes Settings and see if the IP ranges overlap with the 172.16.2.0 network as I think they do by default which means TrueNAS scale can’t reply because it thinks that address is local to Kubernetes.

It was exacly that. Thank you so much. I had it narrowed down to some issue with my TrueNAS scale server, but this didn’t even cross my mind.

Thanks again, have a nice day.
Nicola

1 Like