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.

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

@emnul I don’t know if this was a typing mistake but I see form your post that your WG_TEST tunnel is listening to port 52821 and your iOS device is trying to connect to 51821. These should match for both Tunnel and Peer

VPN Wireguard Tunnels:
tun_wg1
Address / Assignment: WG_TEST
Listen port: 52821

And your peer is:
[Peer]
pubKey = MY_PUB_KEY (i've confirmed it matches config in pfSense)
Endpoint = MY_IP:51821
AllowedIPs = 0.0.0.0/0

You MUST have your WG_TEST (tun_wg1) Interface /24 and your Peers as /32.

Based on the info you provided on your first post, this is how your WireGuard and Peer SHOULD look like:

Tunnel Setup:

VPN > WireGuard > Tunnels > Edit tun_wg1 Description: WG_TEST Listen Port: 51821 Interface Keys: [Auto-generated]

Interface Setup:

Interfaces > WG_TEST IPv4 Configuration Type: Static IPv4 IPv4 Address: 172.26.2.1/24 MTU: 1420

WAN Firewall Rules:

Firewall > Rules > WAN Action: Pass Protocol: UDP Source: Any Destination: WAN Address Port: 51821 Firewall > Rules > WG_TEST Action: Pass Protocol: Any Source: WG_TEST Destination: Any

Outbound (Hybrid Mode) Setup:

Firewall > NAT > Outbound Interface: WAN Source Network: 172.26.2.0/24 Destination: Any Translation: WAN Address

For Peer Config (in WireGuard):

VPN > WireGuard > Peers Description: iOS Device Tunnel: WG_TEST Allowed IPs: 172.26.2.2/32 Endpoint: Dynamic

On your iOS WireGuard App:

[Interface] PrivateKey = [Auto Generated] Address = 172.26.2.2/24 DNS = 9.9.9.9 MTU = 1420 [Peer] PublicKey = [Auto Generated] PresharedKey = [Auto Generated] AllowedIPs = 0.0.0.0/0 Endpoint = WAN IP:51821

If you are still having an issue:

This is the YouTube video I used to setup my WireGuard and it's been working flawlessly for 2+ years.

How to Install WireGuard on pfSense (Tutorial)

Follow it from start to finish in its entirety and set up as in the video. Made the mistake of cutting the video short thinking I was done but my WG was refusing to connect.

I suggest you configuring all of the IPs as in the video to get an undertsanding and a working config, then modify as you like (with your desired 172.26.2.0/24 IPs).

@pfsenserich said in Wireguard 0.2.9 - pfSense 24.11 - service issues since upgrade from 24.03:

I have confirmed if you reboot with wireguard up it crashes after reboot.

have you tried stopping the wireguard service then rebooting and seeing if it comes up without errors?

am not overjoyed at the fact I had to disable the daily cron reboots to stop this issue, but it is what it is.

whats more troubling is the lack of replies to this thread.

Will be opening a support ticket on this one eventually, just for Sh... an G.....

I tried it. I stopped the WG service and restarted the PF Sense. But even so, I can only get the service to work again by reinstalling the Wiregard package.

@gguglielmi said in pfSense CE Wireguard Throughput:

Does anybody knows if there's a difference between Plus and CE for Wireguard?

Hardware encryption support is different