Messages

I would like to say thank you for the new interface: I used a fortigate for a couple of years and I find the new interface quiet similar. Not easy to get along with it (I changed the way to name the rules and added tags) but later it is more clear (the order of the rules is much more clear).

The only thing I would change is about the "automatically generated rules" list that is visible only activating the "inspect" feature...is not possible to add it to the top of the dropdown menu?

I have an issue somewhere with a multiwan configuration where I put 3 wireguards to higher priority than the WAN interface.
At a randomic moment (sometime after 1 day sometime after a week) the wireguard connections are note renewed one after another (also in this case with a random delay of days). The VPN log tells me that the handshake is not renewd.

The only way I found to restore the handshake is:
- forcefully change the WAN pubblic address exposed to the opnsense wan interface (restart the modem);
- switch off, wait 30 secs and than switch on the opnsense (just the restart is not effective).

My question is what data/routing/other "resist" the reboot but not the stich off/on. Otherwise everything seems to be properly working and I am not able to find a solution (I have crowdsec and intrusion detection but no alerts are communicated).

I know this is a very weird question, but it would be really helpfull.
Thanks.

Did you try to traceroute an external ip (i.e 1.1.1.1 or 8.8.8.8) in order to verify the routing? It helped me a lot with troubleshouting, also to keep the live view of the firewall open while doing these tests.

I have a setup that is based on road warrior but it is different: i do not use a specific firewall rule to route designated clients to wireguard, but I activate "Allow default gateway switching" and " Upstream Gateway" in each wireguard gateway.
This way each wireguard gateway should be equivalent to a WAN and I can route the traffic (both of the clients and of the firewall -i.e. unbound dns) just setting the priority level.
Using the gateway dpinger, in case a gateway is marked as down, automatically you switch to the next one.

I hope this better clarify my setup.

My question come also because here https://docs.opnsense.org/manual/how-tos/wireguard-client.html it is reported:

Code Select Expand

Step 4(a) - Assign an interface to WireGuard (recommended)�

Hint

This step is not strictly necessary in any circumstances for a road warrior setup. However, it is useful to implement, for several reasons:

First, it generates an alias for the tunnel subnet(s) that can be used in firewall rules. Otherwise you will need to define your own alias or at least manually specify the subnet(s)

Second, it automatically adds an IPv4 outbound NAT rule, which will allow the tunnel to access IPv4 IPs outside of the local network (if that is desired), without needing to manually add a rule

Finally, it allows separation of the firewall rules of each WireGuard instance (each wgX device). Otherwise they all need to be configured on the default WireGuard group that OPNsense creates. This is more an organisational aesthetic, rather than an issue of substance
From this, it seems that NAT outbound rule is created automatically.

The guide about road warrior wireguard connection explain how to set the outbound nat rule, my question is: if I route the connections through the wireguard gateway giving to it an higher priority than wan and setting it as "possible default gateway", I still need the nat outbound rule?

NAT oubound rule is by default enabled only on wan gateway?

What ip are you pinging?
Did you try to ping from a client and from the opnsense gui?
Did try a traceroute (tracert on windows)?

Tried to go again through the opnsense docs? Sometime I also totally forget a step in between and only looking again to the docs I remember it.

Personally I found two possible ways:

- first is going in the unbound settings, show advanced settings and select the outgoing interface you want (be aware that if that interface is down, no dns queries will leave the firewall). It does not accept gateways group, so you can only chose single or multiple gateway, but you can't define the order of use;
- second to route everything through the wireguard connections like a multi-wan setup.

To summarize: clients traffic go through the wireguards, but the traffic originated by the opnsense itself does not, correct?

In order to route everything through the wireguard VPN connections (I have 2-3 used one as backup of the previous one), I did:

partially follow the wireguard road warrior:

- flagged "Gateway switching" in System-Settings-General;
- flagged "Upstream Gateway" in System-Gateway-Configuration-each of the wireguard gateways;
- flagged  "Failover States" & "Failback States" in each wireguard gateway;
- given an higher priority (lower number) to the wireguard gateways (ie. First VPNgw =1 , Second VPNgw =3, Third VPNgw =5, WAN =7);
- the gateway monitoring brings online/offline each gateway in case something is not working;

-created a static route + firewall to each IP entrypoint through WAN (in order to avoid VPN connections going one through the other)

This way the wireguards are basically used as a multi-wan setup and I am finally able to route everything (also firewall originated traffic) through the VPNs.

The questions is: this configuration has any security issue or any other flaw?

Everything works properly, aside that after a randomic amount of time the handshakes are not renewed but the IP entrypoints are still reachable: I am trying to understand where is the cause of this behaviour.

Thank you.

Is it recommended to perform a clean installation and restore the latest config backup when installing major updates like this?
thank you

I want to totally disable the keepalive signal to peers of wireguard connections, is it possible?

If I put nothing in the box, it sends signals. If I put 0, it is not allowed. It seems the only thing I can do is to use the maximum value allowed of 65535 secs.

Thanks

Hi,

the latest version of this story (that lasted 2 years for me) is that PROTON VPN implemented silently a DDOS protection and has a very low threshold about the ping signals(any ping signal).
Once the protection kickin, it reject your request of handhake (in the beginning I thought it was some kind of block from my side)

Therefore:
- I passed from 3 to 2 vpn connections in parallel;
- set the gateway ping signal to 60 seconds for the first vpn;
- removed the gateway ping for the second one;
- removed the keepalive signal (pay attention that "0" i sont accepted, you have to leave the box empty) for both.

In this condition I solved the problem. The second vpn can become stale, but when it is used it immediately return online.
Do not contact them to ask what is the threshold of the ping signal beccause they refuse to share such information.

Solved -> https://forum.opnsense.org/index.php?topic=45457.0

Looking in the log of unbound, it was notified an error about a specific hostname....I found I entered that with a " " (space) instead to use an underscore ....

Activating  "Register DHCP Static Mappings", now everything seems to work.

Thank you Cedrik for your time.

uh...complicated, I should take my time to carefully read through it.

On unbound i tried to flag the "Register DHCP Static Mappings" as it seems to be what I need, but once I restart the opnsense, unbound does not start because of an error.

If I correctly understand, it could be this https://github.com/opnsense/core/issues/7237