@dem would be a good option like Ovpn does with the parameter mtu-test, regards!!!

SOLVED. Had to remove an IPSec Tunnel to make this work

@jimp Thanks!

I finally got it working. I wanted a road warrior config between my home pfSense and work. It took me awhile to realize that, while you don't need to define an interface on the work (server) side, you do on the home (client) side plus the usual firewall rule and outbound NAT rule to direct the traffic out the wireguard interface.

@periko my ISP using several routers behind my firewall. So all sites are dynamic, only my central is static.

Thanks for the info guys. I didn't realize how different WG is compared to the more traditional vpn.

No, that is not possible.

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:

e23c68db-45cc-4517-bc99-a8820426ca19-image.png

This is different to Firewall | Rules | Wireguard, in which the protocol is Any:

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 workingScreen Shot 2021-02-27 at 7.08.01 AM.png