0

I am unable to get mTLS working between an Istio Gateway and a workload within my mesh. I get the following error when calling from the Istio Gateway to the target service:

curl http://target-service.default
curl: (56) Recv failure: Connection reset by peer

I have an Istio Gateway installed in the istio-system namespace. I also have a workload installed in the default namespace. The traffic flow looks like this:

Inbound traffic => Istio Gateway (istio-system ns) => Target Service (default ns)

I have applied PeerAuthentication in the default namespace for mtls

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

I am able to access the target workload using mTLS from other pods, it is only the Istio Gateway that is unable to do so. I have auto-injection turned on for the Istio Gateway and it appears to be working fine. Other workloads within the istio-system namespace can access the target service, only the Istio Gateway cannot.

I want to make sure the traffic from the Gateway to the target service is encrypted. Any input would be much appreicated.

2 Answers2

0

I was seeing this issue regardless of the mTLS peerauthentication configuration - I was using AWS EKS, with kubernetes version 1.26.

What was causing this issue for me was that on the node group level, there wasn't a security group rule that allowed all the traffic within the SG - Basically all traffic should be allowed within the node group - ref https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html .

Once i enabled that rule, my applications started working fine. Let me know if that helps

  • Thanks for posting @Srikar. My EKS node security group is already open to all internal traffic so this doesn't solve it for me. Also, I'm only seeing this issue with mTLS enabled. With mTLS disabled I don't run into this error at all. Thank you. – Ryan Pagel Jul 10 '23 at 20:24
0

Ok, I've got this working now. I had FluxCD installed and I think it was messing things up. Wireshark is showing encryption between the gateway and the target pod now.