Using a Private Endpoint will add an entry point to the service into your VNET, using a private IP address in the subnet you allocate the endpoint to. However, by default, the Azure File Share is still accessible via its public IP address. To prevent access from the internet to the file share's public address you have to add storage firewall/network security rule settings to the share, which limits the networks from which access is permitted.
There appears to be a problem here when used in combination with a P2S VPN gateway. After restricting access from all networks (including the internet) you then have to explicitly allow access to the storage resource from subnets within your VNET or from listed public IP addresses.
P2S VPN clients are assigned addresses within a leasepool subnet range defined when you create the virtual network gateway. This subnet does not have a subnet ID - it is separate to VNET subnets and cannot overlap. So it is not possible to authorise access to the storage file from the VPN client range subnet.
Additionally, it will not be possible to authorise access from the client leasepool range by adding it to authorised IPs, if you are using a private IP range as only public IP addresses (or ranges) are allowed.
So it appears that whilst you can setup a Private Endpoint to route connections via Microsoft's fabric to a Storage File service from your VNET without traversing external routes, you cannot then disable access via its public IP without also breaking access from P2S connected clients. Does anyone know of a way to get round this?