Messages

It's not a bug, it's a known issue.

Does this mean it will get fixed in the future?

Is there a workaround?

It is the same in the Interfaces -> Diagnostics tool, I can ping the machine inside the VPN from WAN, but not from LAN.

I went through the easy and straightforward documentation for setting up a Site-to-Site OpenVPN connection a dozen times now, and I understand every step. But I don't understand why the connections coming from LAN aren't routed through the VPN (or at least why there is no response).

I have an OpenVPN server and two OPNsense boxes, which should work as site-to-site clients in this context. The first box works without issues, it holds a stable VPN connection to the server and routes the LAN clients connections to the VPN.

But the second box doesn't, which now left me out of ideas. It has exactly the same configurations of Firewall rules, VPN client (other VPN account though), interfaces... The VPN connection stands and I can ping machines in the VPN from the OPNsense box, but not from its LAN clients. The firewall log shows the ICMP packets from the LAN client to the pinged machine in the VPN as green under the "allow all from LAN" rule. Yet the pong does not arrive at the LAN client.

What could be the issue here?

(I actually remember having had this issue with the first box too, when I set it up. But I didn't document it, which I now regret.)

Since nobody answers I guess the question is
a) stupid
b) easy to find in the documentation
c) too hard to answer

Please point me to where I can find information regarding this topic. I think I read every piece of information about this problem for pfSense and OPNsense, but maybe I am stupid myself.

Though it is still tagged as experimental, and there only is a userland implementation for OPNsense at the moment, it is completely stable for me and everybody I know who uses WireGuard. I have not yet brought it to its performance limits though.

I get the idea to NAT the VPN port to localhost, where the OpenVPN server is bound to. But what to do if I have a OpenVPN client on this side?

I want to ideally have a VPN connection on both WANs of the gateway group, two VPN connections parallel would be ok too. But at the moment I would be happy to get MultiWAN to work with even VPN only on the default gateway...

I still did not get MultiWAN Failover and VPN to work together (both works for itself though).

Do I need a special firewall rule or something to at least have the VPN work for the default (=non failover) connection? The moment I assign the default outbound firewall rule to the gateway group the VPN packets seem to get dropped somewhere.

Thank you for your response.

I already suspected OpenVPN wouldn't support this. For now I would be happy to get the VPN connection to work with the Gateway Group's main WAN, even if it wouldn't work on the failover connection. So that the failover works in general, even if it doesn't work with the VPN, but that the VPN at least works for the main WAN.

I have two WAN connections, of which the second one (only LTE) should work as a failover if the first one fails.
I also have a client-side VPN connection, which should be always active.

Both of these work flawlessly individually, but not together: Once I point the default LAN rule to the Gateway Group, no packets get routed over the VPN connection anymore.

I am not sure about the theoretical foundations here; is it possible with OpenVPN (SSL) to jump between the gateways without reestablishing the connection (is this roaming, which wireguard is said to support?)?

If this is possible, what is there to do to run the VPN connection over the gateway group?

I have the same error on a freshly installed 20.1, and still after upgrading it to 20.1.7 (vanilla, no config import).

I get a syslog message as OP does for nearly every action I do in the web gui, whenever I try to watch any logs or try to use the search.
A new admin user doesn't solve the problem, even if the user is logged into the web gui syslog still shows a "authentication failed for api key root".

Any idea?

Edit: Just made a fresh install of 19.7 where this error doesn't show. Upgraded to 20.1 and there it is again.

Edit2: It seems to work sometimes; I didn't change anything but sometimes it works, sometimes it doesn't. Haven't observed a pattern yet.