Ok, so I got it to work. Not sure that where the problem was exactly. Was it in misconfiguration or in my human element... In general WireGuard tab I had rule from this guide https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html. I removed all the configurations from that guide and left only configurations from this guide https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html. Here I noticed that netcatting the port gave connection timeout and trying to access the port using actual client worked... So after coming to conclusion that port forward works, I started adding the remote access using already mentioned guide https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html with one exception: before adding rules to general WireGuard tab as said in the guide, I created an own interface for this, and added the "Pass VPN traffic from WireGuard peers" rule under the tab with the new wg interface. So, I have no rules under general Wireguard tab now. Now both use cases are working well. Thanks to everybody who helped and hopefully this post will help somebody with a similar issue. PS. port forwarding ssh port was just a port forward test, as I thought ssh would be an easy service to test that port forwarding works. Going to use another service for actual port forwarding use case and use ssh over remote access.

Last time I saw that happen it was due to an invalid configuration where two peers on the same tunnel had Allowed IPs set to 0.0.0.0/0. We're adding input validation to prevent that invalid configuration: https://redmine.pfsense.org/issues/11465

Mods even after a fresh install of 21.02p1. I still have the same errors on the status/ interface page for my SG3100. do you suggest this be moved to the Official Netgate forum? I think it should be on the radar just really low since everything "appears" to be working[image: 1614427711162-screen-shot-2021-02-27-at-7.08.01-am.png]

Sorry, this is a duplicate, please ignore.

Remember unless you define the remote peer address, Gateway monitoring actually is monitoring the local wire guard address not remote address which from a monitoring perspective is pretty useless

@slugger I owe you a debt of gratitude for your last post. You have tremendously clarified my thoughts and helped me resolve some long standing questions/misunderstandings/uncertainties that I've had with regard how VPN's work. I'm sure that the knowledge you passed on to me in your post will benefit me for years to come. Thank you, very, very much!

@slugger So I know exactly whats going on. As I said this laptop connects to two VPNs and creates two tunnels: tun0 and tun1 When it connects to tun1 it starts having issues letting WG access it. I guess it's interesting why it's going on and how to control it, but I am happy it's clear what's going on. I thought that by using on ubuntu option "Use this connection only for resources on its network" takes care of this issue, but maybe not (maybe a bug in WG or Ubuntu VPN :) ). [image: 1614195339509-3ae154f3-3220-41e4-b664-7f7c660d37b0-image.png] Definitely some difference between OpenVPN and WG Thanks for your help !

@jimp Hello Sir. I have sort out all issues and now i have more specific questions.(Working now). I have added a rule on Wan interface, destination wan address for the port used on both sites. Is this necessary to both ? (1 site has static public ip, the peer is dynamic) I have a rule on both sites Lan's: source * (any) instead of Lan net. Does this needed ? I have allow all rule on WireGuard auto created tab and also on the Wireguard virtual interface i have made the assignment. Does those rules both needed ? Thank you , your comments are much appreciated.

There is no service or daemon to restart, it's an interface configuration. It can't just "stop working" in that way.

I'm posting a follow up to my original post with a description of what resolved my issue in case someone comes across this post with a similar problem. The fix I implemented was to change the MSS value for the interface I created for the Wireguard VPN. The following picture shows the MSS setting I changed from a default of "Blank" to 1380. I came to this solution by reading this Netgate blog posting https://www.netgate.com/blog/wireguard-in-pfsense-2-5-performance.html [image: 1614093070889-2ac9afb9-30d8-4137-b455-32e92bc8bf23-image.png] Note: The value in the Description field above does not match the value for the Description field in the tunnel setting in my earlier posting. This is just because I was playing around with the settings when trying to resolve the issue and the value was changed. The discrepancy has no relevance to the solution which was entering 1380 in the MSS field.

see https://redmine.pfsense.org/issues/11302

@periko said in Peer for each mobile client?(SOLVED): @virgiliomi thanks, question answer. Maybe that feature will for pf+, I had seen that feature on Linux groups. That has nothing to do with plus or not, the QR code logic is already there. Just read the posts from jimp: https://forum.netgate.com/post/960960 Long story short, they are working on it, but it's not that "simple" as just create a QR code as WG treats every peer the same so it's not just a "client export" thingy but the exporter has to be flexible as to the settings the user wants the device to have.

Thanks @virgiliomi, setting DNS to 10.6.210.1 has resolved the issue. Though I'm still seeing CLOSED:SYN_SENT against Transmission, but this I guess something else.

@ab5g Sounds good, thanks!

I copied this from the WireGuard documentation: This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT. I think by saying “a keepalive packet is sent to the server endpoint” they must mean the public IP address because on the pfSense GUI the Endpoint address is the public one and the Peer WireGuard Address is used to describe the peers tunnel address.

@dhiru Yes, agreed - and similar to the link above from @AB5G. There is a way to do this in the webConfigurator as well (you can set MSS inside the interface). I tried it, and it works ... and also fixes my issue, thanks! What's very odd, I can see the MSS webConfigurator setting works (based on tcpdump captures). But when I upgraded from 2.5-RC to 2.5 => it no longer seems to be needed. Huh? Thanks!

@beachbum2021 disregard, apparently there's already a thread on this subject.

@p1erre That's pretty cool. I don't have a WireGuard endpoint to play with so thanks for testing it. It kind of negates the point of using WireGuard for slight it's speed benefit over openVPN, but still that's pretty cool.

Please create a bugreport: https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html