OpenVPN: Incompatible with the official OpenVPN P2P mode configuration

[laozhoubuluo]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

OpenVPN peer-to-peer tunnels in legacy mode can support traffic from any address instead of a specific peer-to-peer address. This is used for dynamic routing-based networking or scenarios where NAT is not allowed. This is achieved using OpenVPN's native p2p mode (mode p2p).

In the new version of the OPNsense's OpenVPN configuration interface, server mode (mode server) is hard-coded in the p2p scenario of configuring the /30 network segment. The server mode cannot support this scenario because it involves multiple clients. This causes traffic from non-specified peer-to-peer addresses to be dropped.

The current scenario at OPNsense is different from the mainstream implementation and OpenVPN legacy caused the problem, so this scenario needs to be modified. Compatible with the official OpenVPN mode and the original OpenVPN legacy configuration.

Ref: #7228

To Reproduce

Steps to reproduce the behavior:

1. Configure two OPNsense devices, connect the WAN ports, and assign two different address segments to the LAN ports to simulate two areas that need dynamic routing interconnection (it should be noted that there are multiple areas in the real environment, and it is not possible to communicate with each other by hard-coding the address segments at both ends).
2. Use the new OpenVPN configuration page of OPNsense to set up an OpenVPN server. The server IPv4 is set to /30 address, and the topology is selected as P2P mode.
3. Use the new OpenVPN configuration page of OPNsense on another OPNsense to set up an OpenVPN client connected to the server.
4. Establish a neighbor relationship between the two OPNsense interfaces on a dynamic routing protocol (such as BGP).
5. After the neighbor relationship is established, try to access the services under the LAN ports of the two devices.

Expected behavior

After the neighbor relationship is established, the services under the LAN ports of the two devices can be accessed mutually.

This function can be worked if the new OpenVPN configuration page in the operation steps is replaced with the old version page.

Describe alternatives you considered

#8604

Screenshots

Relevant log files

MULTI: bad source address from client [X.X.X.X], packet dropped

Additional context

Environment

OPNsense 25.1.5_5-amd64
FreeBSD 14.2-RELEASE-p2
OpenSSL 3.0.16

[AdSchellevis]

missing client specific overwrite? (https://openvpn.net/faq/multi-bad-source-address-from-client-packet-dropped-or-get-inst-by-virt-failed/)

[cweakland]

I am seeing the same issue when moving from legacy to the new "instances":

https://forum.opnsense.org/index.php?topic=47309.0

When trying to send routed traffic over the tunnel I get this in my VPN log:

GET INST BY VIRT: 192.168.1.1 [failed]

[cweakland]

I was able to fix my issue by using AdSchellevis suggestion. I created a client specific override and placed the foreign network (In my case 192.168.1.0/24) in "Remote Network" field.

I did not realize the difference between the OpenVPN server "Remote Netwokrs" and the "Remote networks" for the Client Specific Overrides. In the overrides the "remote networks" are configured via iroute clauses in OpenVPN and inform the server to send these networks to this specific client.

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.