I’m setting up split-tunnel WireGuard with pfSense+ 24.03 as server and an Alta Route10 as client. pfSense listens on UDP 51821, tunnel IP 10.7.7.1/24 (assigned). Peer = Route10 with Allowed IPs 10.7.7.2/32, keepalive 25s. WAN rule allows UDP 51821 to firewall; WG interface rule is any from WG net to LAN (also tried to any). On Route10: Binding Use Own, hostname = pfSense WAN/FQDN, port 51821, server public key pasted, PSK tried on/off, client IP 10.7.7.2/24. Remote Subnets = pfSense LAN(s) (e.g., 192.168.1.0/24) + 10.7.7.1/32.
Status shows Latest Handshake: Never and I can’t ping 10.7.7.1 or LAN hosts. Is “Use Own” correct for a pure client? Does Route10 expose PersistentKeepalive? Are my Remote Subnets right?
I haven’t had a chance to deploy the Route10 this way yet, but it could be worth perusing this support article since it has an example of a site to site style setup between Route10s at least:
So I managed to sort it out, but I wouldn’t have figured it out without using the command line and running ‘wg show’ on Route10. The issue came down to the fact that I was using a different port than the default 51820—specifically, I had set it to 51821 since 51820 was already in use. That should’ve worked fine, since I configured both ends to use that port for communication. But even though I’d saved the setting (under “Advanced” in the VPN config tab), it was still bound to 51820.
TL;DR: The GUI showed I was using port 51821, just as I’d manually set it, but the command line showed it was still stuck on 51820. Once I switched everything back to 51820, the handshake went through.
Maybe something the Alta Labs team want to look into?
Thanks for this report, and thanks for the mention @jmszuch. Thought I should comment, as we are investigating a possible provisioning issue, and your specific observation here aligns with some other things at least that I’m seeing a couple reports of. It sounds like a bug (to me), but that is not yet confirmed. However, please do know we are investigating it. I’ll follow up here once we know more.
Okay, I see what’s happening now. Your issue does not appear to be related to the bug I’m investigating.
The FE probably could use some changing to make this more clear. You need to define the port of the remote peer in the hostname field. The port also needs to be defined at each side, and they can be the same or unique as long as the hostname contains the intended port of your remote peer then it’ll work.
So for example, if you set 51821 as the port under advanced on both, make sure it’s hostname:51821 in the hostname field at both sides of the link, or ip:51821 if you are using IP instead of DDNS… but as long as you define in both locations then it should just work. By default it will be hostname:51820 unless you define a custom port here.
It will intermittently work if you have remote user VPN working as that creates a firewall rule, and then there is at least an instance of WG listening on that port, which is likely why you saw it working, but it’s just a matter of adjusting your config so that it works as desired.
Please let me know if any of that wasn’t clear, or could be expanded on.