I am guessing you have something like this:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: review-external
spec:
  hosts:
  - "*.example.com"
  gateways:
  - mygateway
  http:
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2
      weight: 25

In that case you can use the gateways list in the VirtualService object for that.

For Docs:

When this field is omitted, the default gateway (mesh) will be used, which would apply the rule to all sidecars in the mesh. If a list of gateway names is provided, the rules will apply only to the gateways. To apply the rules to both gateways and sidecars, specify mesh as one of the gateway names.

Source: https://istio.io/latest/zh/docs/reference/config/networking/virtual-service/#VirtualService

So you have two options here. You can either mention mesh as one of the gateways:

[...]
  gateways:
  - mygateway
  - mesh
  http:
[...]

Or you could create a second VirtualService without the gateways list so it defaults to mesh (or mention only the mesh as gateway if you want to be declarative). The spec.hosts field must contain the host, that is mentioned in the destination.host.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: review-mesh-internal
spec:
  hosts:
  - "reviews.prod.svc.cluster.local" # must be the kubernetes service host as below
  gateways:
  - mesh #optional since it's the default
  http:
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1
      weight: 100

This brings the advantage, that you can route the traffic from outside the cluster differently than from inside the cluster. Think about maintenance for example, where user traffic should not reach a specific pod but traffic from inside the cluster should still be able to.