Connection reset by peer when specifying TLS traffic in Istio - istio

Question

I have a distributed database (Consul) that I want to run within Istio on Kubernetes. Communication between peers are encrypted and verified using mTLS. I am using a headless service to allow the peers to reach each other:
apiVersion: v1
kind: Service
metadata:
name: cluster
namespace: consul
spec:
clusterIP: None
publishNotReadyAddresses: true
selector:
app: consul
ports:
- name: tcp-server
port: 8300
targetPort: 8300
- name: tcp-serflan
protocol: TCP
port: 8301
targetPort: tcp-serflan
- name: udp-serflan
protocol: UDP
port: 8301
targetPort: udp-serflan
However, when I name the tcp-server port on the headless service tls-server instead I see a load of connection reset errors:
2020/02/18 08:46:44 [INFO] serf: EventMemberUpdate: consul-0
2020/02/18 08:47:33 [ERR] agent: Coordinate update error: rpc error making call: stream closed
2020/02/18 08:47:38 [WARN] raft: Heartbeat timeout from "10.0.3.146:8300" reached, starting election
2020/02/18 08:47:38 [INFO] raft: Node at 10.0.2.114:8300 [Candidate] entering Candidate state in term 106
2020/02/18 08:47:38 [ERROR] raft: Failed to make RequestVote RPC to {Voter 54224806-ed63-0d1b-ae2c-9c1a09de43c4 10.0.3.146:8300}: EOF
2020/02/18 08:47:38 [ERROR] raft: Failed to make RequestVote RPC to {Voter 5b2e92ce-61d8-032e-dd94-c0d9eb1319a0 10.0.1.209:8300}: read tcp 10.0.2.114:40018->10.0.1.209:8300: read: connection reset by peer
2020/02/18 08:47:47 [WARN] raft: Election timeout reached, restarting election
2020/02/18 08:47:47 [INFO] raft: Node at 10.0.2.114:8300 [Candidate] entering Candidate state in term 107
2020/02/18 08:47:47 [ERROR] raft: Failed to make RequestVote RPC to {Voter 54224806-ed63-0d1b-ae2c-9c1a09de43c4 10.0.3.146:8300}: read tcp 10.0.2.114:40762->10.0.3.146:8300: read: connection reset by peer
2020/02/18 08:47:47 [ERROR] raft: Failed to make RequestVote RPC to {Voter 5b2e92ce-61d8-032e-dd94-c0d9eb1319a0 10.0.1.209:8300}: read tcp 10.0.2.114:40062->10.0.1.209:8300: read: connection reset by peer
How is Istio/Envoy treating TLS traffic that could be causing this issue? The traffic is TLS traffic (I am doing this) so it seems it's necessary to pretend the traffic is TCP.
Consul version: 1.6.2
Istio version: 1.4.4