As far as I know there should not be any issues with that.
Few examples below.
Take a look at ambassador api gateway documentation and a post on itnext.io about connecting it with istio.
Ambassador is a Kubernetes-native API Gateway for microservices. Ambassador is deployed at the edge of your network, and routes incoming traffic to your internal services (aka “north-south” traffic). Istio is a service mesh for microservices, and designed to add L7 observability, routing, and resilience to service-to-service traffic (aka “east-west” traffic). Both Istio and Ambassador are built using Envoy.
Ambassador and Istio can be deployed together on Kubernetes. In this configuration, incoming traffic from outside the cluster is first routed through Ambassador, which then routes the traffic to Istio. Ambassador handles authentication, edge routing, TLS termination, and other traditional edge functions.
This allows the operator to have the best of both worlds: a high performance, modern edge service (Ambassador) combined with a state-of-the-art service mesh (Istio). Istio’s basic ingress controller, the ingress controller is very limited, and has no support for authentication or many of the other features of Ambassador.
Take a look at documentation about Extending Istio 1.5 with Gloo API Gateway
Gloo is an open-source API Gateway built on Envoy Proxy that highly complements a service mesh like Istio with edge capabilities like request/response transformations, direct-response actions, and Open API Spec/Swagger and gRPC discovery. Gloo Enterprise supports more sophisticated security edge requirements like OIDC authentication, OPA authorization, Web Application Fire walling (WAF), rate limiting and others. A lot of Gloo users put Gloo at the edge and integrate with Istio for east-west traffic management.