ppggff / vagrant-qemu

Use Vagrant to manage machines using QEMU. Test with Apple Silicon / M1 and CentOS aarch64 image
MIT License
424 stars 33 forks source link

Port forwarding not working on ARM Mac and RHEL/Alma/Rocky/Cent 8+ #60

Closed kmasaryk closed 3 months ago

kmasaryk commented 3 months ago

Port forwarding is not working on the following boxes running on an M3 MBP (box names in parens):

I'm unable to get any RHEL9/Alma9/Rocky9 x86 version working at all so couldn't test the port forwarding but that's a different issue.

Oddly, forwarding on the 'almalinux/8' x86 box DOES work so it seems there's something about how the box was built which may influence whether PF works with vagrant-qemu or not.

I'm using a simple Vagrantfile:

config.vm.provider "qemu" do |qe|
  qe.arch = "x86_64"
  qe.machine = "q35"
  qe.cpu = "qemu64"
  qe.net_device = "virtio-net-pci"
end

config.vm.network "forwarded_port", guest: 80, host: 8080

Tested connectivity with python3 -m http.server 80 and nc -l 80 in addition to confirming no traffic coming into the VM with tcpdump.

I do see the port open and listening on the Mac side..it's just that the packets don't seem to make it into the VM. In other words, no errors, it's just a black hole.

What's really strange is that vagrant ssh works on every OS and that uses a 22-->50022 port forwarding by default. That's promising since it suggests that it is possible to make it work...somehow.

ppggff commented 3 months ago

I tried the CentOS8 x86 (generic/centos8) box. It works after enable the firewall with following command:

sudo firewall-cmd --zone=public --add-port 80/tcp
kmasaryk commented 3 months ago

Thanks @ppggff I'd forgotten that rules aren't visible with 'iptables --list' when running firewalld and 'iptables --flush' has no effect.

I do have http working now but https requests all generate "Connection reset by peer" errors.

$ curl -v -k https://127.0.0.1:55443
*   Trying 127.0.0.1:55443...
* Connected to 127.0.0.1 (127.0.0.1) port 55443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection
curl: (35) Recv failure: Connection reset by peer

Trying the same command in the VM itself works without issue. I found testing to be easiest with the example Python server found here.

Can anyone replicate this behavior?

ppggff commented 3 months ago

It works without "Connection reset by peer" error.

Screenshot 2024-06-19 at 12 09 50
kmasaryk commented 3 months ago

Thanks for checking. Must be something on my end.