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

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 [image: 1742936453763-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.

@Bob-Dig I found other configuration examples on GitHub: https://github.com/a4649/wireguard-multi-site In this example, site A is the "hub". In each "spoke" site, the AllowedIPs contains the remote LAN of all other sites and the tunnel interface of the hub instead of the entire tunnel network. So it seems to me that it is not a "requirement" to have the entire tunnel network specified in the AllowedIPs in all the "spoke" sites. The use case you mentioned is indeed very rare, but I couldn't really think of other reasons why the entire tunnel network is specified in each remote office's AllowedIPs setting.

@theyikes this is a pfSense focused forum. You will have better luck in the OpenWrt forum, category Installing and Using OpenWrt.

@theyikes Wireguard is not a server - client construct in the OpenVPN sense. Both end of the tunnel are peers and both can be configured the same. The difference would be that on the server you can allow clients to access local network and you don't generally want the server to allow access to the network on the client. And on the server you would allow multiple peers (clients) to access it and on the client(s) you have only one peer, the server.

Just to thank you since I cannot upvote after registration.

For info I resolved this by adding a persistent static route for the PC I wanted to connect to. Network address / Netmask / Gateway address 10.252.30.0 / 255.255.255.0 / the node address of my Wireguard device. Job done, works a treat.

I forgot to mention that I used https://dnsleaktest.com to test for DNS leaks and configured the browser to use my default resolver.