Site-to-Site WireGuard VPN Setup Issue: RUT950 Client Unable to Establish Handshake

Product: Teltonika RUT950 Firmware Version: RUT9_R_00.07.06.18

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:

  1. 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.
  2. 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
  1. 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.
  1. Router Reboots: Both devices have been rebooted multiple times after configuration changes.
  2. 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?

Hello,

Could you do a tcpdump on the pfsense:

tcpdump -i any -n -v 'udp port 51820'

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 ?

Regards,

Hi there,

Please try adding 10.0.0.0/24 to the Allowed IPs list on each side and let me know if that helps.

Regards,
M.

Thanks! I found an issue with the keys, and now I get a successful handshake.

However, there’s still no traffic. Traceroutes from hosts behind pfSense to hosts behind the RUT950 are not routed through the VPN at all.

Traceroutes from hosts behind the RUT950 just end at the RUT950 itself.
any idea on this issue?!

Check the routes on both the pfsense and RUT950:

ip -4 route show

It would be interesting to see the full traceroute output from both lans, in particular the last successful step.

As @MatasR has suggested add the address / networks to the Allowed IPs list:

  • on the RUT side add 10.0.0.0/24
  • on the pfsense side add 10.0.0.2/32 for the RUT950 peer

A tcpdump + simultaneous ping on the pfsense and RUT would also be instructive. Filter on icmp only. Do you see something ? Icmp errors ?

And last check: have you enabled masquerading on the firewalls ? Retry with this flag disabled.

1 Like