Problem Description: I am attempting to establish a site-to-site WireGuard VPN tunnel between my Teltonika RUT950 (acting as a client on a mobile network, RUT950 LAN: 192.168.2.0/24) and a pfSense firewall (acting as the WireGuard server, pfSense LAN: 192.168.1.0/24, with a public IP accessible via DNS: myvpn.example.com).
I have successfully added the WireGuard peer for pfSense on the RUT950, and it appears in the list of peers. However, no handshake ever occurs between the two devices. On pfSense, under “Status → WireGuard,” the peer representing the RUT950 (which I’ve named RemoteSite on pfSense) consistently shows “Latest Handshake: never”. This indicates that either the RUT950 cannot initiate contact with pfSense on the WireGuard port, or the response from pfSense is not reaching the RUT950.
Troubleshooting Steps Performed:
WireGuard Instance on RUT950 created and enabled: The instance (VPN2Home) is “On” and has the correct IP 10.0.0.2/24 with unique keys.
Peer on RUT950 added and configured: I have successfully added the peer (hemma) on the RUT950 with the following settings:
Public Key:[PF_SENSE_PUBLIC_KEY] (pfSense’s public key)
Endpoint host:myvpn.example.com
Endpoint port:51820
Allowed IPs:192.168.1.0/24 (pfSense LAN)
Route allowed IPs: On
Pre-shared key:[PRE_SHARED_KEY]
Persistent keep alive:25
pfSense configuration verified and updated:
Tunnel (wg0) is enabled, listening on port 51820 with IP 10.0.0.1/24, and a correct public key ([PFSENSE_WG0_PUBLIC_KEY]).
Peer (RemoteSite) for RUT950 on pfSense has the correct public key from RUT950 ([RUT950_PUBLIC_KEY]), the correct pre-shared key ([PRE_SHARED_KEY]), and Allowed IPs set to 192.168.2.0/24 (RUT950 LAN). The Endpoint is dynamic, as expected.
Firewall rules on pfSense:
WAN rules allow UDP traffic on port 51820 to the WAN address.
WG0 rules allow traffic between 192.168.1.0/24 and 192.168.2.0/24.
LAN rules allow traffic between 192.168.1.0/24 and 192.168.2.0/24.
Router Reboots: Both devices have been rebooted multiple times after configuration changes.
IP Addresses: pfSense has a public IP, RUT950 is on a mobile network (dynamic IP).
Question for Support: Despite what appears to be correct peer configuration on both sides and appropriate firewall rules, no WireGuard handshake is occurring. What could be preventing the handshake, especially from the RUT950’s side when it’s on a mobile network? Are there any hidden settings, or specific requirements for WireGuard on mobile connections on the RUT950 that are not apparent?
Do you see incoming packets ? Outgoing ones ?
If there is nothing something is wrong at the RUT950 side execute the same tcpdump and check if you have outgoing packets.
If you have incoming packets but no outgoing ones on the pfsense side the most probable cause is a key mismatch somewhere.
If you have both incoming and outgoing packets on the pfsense sense with no handshake check the destination address and port of the outgoing packet. Is it the same as the source address and port of the incoming one ?
This is an update to my ongoing WireGuard issue. The core problem persists: traffic from my local network (192.168.1.0/24) to the RUT950’s local network (192.168.2.0/24) is not being routed via the WireGuard tunnel. My tracert still shows the traffic going out to the internet instead of through the VPN tunnel.
I have meticulously re-checked the pfSense routing table (Diagnostics -> Routes) and it definitively shows no route for 192.168.2.0/24 pointing to the WireGuard interface (tun_wg0 or wg0).
This is occurring despite the WireGuard peer “Orion” on pfSense having 192.168.2.0/24 correctly listed under “Allowed IPs”. This configuration should, in theory, automatically add the necessary route.
To reiterate the configuration and steps taken so far:
pfSense (Server) Configuration & Troubleshooting:
WireGuard Peer “Orion”:192.168.2.0/24 is correctly set as an “Allowed IP”.
Firewall Rules (WG0 Interface): Two rules are in place allowing all traffic in both directions between 192.168.1.0/24 and 192.168.2.0/24.
Handshake Status: The handshake with the RUT950 (Orion) is consistently active, with RX/TX data flowing, indicating the tunnel itself is up.
Troubleshooting Steps Performed on pfSense:
Restarted the WireGuard service via Status -> Services.
Toggled the “Enable Peer” option for the “Orion” peer (VPN -> WireGuard -> Peers), saving and applying changes after each toggle.
Removed a previously added manual gateway under System -> Routing -> Gateways that was pointing to 10.0.0.1/24, understanding that it was incorrectly configured and WireGuard should handle routing automatically.
RUT950 (Client) Configuration:
WireGuard Interface IP:10.0.0.2/24.
WireGuard Peer (“Hemma” / “Site2”): “Allowed IPs” include 192.168.1.0/24 with “Route allowed IPs” enabled.
Firewall (WireGuard Zone): The “Forward” setting for the WireGuard zone has been changed from Reject to Accept.
Reboot: The RUT950 has been rebooted after all configuration changes.
Given these details, the primary issue remains why pfSense is not adding the 192.168.2.0/24 route to its routing table, which is preventing communication.
Any further insights or troubleshooting steps would be greatly appreciated.
Sure it should but apparently it doesn’t as you mention.
From 192.168.1.x can you ping both 10.0.0.1 and 10.0.0.2 ? 192.168.2.1 ?
Do a tcpdump on the pfsense with the following arguments:
tcpdump -i any -n -v 'udp port 51820 or icmp'
What is the result ? Do you see ICMP errors ?
What are the routes on the pfsense ?
Can you change the firewall on the RUT for wg0=>lan, set it to Accept/Accept/Accept and masquerading off ?
There should be no requirement to do that, Allowed IPs + Route Allowed IPs set should be enough.
Do you have the equivalent of a “Route Allowed IPs” flag on the pfsense ? If so, is it set ?