Christophe Fergeau

An alternative is to have `crc` bind to `0.0.0.0` instead of `127.0.0.1` for its VM ports which removes the need for the haproxy instance.

I see binding to 127.0.0.1 as some kind of isolation feature, keep the VM private to the local machine. I don't know if there was more to this design choice.

> An alternative is to have `crc` bind to `0.0.0.0` instead of `127.0.0.1` for its VM ports which removes the need for the haproxy instance. Actually, the daemon is already...

Thanks for the report! This is a side-effect of b14fb9dd247e8860daa848e5966ca0aff1af46ec (the tests assume the openshift preset is in use), and was not detected because we don't have any automated m1...

I gave this a quick try, and moved vfkit to see how it goes. I documented my findings so far in https://github.com/crc-org/vfkit/wiki/Moving-from-code-ready-to-crc-org

List of modules to be moved: - [x] vfkit https://github.com/crc-org/vfkit/pull/9 - [x] snc - [x] routes-controller https://github.com/crc-org/routes-controller/pull/9 - [x] admin-helper https://github.com/crc-org/admin-helper/pull/37 - [x] machine - [x] machine-driver-libvirt - [x] crc...

Since the vfkit move went smoothly, I'll move soon a bigger set of modules if there are no objections. I'm thinking routes-controller/admin-helper/machine/machine-driver-libvirt, and once they are moved, file a PR...

The initial connection to the cluster using `oc` is currently unsecure as `oc` does not know which CA is being used. I'm guessing it's the same CA as the one...

There's also this OpenShift enhancement https://github.com/openshift/enhancements/pull/137

If you are using `network-mode=vsock`, you cannot use haproxy, see https://github.com/code-ready/crc/issues/2667#issuecomment-915257243 for an alternative which should work: ``` firewall-cmd --zone=public --add-port=2222/tcp firewall-cmd --zone=public --add-service=https firewall-cmd --zone=public --add-service=http ```