this issue did not be fixed in 4.1.0-0.nightly-2019-08-28-043410
see below. z1 has egress ip and z2 has external ip and z3 without egress ip

# oc get netnamespaces z1 -o yaml
apiVersion: network.openshift.io/v1
egressIPs:
- 139.178.76.100     
kind: NetNamespace
metadata:
  creationTimestamp: "2019-08-29T08:15:49Z"
  generation: 2
  name: z1
  resourceVersion: "27094"
  selfLink: /apis/network.openshift.io/v1/netnamespaces/z1
  uid: 358cb6b6-ca35-11e9-86fc-0050568b2776
netid: 7381622
netname: z1


[root@dhcp-140-66 bug-1726045]# oc get hostsubnet control-plane-0 -o yaml
apiVersion: network.openshift.io/v1
egressIPs:
- 139.178.76.100
host: control-plane-0
hostIP: 139.178.76.37
kind: HostSubnet
metadata:
  annotations:
    pod.network.openshift.io/node-uid: 3aa65225-ca2b-11e9-bf25-0050568b8a56
  creationTimestamp: "2019-08-29T07:05:01Z"
  generation: 2
  name: control-plane-0
  resourceVersion: "28398"
  selfLink: /apis/network.openshift.io/v1/hostsubnets/control-plane-0
  uid: 51ebd6f6-ca2b-11e9-bf25-0050568b8a56
subnet: 10.129.0.0/23

# oc get pod -n z1
NAME        READY   STATUS    RESTARTS   AGE
hello-pod   1/1     Running   0          6m52s

#oc get svc -n z2
NAME               TYPE        CLUSTER-IP      EXTERNAL-IP      PORT(S)     AGE
service-unsecure   ClusterIP   172.30.53.205   139.178.76.101   27017/TCP   20m

# oc get pod -n z3
NAME        READY   STATUS    RESTARTS   AGE
hello-pod   1/1     Running   0          19m

# oc rsh -n z1 hello-pod
/ # curl 139.178.76.101:27017 --connect-timeout 4
curl: (28) Connection timed out after 4001 milliseconds

## oc rsh -n z3 hello-pod
/ # curl 139.178.76.101:27017 --connect-timeout 4
Hello OpenShift!

Nuts. Can you attach the output of `iptables-save` for the test cluster, please?

Created attachment 1609729 [details]
iptables-save

my bad. I thought I attached the iptable rules yesterday. Sorry for late attach

hi Casey

  please ignore above information, this bug had been fixed. I made a mistake using a invalid external ip for node. sorry for this.

  Verified this bug.

Thanks for the update!

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2594