crc-org / crc

CRC is a tool to help you run containers. It manages a local OpenShift 4.x cluster, Microshift or a Podman VM optimized for testing and development purposes
https://crc.dev
Apache License 2.0
1.26k stars 242 forks source link

Can't reach host.crc.testing running on Windows #4440

Closed evilADevil closed 1 week ago

evilADevil commented 1 week ago

Hello, I'm facing a problem that I had not in the past. I have both a Nginx and a MSSQL DB running on my local machine and it looks like I cannot reach them from within a container running in OCP Local. Here is my configuration:

C:\Users\024358758>crc config view
 - consent-telemetry                     : no
 - cpus                                  : 12
 - disk-size                             : 200
 - host-network-access                   : true
 - memory                                : 32768

I've recreated the environment multiple times without success. If I issue the curl command from the Windows cmd, I get:

C:\Users\024358758>curl --ipv4 -v localhost
* Host localhost:80 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/8.9.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx/1.22.1
< Date: Fri, 08 Nov 2024 11:06:41 GMT
< Content-Type: text/html
< Content-Length: 3692
< Last-Modified: Sun, 14 Jan 2024 07:30:24 GMT
< Connection: keep-alive
< ETag: "65a38d90-e6c"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
...

If I run the same command from a container, I get:

sh-5.1# curl -v --ipv4 host.crc.testing
*   Trying 192.168.127.254:80...
* Connected to host.crc.testing (192.168.127.254) port 80 (#0)
> GET / HTTP/1.1
> Host: host.crc.testing
> User-Agent: curl/7.76.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Fri, 08 Nov 2024 10:57:44 GMT
< Content-Length: 19
< 
404 page not found
* Connection #0 to host host.crc.testing left intact

Looks like something else is responding, not the Nginx running on my local machine. Interestingly enough, when targeting the MSSQL DB, from the Windows cmd, I see the connection being established and cut by the server:

C:\Users\024358758>curl --ipv4 -v localhost:1433
* Host localhost:1433 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:1433...
* Connected to localhost (127.0.0.1) port 1433
> GET / HTTP/1.1
> Host: localhost:1433
> User-Agent: curl/8.9.1
> Accept: */*
>
* Empty reply from server
* shutting down connection #0
curl: (52) Empty reply from server

but a similar command like curl -v --ipv4 host.crc.testing:1433 from within a container just hangs forever. As I said, this was not happening in the past, but I can't figure out what may have changed in my environment, aside from the CRC version that is now:

C:\Users\024358758>crc version
WARN A new version (2.43.0) has been published on https://developers.redhat.com/content-gateway/file/pub/openshift-v4/clients/crc/2.43.0/crc-windows-installer.zip
CRC version: 2.41.0+e6495f
OpenShift version: 4.16.7
MicroShift version: 4.16.7

Any help in sorting this out is appreciated ;)

cfergeau commented 1 week ago

@evidolob this is possibly a gvisor-tap-vsock bug/regression

cfergeau commented 1 week ago

@evilADevil Can you try with the latest crc version to see if this still happens? https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/

evilADevil commented 1 week ago

Thank you @cfergeau I tried with the latest and it works. I have to mention that I have done a complete cleanup, therefore, not just the crc cleanup but an uninstall and reinstall of the OCP Local. Therefore I cannot be sure what exactly solved my problem, given before I only did the crc cleanup and not the uninstall. I also want to mention that the nginx test should have been done on a port different from 80. There is evidently something running on that port that does not allow to reach the nginx running on the host. In fact when I had the nginx on the host run on port 8088, I was able to reach it from within the container.