QR code for pfSense WireGuard will be awesome!

@MartynK that's ok, it's a bit odd that a reboot was necessary. Maybe it was the MTU changes?

My eyes are having a hard time getting beyond 250.0.0.0. Just something about it. I say this as a free thinker that regularly uses 172.20.20.0 or 172.21.21.0 I'm putting my money on a DNS entry feeding a public IP address instead of an internal IP address, and therefore not trying to send the 25 out the tunnel, and then the ISP knocking down the port 25 traffic.

@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 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)

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.