https://redmine.pfsense.org/issues/11600

@madnet I change MTU values to 1500 on my Site to Site VPN as the default value of 1420 was affecting google services (no youtube, no gmail, not maps nothing that had to do with google worked and I also had issues with Apple email servers that did not worked with MTU set to 1420) but as soon as the MTU value was changed to 1500 all worked fine only issue that I see is that the MTU values will revert back to 1420 after sometime by itself inside Pfsense but if I change it again and save it will set it back to 1500 and all work good but it will be good to know if there is a way to hard set the MTU to 1500)

@dennis_s Sure! Opened bug #11618.

@jimp Thanks for that - I must have screenshot the wrong thing. I've actually played around some more, and it turns out that I had a problem with the protocol. I had not realized that I set it up with TCP rather than UDP. For those who might experience this, please note carefully, that for the Firewall | Rules | WANS, make sure the protocol is UDP: [image: 1614733638114-e23c68db-45cc-4517-bc99-a8820426ca19-image.png] This is different to Firewall | Rules | Wireguard, in which the protocol is Any: [image: 1614733711680-d5d7bf63-a23f-48c5-9aed-56ed5087d8c1-image.png]

@tigs this seems to me like the issue I'm currently facing. Unfortunately I haven't found a solution yet. Neither did @xxgbhxx's idea work for me. I suspect in-depth knowledge of the inner-workings of pfSense/FreeBSD/the WireGuard module(?) is required to figure out what's going on. On my installation the DNS resolver would even use the WAN interface when it is not even selected as one of the "Outgoing Network Interfaces", which seems odd to me.

@dma_pf @jimp Interesting... Thx I never assigned an interface to OpenVPN. Is it incorrect ? When would you vs won't you assign it ?

@chudak said in iPhone via WG tunnel - help validate my setup: @dma_pf When I set Allowed IPs and Peer WireGuard Address as suggested in the video to 10.0.0.6/32 I get 100% loss on WG0_XX Gateway seeing in the dashboard. Have you tried this ? I'm seeing the same result. In my case I have been testing this with my android phone. It's the only peer I have set up at the moment. It's using the native Wireguard app. The only time I'm seeing the 100% packet loss on the dashboard is after I get home, shut off wireguard and turn and connect it to my WiFi which is connected to pfSense. I haven't really looked into why it's showing the loss. But I just looked at the System/Gateways log and saw that there were entries showing the packet logs on the tunnel interface. I just noticed that the gateway in pfsense had the Gateway Monitor enabled. I just shut it off to see what happens. I'll let you know.

@chudak, guessed as much thanks for confirming!

@z3us good for you! As for me, I don't plan on going back to OpenVPN because of how slow it is compared to WireGuard, at least for my decent-powered CPU.

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.