@t_k Let me see if I understand this.
You had 0.0.0.0/0 included in the list of "IPv4 Remote networks(s)" on the CLIENT side of a point to point OpenVPN link, running PFSense ?
If so, that is to be expected and your original configuration was wrong - 0.0.0.0/0 is the default route in a routing table, and setting it in the OpenVPN settings will cause the default route set in System->Routing to be overridden, but not reliably. There can only be one default route.
Something may have changed in 2.7.0 to make it work properly now.
We have a site to site OpenVPN link with PFSense at both ends, originally set up on 2.6.0 but now running 2.7.0, and unlike you I DO want ALL user traffic to go across the VPN and find its way out to the internet from there, (after additional filtering/inspection/logging at the main office site) and not go directly to the internet.
I actually had problems with 2.6.0 getting this to work reliably. The issue was that if you set the default route to the OpenVPN client interface only in Settings->Routing (setting Default Gateway IPv4 to the VPN tunnel interface) it does not seem to get reapplied if the OpenVPN connection drops and reconnects.
On the other hand if you set 0.0.0.0/0 in "IPv4 Remote networks(s)" in the OpenVPN client config, when the OpenVPN connection disconnected it would remove (clobber) the default route and not replace it, leaving it with no default route even after the OpenVPN connection came back up.
The workaround I came up with was to set the default route to the VPN interface on the client side in Settings->Routing AND push the default route from the OpenVPN server side by including 0.0.0.0/0 in "IPv4 Local network(s)" on the SERVER side, which pushes the route to the client side. (In fact I have all the local routes pushed from the server as well rather than defining them at the client side)
This is a workaround for what is probably a bug but it does seem to work in both 2.6.0 and 2.7.0 - from what you say behaviour when specifying a default route on the client side may have changed so that it works more as expected so I might not need to use my workaround of explicitly pushing a default route now.