After some reflection, now I believe what you’re experiencing may not be split tunneling but rather a NAT loopback, also known as hairpinning. Let’s simplify the scenario by assuming your server is a web server. When the client establishes the VPN tunnel using the “redirect-gateway def1” directive, all its traffic is routed through the tunnel, including the traffic from the web browser. Upon reaching the OpenVPN server, where is this traffic directed? To the web server’s public IP address as OpenVPN see that in the destination.
As a result, the traffic is sent back to IPFire, which recognizes the destination as the web server based on the IPFire public IP and web port numbers. To ensure that the response from the web server goes back through the same interface (THIS IS THE KEY), IPFire (or OpenVPN) before delivering the packets to the web server performs a source NAT. It changes the source IP in the packets back to the client’s public IP, rather than using the OpenVPN-assigned private IP. This is known as NAT hairpinning or loopback.
For a more detailed explanation of this process, you can refer to this excellent thread on the topic.