<p>So we are running istio 1.3.5</p>
<p>We have a docker container running a dotnet core application that is trying to consume messages from azure event hub.</p>
<p>With the istio sidecar turned on, we get a 404, with it turned off things work just fine.</p>
<p>Also interesting is you can send messages to the event hub just fine with the sidecar enabled.</p>
<p>here's the istio related yaml that's &quot;in play&quot; in the namespace:</p>
<pre><code>apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
spec:
  egress:
  - hosts:
    - &quot;./*&quot;
    - &quot;elasticsearch/*&quot;
</code></pre>
<pre><code>apiVersion: &quot;networking.istio.io/v1alpha3&quot;
kind: &quot;DestinationRule&quot;
metadata:
  name: &quot;default&quot;
spec:
  host: &quot;*.MYNAMESPACE_NAME.svc.cluster.local&quot;
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

</code></pre>
<pre><code>apiVersion: &quot;authentication.istio.io/v1alpha1&quot;
kind: &quot;Policy&quot;
metadata:
  name: &quot;default&quot;
spec:
  peers:
  - mtls: {}
</code></pre>

Todd Spurlock
<p>We have figured out the issue.<br />
When the istio sidecar and the main micro service startup, there is a period of time where the istio sidecar is initializing itself and is not “on”.<br />
During this period all network traffic from the main microservice is blocked.<br />
<strong>To fix this you need to make a call to an istio sidecar endpoint before your main program starts.</strong></p>
<pre><code>    #!/bin/bash 
    until curl  --head localhost:15000   
    do  
       echo &quot;Waiting for Sidecar&quot;  
       sleep 3   
    done   
    
    echo &quot;Sidecar available&quot;  
</code></pre>
