I’m new to the IPFire community and currently experimenting with IPFire on Raspberry Pi 3 hardware. I have two Raspberry Pi 3 systems running IPFire. My goal is to configure one as an OpenVPN server and the other as an OpenVPN client.
In addition, I want all traffic from the GREEN network to be routed through the OpenVPN TUN interface. The web interface appears quite limited for this use case, and I cannot find a clean way to enforce this routing without manual command-line modifications.
What is the recommended approach to achieve this on IPFire? Are there supported methods (firewall rules, policy routing, or specific OpenVPN options) to properly route GREEN traffic through the tunnel?
Any guidance or references to official documentation would be greatly appreciated.
The use of a Raspberry Pi is not the main point. In the case of the Raspberry Pi 3, it is only used as a practical example. Please do not focus on the hardware, as the discussion is strictly about the system itself.
The core topic is IPFire-to-IPFire communication (client-to-server) using OpenVPN. I am not looking for an alternative solution. Rather, I would like to present a technical issue and understand whether there is a solution, or whether this use case does not fit within the current direction of the IPFire project. That would be unfortunate, as OpenVPN remains a widely used and mature technology.
In addition, my network constraints may not be immediately apparent. In my case, using OpenVPN over a 4G connection is problematic because mobile operators rely on CGNAT. Requesting a fixed public IP address without CGNAT would not address the underlying technical challenge, but rather bypass it.
Best regards.
If you are trying to set up a net-to-net tunnel then one end of the tunnel must have a publicly accessible IP.
The end with cgnat then connects to the end with the public ip as that end is publicly accessible. Then the tunnel is created between the two ends and both systems can then communicate with each other.
If both ends of the tunnel have cgnat then you will not be able to make a connection as most cgnat providers do not allow any port forwarding from the public IP they use to the private IP they provide to your system.
Having a DDNS just allows you to have a domain name in place of the public IP but you have to have a public IP to be able to use DDNS.
The principle of CGNAT is the sharing of a single IP address among multiple customers. The issue lies in the ports. Indeed, customers share dynamic pools of ports for the same IP address. You just need to check on a site between a time t0 and a time t1, the port being used (as detected) will have changed at least once. Therefore, DDNS is not sufficient, because it only updates the IP address, whereas the real problem is elsewhere. The port pools change as well as the IP.
i have in mind that redirect-gateway does also work for N2N connections, to test tis you would also need to use the command-line but it might be cheaper then setting up the whole routing by yourself.