The 'trusted VPN' client cannot be given full autonomy unless you have reviewed the source code yourself. However, a VPN client with a kill switch is a must if you intend to not use a firewall. This kill switch should either upon disconnect, disable the chosen networking interfaces (those which can access the Internet), or change/enforce firewall policies, so that when the VPN client is active no outbound traffic is allowed, except via their preapproved IP addresses (those which the VPN provider controls), this will then prevent packet and 'true' IP address leakage upon disconnect.
While the VPN client's kill switch via firewall policies will work differently on Windows than on Linux, which uses
iptable. Instead, on Windows, often the VPN client will enforce the policies when active via their own firewall. If this occurs, instead of enforcing these firewall policies via Windows Firewall, it causes packet and 'true' IP address leakage if the VPN client is to ever crash.
I can only foresee a firewall and VPN being used together to mitigate packet leakage, do not interpret this as 'I do not need a firewall' as other applications may require one. The above point about the VPN client crashing and the kill switch failing is the main reason I use Linux in this regard. But, this is not required. Instead, you may enforce the firewall policies manually within Windows Firewall. First, create a virtual interface, you will share Internet access to this interface and connect your VPN here.
Second, Setup firewall policies for the virtual interface to ensure only the VPN's induction nodes are allowed, in the event of no VPN connection, the firewall will not allow any outbound traffic. Third, enforce firewall policies denying all inbound and outbound traffic except the virtual interface, for the interface with Internet access.
See, Creating a virtual NIC that connects to the same network as physical NIC for the technical configuration.