OpenVPN: Use OpenVPN's official p2p mode, consistent with standard OpenVPN behavior

[laozhoubuluo]

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.

This PR restores OpenVPN's native p2p mode in peer-to-peer mode and removes client parameters that are invalid for real peer-to-peer requirements, thereby resolving this issue.

Ref: #7228

[AdSchellevis]

this will undo 66fd0e4 and reintroduce issues reported earlier (for both net30 as p2p).

[laozhoubuluo]

this will undo 66fd0e4 and reintroduce issues reported earlier (for both net30 as p2p).

Can you describe the problem more precisely? I don't fully understand your statement, so I'll try to answer it.

1. The premise of all modifications is (string)$node->topology == 'p2p', so the scenario using net30 will not be affected in theory.
2. The reason why OpenVPN p2p mode could not be activated in the early stage was that the three parameters client-config-dir client-connect client-disconnect were introduced into the p2p mode, which are not needed and not supported by the p2p mode. The references to these three parameters have been removed in this PR.

[AdSchellevis]

@laozhoubuluo my mistake, I tightened the scope earlier for #7228 in 833765f, I'm just doubting changing this will be necessary as this will impact people with a p2p combined with a /30 network and the actions are literally the same as specified in https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/.

If omitting the three additional parameters solves your issue, I don't mind having a look in omitting these, just let me know if that's the case.

[laozhoubuluo]

@laozhoubuluo my mistake, I tightened the scope earlier for #7228 in 833765f, I'm just doubting changing this will be necessary as this will impact people with a p2p combined with a /30 network and the actions are literally the same as specified in https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/.

If omitting the three additional parameters solves your issue, I don't mind having a look in omitting these, just let me know if that's the case.

We have multiple networks in multiple points, and the networks are interconnected using OpenVPN or WireGuard. Due to the large number of points, the points change over time, and the interconnection requirements between each node vary, it is impossible to achieve full-mesh interconnection between all nodes. Considering the above problems, the current architecture uses a dynamic routing protocol to achieve interconnection between points (currently use BGP, and a private ASN number is assigned to each points. The points administrator manages the routing within the points).

The P2P VPN interface address is only used for interconnection between two routers. The source address and destination address of the actual services are both addresses broadcast by the dynamic routing protocol, and there are situations where the source address and the destination are forwarded through multiple routers/firewalls.

Both standard OpenVPN and WireGuard can meet this requirement, so theoretically there should be no technical problems in implementing the same scenario on OPNsense.

The current scenario at OPNsense is different from the mainstream implementation and OpenVPN legacy, so I personally doubt whether there are many users who rely on this scenario. But if OPNsense deems it necessary, splitting into p2p and ovpn-p2p is also a viable option.

[AdSchellevis]

I'm not sure what the question is, but if the p2p serves a larger net (<=29), the address calculation wouldn't be used in our case. Best go back to the drawing board and start with a ticket explaining what we are trying to fix and which circumstances.

[laozhoubuluo]

I'm not sure what the question is, but if the p2p serves a larger net (<=29), the address calculation wouldn't be used in our case. Best go back to the drawing board and start with a ticket explaining what we are trying to fix and which circumstances.

I'm create a new ticket #8622 for details.