WireGuard Package documentation
-
Hi,
After a flawless 2.5.2 upgrade, I've decided to give WireGuard another go. I was able to use it as a remote access on 2.5.0 and was eager to do it again.
It appears that the configuration is different from previous implementation, and based on my past experience, I'm struggling to have it working properly.
I'm ready to RTFM but the documentation is no longer valid : https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/index.html
Any link for updated instructions ?
Thanks,
-
The package is still undergoing significant development work, once it settles down those docs will be updated to match the package GUI.
The general guidance there is largely the same, just that some procedural aspects changed, like setting up peers works differently.
-
I have my 2.5.2 WireGuard implementation working again - after creating the tunnel you need to add an Interface Assignment for the new tunnel (e.g. OPT1 which I renamed to WG). Then you need to assign this interface a static IPv4 address range (your peers will be using an IP within this range). You also need to go to Firewall Rules -> WG (not WireGuard) and add a default passing rule for all IPv4 traffic.
Each peer should have a single Allowed IP which is unique and matches the WireGuard configuration on the client.
-
@brookheather said in WireGuard Package documentation:
Then you need to assign this interface a static IPv4 address range (your peers will be using an IP within this range).
That was the point I was missing... I've done it once again (I've already gave it too many tries but something should have been obviously wrong at the same time so I gave up that idea).
Many thanks, a step closer to have it set up properly (works from my LAN, not from outside yet...)
-
Thanks for the tips here, I feel like I'm getting closer to my setup working, as it stands I still cannot get a remote peer connecting to my tunnel!
I set up the Tunnel:
- Left port as default
- Generated keys, made a note of the public key (PUB1)
Went into interfaces and created a new interface:
- Interface called WGI
- Network port = tun_wg0
- IPv4 config = Static
- IPv4 Address = 10.8.9.1/24
- No upstream gateway (no internet required, just access to LANs)
Went into Firewall > Rules > WGI
- Allowed anything
Created peer for for remote client:
- Tunnel = tun_wg0
- Keep Alive = 25
- Public key = PUB1
- Generated a PSK (PSK1)
- Allowed IPs = 10.8.9.0/24 & 10.8.9.2/32
Created config for remote peer
[Interface]
PrivateKey = (Generated by client)
Address = 10.8.9.2/32[Peer]
PublicKey = PUB1
PresharedKey = PSK1
AllowedIPs = 10.8.9.0/24,
Endpoint = publicIP:51820
PersistentKeepalive = 25The remote peer shows 'connected' and sends a couple hundred bytes and that's it. Looking in pfSense the tunnel shows now data sent/received and I cannot access LAN (no surprise).
Would anyone kindly point out where I'm going wrong!?
-
@topper2 Not sure if you have figured this out. It seems that the step that is missing (or not described) is the routing. Go to System -> Routing and add a Gateway for the Wireguard interface with address family IPv4 and Gateway Address 10.8.9.1.
Also for the peer entry in pfsense, you only need the pubkey from your Android phone app (or other client). The Pre-shared key is not needed. Same for the client, all you need is the pubkey from the pfsense server.
Finally, the client works just find using a URL for the endpoint. This solved the problem of IPs moving around if your pfsense server does not have a fixed one.
-
Hey dude - thanks for all your posts :)
I added the route as you advised - I'm still not getting a handshake!? What do you reckon I'm missing?
I'll try nuking it and following the guide you suggested again (which I had already followed once!) but with the added step of including the route like you said :)
I was adding the PSK as I'm setting this up to access pfSense remotely (in another country entirely) so wanted the extra layer of security! As a matter of fact I already have a separate WG tunnel working for many peers and that works without a hitch... set that up through CLI standalone.... it's getting it working with pfSense that's bugging me!
-
@topper2 said in WireGuard Package documentation:
Allowed IPs = 10.8.9.0/24 & 10.8.9.2/32
I think it should just be Allowed IPs = 10.8.9.2/32 - this is how I have it setup - the Allowed IPs is used to route traffic back to the peer so should just match the IP used by the peer.
-
Also having issues with wireguard after updating to 2.5.2 today
so configuration itself is pretty straight forward (for site to site in my case)
allow 51820 UPD ports on WAN interface on all peers
create tunnel on both sides
generate keys
assign tunnel to OPT interface
assign static IPs for the new interface (i'm using 10.10.10.1/24 for the first side and second side 10.10.10.2/24 for the second side) - leave gateway empty as that's peer-to-peer connection only no need gateway
allow all traffic in rules for the new interface
create peer with tunnel: tun_wg0
endpoint public address and UDP port of the peer
Public key of the other side's tunnel interface
preshared key (if needed)
allowed IPs: list of subnets available behind the peer AND peer's private tunnel address with /32 mask.It handshakes instantly and all the time, but neither private peer addresses nor target subnets are accessible. From my understanding there is routing missing somehow. as pfsense routing table only shows private peer\tunnel subnet routed to the tun_wg0 interface: like so
this is one side (notice missing private subnets available behind the peer)
10.10.10.0/24 link#11 U 302 1500 tun_wg0
10.10.10.1 link#11 UHS 0 16384 lo0second side
10.10.10.0/24 link#9 U 563 1500 tun_wg0
10.10.10.7 link#9 UHS 2 16384 lo0Regards,
Vladimir. -
@marvinfs said in WireGuard Package documentation:
allowed IPs: list of subnets available behind the peer AND peer's private tunnel address with /32 mask
Try with just the peer's private tunnel address with /32 mask specified.
Also shouldn't you be using two different subnets for each end of the tunnel - e.g. 10.10.10.1/24 for one side and 10.10.11.1/24 for the other?
-
@brookheather
From service mans - allowed IP lists: IPv4 or IPv6 subnet or host reachable via this peer.
otherwise how service will tell which subnets to route there?Different subnets for each side of the tunnel? Doesn't make any sense. No I haven't tried and don't think worth trying.
-
@brookheather said in WireGuard Package documentation:
Then you need to assign this interface a static IPv4 address range (your peers will be using an IP within this range).
I registered just to post here. This was it. This fixed my WireGuard issue. I could get connections and handshakes to the tunnel, but I couldn't get LAN or WAN access.
I do not remember if I had the configured in 2.5.1 or not, but since the change to 2.5.2 I couldn't get the WG tunnel to pass traffic. I didn't even need to create a gateway for the tunnel as mentioned above.
Adding the IP address fixed it all. Thank you!
