@yodaphone I'd like to know this answer too. I have been having trouble getting wiregaurd to pass any traffic for a for a single remote peer. Unfortunately, this nat rule did not resolve the problem.

@slugger Hmm, it is just weird because I didn't seem to need that rule when using OpenVPN. Regardless, I have added the rule to LAN and it seems to be routing my traffic over WG.

Filed a bug here.

@jimp Perfect! Thanks for the reply. I just wanted to share this and I am pretty sure all will be fixed with 2.5.1 when it will come out.
Thanks again!

@gabacho4 @heatmiser thanks all for the help in troubleshooting this, appreciate you checking so that I knew this issue wasn't unique to my setup. Mullvad is an awesome provider, just hoping they fix this quirk soon. Cheers.

@griffo thank you for the reply:

server side:

interface: wg0 public key: xw+fQgc**************Hi7b2WRNVuGpnc= private key: (hidden) listening port: 51820 peer: OuQlCN2OTy********************epbr8kGIJhA= allowed ips: 192.168.168.0/24 peer: fBgCDQejJDET***********************4/YD4= allowed ips: 192.168.0.0/24

client side:

[Interface] PrivateKey = qJec0SvTJ4**********************Um3bQ5W4= Address = 192.168.168.2/32 DNS = 1.1.1.1 [Peer] PublicKey = xw+fQgcFPC***********************uGpnc= AllowedIPs = 192.168.0.0/24 Endpoint = aaaaaaaaaaa.ddns.net:51820 PersistentKeepalive = 20

@matosc

i had the same thing while messing with Wireguard the first week after the 21.02 release. i found i had deleted the keys required for the connection so the connection, never connected.

not sure if there is a timeout period on boot up for this to connect or not!

hopefully someone more knowledgeable can fill us in

@dma_pf Thanks again for your reply!

Unfortunately I think you might have confused Network Interfaces and Outgoing Network Interfaces! 😯

I didn't show it in the video, because it shouldn't make a difference, but I do have LAN and Localhost selected as Network Interfaces (for responding to queries from clients). If I hadn't, I'd receive the error message you posted a screenshot of.

However, I only have the WireGuard interfaces selected as Outgoing Network Interfaces (that the DNS Resolver will should use to send queries to authoritative servers and receive their replies). Yet unbound will still use the WAN interface, as if it were selected for the latter setting, which it definitely is not. I have double triple quadruple checked.

I've even reinstalled pfSense from scratch, on a new SSD. I configured it without restoring settings from a backup. I only set up what was necessary to get me connected to the internet and the WireGuard interfaces. This didn't fix the issue either. At this point I genuinely wonder if I have somewhat of a "one in a million" configuration/environment that triggers this issue or if people who are affected by this issue simply don't know (or care) that they are. 😕

@hypnosis4u2nv said in WireGuard VPN providers that support pfsense:

I have Torguard up and running.

And i can confirm that it works with their dedicated (streaming) IP's.

@jimp I used the button to generate one.

@dma_pf said in WG not routing or sending traffic:

@xxgbhxx Thanks for the update! I was wondering how things worked out for you and I'm really glad it's all good now.

Here's a suggestion based on our conversation.

You might want to create an interface group to another server or 2 of IVPN's. It's really to do. Just duplicate all that you've done to create the interface you have already made to IVPN (interface, routing, NAT, firewall rules) but use a different IVPN server.

When it's all done bind the interfaces together in System/Routing/Gateway Groups then use that interface group in your rules to route your traffic out the interface group. This will keep your internet up if one of the servers you are connected to goes down for any reason.

I'd use a servers from different data center providers for each connection (datapacket, M247) to provide another level of fail safe protection. Maybe one across the channel? IVPN gives you up to 7 simultaneous connections.

(Bonus Tip: Ping to different servers and see where your fastest responses come from. In my case I get quicker responses, and consistently faster speed tests, from 2 servers that are about 200 miles from me, as opposed to one only 60 miles away. Don't assume that the closest servers are going provide the fastest services. It all depends on the routing out on the net).

That's exactly what I did last week. ;)

I also set up and configured Squid and Snort.

This weekend I do DNSBL in pfBlockerNG then I'm done for a while :)

Many thanks for the tip though :)

G

@jimp said in wg show segmentation fault:

If you want to run one instance on multiple ports you can port forward from one port to the other,

this works perfectly. thanks again!

I solved this by adding an additional interface directive in the DNS Resolver advanced options box. I confirmed that the running unbound config didn't include the wg interfaces and that's why it wasn't responding.

There's no "wireguard" in the Network Interfaces box of the DNS Resolver screen unless you create a Firewall interface based on the wg interface. I don't use ALL because I do not want some of my interfaces to have the option of using pfsense's unbound. Interestingly enough, the proper access-control directives did exist in the config already.

I added these lines and created a firewall rule allowing the wg subnet to access DNS on this IP.

server: interface: 172.27.80.1 interface: 172.27.80.1@853

@80scyborgninja said in WG - Full tunnel problematic:

Definitely very strange.

Definitely a mystery here 👻 , but I am glad you got it working. And thanks for the feedback.

@bartkowski Yep but as I said, they seem to share a single keypair and IP across all your devices, so you can only establish one tunnel.

My problems are gone now with the change to OpenVPN. Disabled WireGuard and all problems are gone for now. No crashes anymore....

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

@rcmcdonald91 OK great.

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.