@slim0287 that repository is no longer active because the project is now maintained in-house. v0.1.6 is available in 22.01/2.6RC branches. There is a UI dependency that makes v0.1.6 incompatible with older versions of pfSense. I’d recommend giving the release candidates a try, they are quite close to GA.

The easiest solution to prevent the openvpn reloads / restarts is just to disable the Gateway Alarm Actions.

But still unsure why the status > peers endpoint IP is not being displayed correctly, I think it is picking up the previous / old one.

@cmcdonald

Since my outgoing WG peer on FIOS has the same destination IP as my outgoing Wireguard peer on LTE, the route solution above doesn't work. I'm not getting any states on the LTE interface. I was fooled, I think by ICMP redirects which made it seem all gateways were up.

revised-pfsense-crash-dump.txt

@joshhboss said in Pfsense SelfHosted acting as Wireguard VPN Server:

Redirect Host(New addr:

i went here..
System->Advanced > System Tunables tab and changed net.inet.ip.redirect to the value of 0.. and the redirects went away.

Could this cause problems?

@deltaend All great suggestions and I agree with them. Will add this to the list of things to work on.

@hossimo ha glad to hear it's working! Sometimes the simplest mistakes are the hardest to hunt down. I hit that more than I'd like to admit.

@netblues Thanks for the suggestion. As it happens I already had that bit right, but I stupidly overlooked including the 98 subnet as an allowed IP for the WireGuard tunnel - so problem solved! Thanks again.

thanks Chris, now I see where mi mistake is. will try tomorrow.

@tquade What do I do to move this along. I can provide screen captures, logs, etc. This functioned OK prior to 0.1.6.

Ted

@ligistx-0 I test on several hardware platforms, including the 1100. No issues to report in regards to arm platforms.

Can you report your package versions from the WireGuard > Status page ?

WireGuard is a very quiet protocol, meaning that it won't "come alive" unless there is actually traffic to pass down the tunnel.

We are constantly exploring new features and capabilities for sure. Yes, these features are high on the list of things to build. There is some initial work on QR in the public GitHub repository for the WireGuard package. This is a high priority for me once we get 22.01 and 2.6.0 shipped here very soon. Stay tuned.

Hello.

In my case both Pf has public IP, went I setup WG P2P at first I don't have to open ports, WG open the sockets and don't add any value for keepalive.

If I delete all setup and delete WG from both pfsenses, this issue appear, I have to open udp port for wg in one side because start blocking the packets.

My questions is, in a standard setup like this one, do wg open the sockets or we need to open the port in the WAN always?

Or what is the right steps?

To understand more how WG is working, thanks Chris.

@robearded said in Wireguard suddenly refuses to handshake:

After I had to restart my modem (so the WAN went down for some minutes on the pfsense) this problem happened to me again. I can't seem to be able to initiate the handshake whatever I do. I also checked "Disable Gateway Monitoring Action" checkbox for the wireguard gateway, however it's still not working

It turns out this happened because of a change I did on the wireguard server without realizing it will break stuff. I'm not however sure if I did this change before the first occurrence of this problem, from what I remember it is after, but it is definitely possible to be before.
I had some DNAT iptables rules in the PostUp and PostDown config of wireguard to forward some ports to pfsense, so I can use the public IP of the wg server as a public IP for the server running pfsense. I figured out that it would be easier to DNAT all ports (except SSH) and just do the firewalling inside pfsense, so I don't have to log in to the wg server everything I want to forward another port, and I can do it all from pfsense. Well, the problem is, that I didn't realized I also forwarded the port WG was listening on.

@bubbel I see you're using a TAP device, which is L2. WireGuard only operates at L3 so if this protocol relies on L2 ethernet frames, you won't be able to tunnel that through WG without an additional inner tunnel that can pass L2 frames. That is technically possible but not trivial to configure.

@cmcdonald

Thanks for responding. The problem was solved in another thread: https://forum.netgate.com/topic/168357/system-log-tun_wg0-loop-detected?_=1640196156974

@seanbts You can enter a private key to reuse a key. If you only have the public key, you can't reuse it as a private key cannot be derived from a public key.

This actually reminded me that there are some UI bits in 0.1.6 that are not available on 2.5.2/21.05... I should probably re-version 0.1.6 to be 0.2.0 to reflect that change. Hmmm

@luckman212 It's now appearing in the pfSense package manager, at least for 2.6.0-devel.

@bcruze I'm not sure what outbound NAT has to do with redirecting DNS queries. Can you explain it to me please? What should I change to redirect the VPN interface's DNS queries through the VPN gateway? Thank you

@dma_pf said in DNS Not Working With Phone As Peer:

@bingo600 @GenericStudent

Thanks to both of you for all of your help. I spent several hours this morning working on this issue and finally got it resolved. It was a combination of 3 different issues that resolved it.

Before I get to the solution I want to clarify that the setup I have is using a dedicated assigned interface with a gateway assigned to it for the remote access tunnel. Like this:

496c0552-b686-48e8-a473-ed95c64c0ead-image.png

181b3442-cdf2-4a90-b875-77cbdcbb8e3a-image.png

I found that first issue I had was the NAT Rule I posted above was not needed:
a5d6906c-2253-4acc-9819-437e134e3175-image.png

The second issue I had was the NAT Rule I posted above was also not needed:
d47715d8-e06f-4300-bef7-254f91def188-image.png
The reason it is not needed is because the 10.0.9.0 network is already know to pfsense through the assignment of that network to the wireguard interface and gateway. If there was no local pfsense interface assigned to that wireguard tunnel then the NAT rule would have been required.

The third issue was exactly what @bingo600 pointed out. I did need to create a rule to allow the 10.0.9.0 network to assess the DNS resolver like this:

62e2c01a-58db-42f3-b0a0-7414fceaa19d-image.png

I am very perplexed as to why that allow rule had to be created. The setting I posted above, d707a8d1-46f5-481e-8b49-caf358dfdbb1-image.png
should have allowed the DNS queries as the 10.0.9.0 network is a local pfsense network. The pfsense cleary indicates that by selecting "All" there should not need an allow rule. Per the pfsense documentation:

ab33f227-2fc2-4c90-a98e-9f56e85c129e-image.png

5ac51888-b59e-4150-8021-6bd37b34c152-image.png

I'm obviously misunderstanding something about why that access rule is required. If you can help me understand that better I'd greatly appreciate it.

Thank you guys for all of your help. I've been trying to figure this issue out for several weeks and your input got me pointed in the right direction to get it resolved. 😀

Thank you so much for this post. I was experiencing exactly the same issue and you helped to fix it!

@cmcdonald said in WireGuard Road Warrior setup:

This isn't necessary for assigned tunnel interfaces as pfSense already appends these subnets to the Unbound config, but for unassigned tunnel interfaces this additional "step" is required. It should be automatic.

@hulleyrob said in WireGuard Road Warrior setup:

yes it was

I had the exact same thing happen to me. I have a Wireguard tunnel installed as an interface for my road warrior set up. I could not get it to resolve until I created in ACL for Unbound. This drove me nuts for days, the details are all in this thread https://forum.netgate.com/topic/165818/dns-not-working-with-phone-as-peer?_=1637700225107

It seems to me that there is an issue/bug where the Wireguard tunnel is not recognized by Unbound and therefore Unbound does not see the interface as an internal network and therefore requires the ACL.

@cmcdonald Thanks for the info.

I took the plunge and updated this "lab" 2100 to 22.01-devel from 21.09-RC and, sure enough, WG was also updated to 0.1.5_3.

I feel you because I am dealing with a similar situation with pf wireguard. PIA is my VPN provider. Their linux app on ubuntu VM runs fine. PIA also has a tool to generate wireguard conf file to work with wg-quick on ubuntu. No problem.

I generate the details in my ubuntu wireguard conf and enter the info in pf gui. Mapping is private key for tunnel. Endpoint and public key for peer. Address for opt interface and routing.

The pf wireguard peer does not always handshake. The first time pf wireguard connected to PIA it was perfect. The connection dropped after 2 weeks. Now the connection has long ping times and very slow.

Is there a way to automate mapping linux wireguard conf to pf wireguard tunnel and peer conf?

@kodols Sure.

You would create a 'site-to-site' style tunnel between pfSense and Mullvad, and then a second tunnel using the road warrior model. Then it just becomes a matter of setting up policy routing and firewall rules to accomplish the desired outcome.

@xiki It isn't clear if and how this is related to pfSense.

@cmcdonald said in Stale WG session ?:

@chudak Thanks for the feedback! Much appreciated.

I don't see a stale state as often as I used to, but it's not completely fixed AFAICS

I will be paying more attention and see if other users provide more data points.

@Lakitu78 You saw the same problem, can you see if it's better/same/worse on the latest release?

@cmcdonald said in WireGuard Widget:

@ciscox Noted! Thanks. That is particular useful for widgets that can be added multiple times to the dashboard, so it might also be worth allow multiple widgets with each filterable by specific tunnels.

Hi,
Exactly what I was thinking.:) 👍 😊

@bassopt Take another peak now, updated package should be available.

https://files01.netgate.com/pfSense_v2_5_2_amd64-pfSense_v2_5_2/All/pfSense-pkg-WireGuard-0.1.5_3.txz

@dma_pf Good call! I'll try it. Thank you so much for your help.

@securvark I had the same issue. This worked for me as well. Thanks for posting.

@mooncaptain You only need the rules on one interface for each FW. Sounds like you are good to go.