Messages

This should really be cleaned up and added as one of the official VPN walkthroughs in the manual.

Not sure what "clean ups" you had in mind, but a PR has now been submitted for this tutorial to be added as a how-to in the OPNsense documentation: https://github.com/opnsense/docs/pull/317

Oh sorry I just meant added to the official documentation page and not that there was anything wrong with the content. I appreciated the info very much and helped to get my Wireguard working.

So it would appear that if the port forward is listening on the LAN, it cannot redirect to and an address on the WAN.  I should add that I have recently switched to  Opnsense from Pfsense.  I had the same issue on Pfsense but did not have to resolve it until now.

I believe this should be a custom outbound NAT rule instead?

This is how I would have redirected any DNS requests not going to my Firewall, but instead redirect those requests to Cloudflare's DNS (1.1.1.1).

Oh that's a really good idea for something like DNS on a "guest" network. I'd been blocking outbound DNS but this would force all devices to use local DNS without breaking ones which may not be correctly configured.

I'm not sure how much of what I was having trouble with was due to actual "wireguard issues" vs the manual gateway configuration process but either way this was finally the tutorial that I needed to really understand what was going on.


This should really be cleaned up and added as one of the official VPN walkthroughs in the manual.

You can use the advanced settings box for the moment:

Code Select Expand

<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
Your static key here
-----END OpenVPN Static key V1-----
</tls-crypt>

Works for me.

I've been using this method as well but the big warning about "this feature being removed in the future" is kind of scary. Would be nice if there was just a supported field for this information in the UI.

Well, I managed to figure it out after making some test interface groups and rules. It apparently uses alphabetical order by group name.


In my previous example therefore the packets would be blocked as "Group_LAB" comes before "Group_LAN" in alphabetical ordering. I think though that I probably should avoid this where possible since it just doesn't feel like it's really a best practice.

I'm familiar with the general rules processing order as discussed in the manual: Auto Generated -> Floating -> Groups -> Interfaces. I'm just not sure how this holds if an interface is added to more than one group.

Code Select Expand

Group_LAN (containing interface: LAN, LAB)
Allow ALL

Group_LAB (containing interface: LAN, LAB)
Block ALL

What exactly would happen here? Does it execute in alphabetical order by group name or something? Is it just bad policy to put an interface into more than one group?