Strange behavior since 2.7 upgrade, is this expected?

[t_k]

What I was seeing

After upgrading to 2.7, clients are randomly routed out the other side of a site-to-site OpenVPN link instead of the default WAN. It almost seems the WAN and the S2S link are being balanced between, but I have no such configuration (and never have).

After a restart, all clients correctly route out of the WAN for some seconds. After a few minutes, some clients start routing through the other side of the S2S link. Then they go back to WAN after some more time.

How I "fixed" it

I tried various steps to find/fix the problem. The one that seemed to ultimately do it was this:
The S2S VPN configuration (OpenVPN, in case that matters) had manual routes defined. For the "IPv4 Remote network(s)" field, there was an entry for 0.0.0.0/0 in addition to the private networks on the other side. This was suspect, so I removed it and things appear to be working correctly again.

The question here

What is surprising is that this worked as expected in 2.x versions before this. Is this new behavior expected? Maybe it was always the case that the old config was wrong, but this version is the first to have trouble with it. Even if that's true the back & forth swapping of the routes was really suspicious of some problem.

[DBMandrake]

@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.