@boyan1 said in Wireguard Gateway not coming up after reboot.: W Hey man, im trying to make the SITE A use internet of SITE B as you did, but there is no means of making that works. How did you make that works? Could you tell me please? Thanks!

Strangely enough, checking the system 4 days later, I now see that Wireguard service is reported running! The last thing I did 4 days ago was to disable Wireguard service monitoring by the Service Watchdog. Anyway, even when it was reported stopped at first, 4 days ago, the tunnels were working flawlessly. Very strange. I will keep an eye on it.

@mreardon said in Wireguard Tunnels - Gateway Recovery Behaviour intermitent: This is still an issue as of 2.8.0 / 25.07, and it drives me crazy. Gateway failure works as expected, the wireguard tunnels will fail over to the backup gateway and continue on as normal, but will never recover once the failed gateway comes back online. While a reboot will (usually) fix it, I usually just go into my routing settings and mark the secondary gateway as down, forcing it to revert back to the primary... the users tend to dislike it when I reboot the firewall in the middle of the day Thanks for adding to the post - genuinely seems to be an issue, unsure if it's a Wireguard implementation problem or a pfSense issue at this stage though. I don't know if anyone else has noticed, but it seems even worse on 25.07. I've got my Wireguard VPN's set as tiered, but pfsense is now pretty much ignoring those tiers in the failover group and firing traffic over whatever one it fancies. Nothing has changed in my setup. Same failover group, same rules pointing traffic at the failover group with the appropriate tiers set - but the tiers don't seem to make any odds. I've recreated the failover group too. I've gone back to 24.11 and it works fine there, so I'll stick on this one for a while I think.

SOLVED. Turns out nothing wrong with my tunnel setup and not due to CGNAT. The reason PING works and other traffic doesn't is due to packet size and MTU. Something on the wireless network means that the default MTU doesn't work, forcing a smaller MTU to 1280 on pfSenseB fixed this. This Reddit thread has more details of this issue: https://www.reddit.com/r/WireGuard/comments/qmsa2n/ping_works_but_sites_arent_loading/

Hi again, to be honest: I guess, I did not remember exactly what I did 2 years ago. May I was mistaken by the interface name opt2 because the SG-3100 has a physical port OPT1 and I mixed up physical and virtual names. The goal was to use 2 different tunnels, one for the mobile clients and one for the site-2-site connection. And now all is running in that way . Regards

@Bob-Dig thanks But I cannot understand why the FTP performance is crippled when going via Wireguard and not when going via the WAN. The same happens for NFS and SMB file sharing protocols. The performance over Wireguard is rather poor, although I haven't tried these over an unencrypted WAN for obvious reasons so can't really compare.

@Jarhead said in WireGuard Site-to-Site VPN: Route for 192.168.2.0/24 Missing in Routing Table: @tomasenskede Wireguard doesn't add routes automatically. And adding the "allowed IP's" is not the same as routes. As stated, you need to add routes manually with Wireguard. THANKS! when I add a gatewate and static routing it started to work fine, thanks @Jarhead

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.

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.