@McMurphy exactly.
I started by setting just the MTU (to 1420). This didn't work.
After the reply from @TheNarc I did a test and additionally set the MSS value as well.

Ultimately, you want the real MSS value to be smaller than the MTU (typically 20 bytes for IP header data and 20 bytes for TCP header, so 40 bytes in total).
However, when you read the description field of the MSS value in pfSense it says

If a value is entered in this field, then MSS clamping for TCP connections to the value entered above minus 40 for IPv4 (TCP/IPv4 header size) and minus 60 for IPv6 (TCP/IPv6 header size) will be in effect.

This is why I set the same value as MTU. I actually don't know why this changes things. I would think that implicitly, the MSS should be affected by changing the MTU value. After all, the amount of data that can fit in a TCP segment directly depends on the overall size of the packet minus all headers. I guess that it would probably also work if you only set the MSS (with reverse logic: How should a packet ever get bigger than its payload size plus all headers), but I haven't tested.

I am no network expert however and the finer details of packet delivery are a mystery to me. I am always happy if I can get things to work ;).

@Bob-Dig @keyser
Ahhh, OK. So the wg<#> Wireguard interface will be assigned to a new logical pfsense interface (as WAN, LAN, OPT1, and OPT2 already have things assigned under Interface Assignments), which will be the next in logical sequence, ergo OPT3. OK, thanks, that helps!

@Ryu945 I never figured out how to get it working in self DNS mode like I could with OpenVPN. I had to put the DNS Resolver in forwarding mode to get it to work.

I also figured out that both the client and server need wireguard rules saying both client LAN to server LAN and server LAN to client LAN.

@Bob-Dig yeah lol, but I'm pretty sure I've followed everything to the letter as the other services are working or it's something small I'm overlooking....

Same issue for me as well. Just came to check if others have the same problem.

I have 3 wireguard interfaces, one is a client VPN, other two are gateways for site to site VPN. When booting up, pfsense says the service is not running, but all tunnels work just fine.

If I click to start the service sometimes it works and it shows up, other times it still fails and shows not running. Either way, all wireguard interfaces work just fine.

@Bob-Dig
Yep, I get it. A bit of reconfiguration and I should have it working the way I had expected it to.

🙏 thanks

@cosmoxl That's makes at least 2 smart people. Well let's keep our fingers crossed.

@viragomann
i did.
i can reach the pfsense LAN's easily but i cant reach the ISP LAN . please look at the image i uploaded.
how do i get "back" to the native LAN ?

thanks

@Bob-Dig
outbound nat is in Hybrid mode now.
dont understand the other questions..

@Bob-Dig Thanks Bob I have it fixed now.

I found this guide years ago. This was back before there were any pfsense VPN guides on the internet. The site has since gone down, but is still on the WayBackMachine. There is a brief explanation of the Wireguard MTU and MSS and how they relate to each other.

DevinMadeThat - Guide: Adding Proton VPN with WireGuard to pfSense

Excerpt:

MTU: 1420
Maximum Transmission Unit: Because of WireGuard's overhead, you want to set it for 1420 MSS: 1420
Maximum Segment Size: You want this clamped to 1380, but it's calculated minus 40 (for 40 bytes of v4 header) from whatever you type here. So you want to enter 1420 (1420-40=1380)

Hi!

I've the same on my pfSense-to-pfSense Wireguard tunnel.
When I've a gateway fallback on one side I need to reboot the remote side to have it up again.
Very, very annoying!

Thank you!

Thanks for the help. I am considering/debating whether to move the tunnel to the edge using the WG package on PFS.

any other suggestions on what might be the issue?
Cheers

It's been a while since the last post; this thread is one of a handful of claims of anyone using this design -- where connected wireguard clients are firewalled until they pass a web authentication service -- that I could find anywhere on the internet. So I have some questions:
  
@mcr19 said:

WireGuard works with predefined IP-Addresses on host and server but as far as i understood the Captive Portal as described in RFC 7710 works with special fields in DHCP

This seems to imply that the RFC 7710 captive portal system just fundamentally won't work for wireguard peers. So how did you overcome this issue for clients? Do they just have to remember to open the auth portal manually after connecting wireguard?

I then proceeded to build my own wireguard-server with web-based authentication service with saml2 and iptables to allow connections after successful login.

Can you say more about how this design was implemented? How has it worked for you over the last 2-3 years?

Update on the issue.

All Tunnels configured under pfSense CE 2.7.1 are still working after an update to pfSense CE 2.7.2

However

New tunnels do not work.

What's the theory here? If a packet enters pfSense through, let's say, a LAN interface with an MTU of 1500 and ends up being routed through the Wireguard interface (MTU 1432 for example) like tun_wg0 to reach the other side of the tunnel? Are the oversized packets properly fragmented or are they considered errors at this point? Possibly returning unreachable/oversized ICMP to the LAN interface origin? I mean, what if the packets counted as errors on the tun_wg0 interface are not actually errors (and should not be counted as such)? Any PMTUD attempt from the LAN to the remote destination through Wireguard would then accumulate "errors" in those counters, when it shouldn't?
Pure conjecture. I'm just trying to make sense of it.

So finally I got Wireguard working in pfSense with a macOS and Android peer. It took quite some help from ChatGPT which explained the IPv6 addresses for the VPN, and helped get the various subnets right. The pfSense setup is fairly vanilla domestic setup, no special settings applied.

Here's the key details that pulled it over the line. The LAN is on 10.0.0.0/24 and the VPN subnet is 10.1.0.0/24.

The pfSense interface for Wireguard is set to have both static IPv4 and IPv6 addresses which are set to 10.1.0.1/24 and fd00:1:1:1::1/64 respectively. The MTU is set to 1420. Otherwise the settings in the pfSense Tunnel are straightforward.

The settings for the macOS peer in pfSense are dynamic peer is set, and the allowed IPs in the Peer configuration are 10.1.0.4/32 and fd00:1:1:1::4/128. The settings for the Android peer are similar, just replacing the 4 above with a 2. Again, the MTU is set to 1420.

The only firewall rule that seems to pass any traffic is Firewall / Rules / WireGuard
4824e018-b50b-4935-bc3d-50f6e7513696-image.png
There seems to be no need to put rules in the Wireguard interface firewall section. Similarly, there seems to be no need for any NAT settings, just leave on hybrid outbound NAT.

Then to the peer settings on the devices that connect to the VPN. The key settings are adequately documented in many other places, no need to repeat that but the IPv6 addresses are harder to find.

Wireguard on the macOS peer has this configuration -

[Interface] PrivateKey = Ixxxyyyzzz2/GA3HDeE8GaoPZappqqqrrrEwrzLMHY= Address = 10.1.0.4/24, fd00:1:1:1::4/128 DNS = 8.8.8.8, 10.0.0.1 MTU = 1420 [Peer] PublicKey = vqverysecretkeylhiddenhereGQJHepd1zk= AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = [2a00:6020:1000:33::1234]:51820

The Android peer is similarly set up, notable are the DNS settings, Endpoint and Allowed IPs. Of course it is helpful to completely stop any other VPN you may have installed such as HMA, and in the VPN settings make sure that Always-on VPN is switched off, as this will block Wireguard.

Please let me know if any of this is incorrect, but otherwise This Works For Me (tm) and hope it helps someone.