@quasides
just a future warning, as we can see we basically define a static routing table on wireguard level.
that also means any change in topology has to be manually updated on each and every client.

automated updated of routing tables like with OSFP dont work, WG has still no implementation for that and while OSFP could change routers (pfsense) it would be overwritten or at least meaningless as WG is gonna override it and or at least use it internally based on manual config

edit: i do understand the confusion tough. not only is WG concept with like no pushiung config a very wierd one, but the naming of the parameter allowed IP is beyond stupid.
just translate it to something sane like "remote network" which what it basically means

@rcmcdonald91 it's a fast-paced world... 🏃

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

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

@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

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

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