NAT port forwarding doesn't work for loopback address on host

[xnoreq]

Setup: Windows 10 host and Linux guest with a single NAT adapter.

Port forwarding: TCP from host address 127.0.0.1 and port 9092 to guest port 9092

On the guest: nc -l -p 9092 (simply listen on the port with netcat)

Test on the host: nc 127.0.0.1 9092

No connection is established, nc immediately exits. telnet 127.0.0.1 9092 immediately exits with: "Connection closed by foreign host."

I have checked, and VirtualBox.exe does listen on 127.0.0.1:9092 TCP, but new connections show up as waiting connections in state Time wait in netstat on the host.

The only way I've got this port forwarding to work is to remove the 127.0.0.1 host address from the port forwarding, and then connect to the host's external IP in the test.

Why doesn't it work for 127.0.0.1 on the host?

[Socratis]

Replying to xnoreq:

Why doesn't it work for 127.0.0.1 on the host?

Because 127.0.0.1 is the host? Why would you even expect it to work? It's similar to putting a rule in place that says "if I call myself, forward the call to myself". Where does the call end up?

Did you expect a rule like "if I call myself, forward the call to someone else"? 127.0.0.1 is (and must be) the very first rule evaluated in any TCP/IP rule, AFAIK.

The NAT port forwarding rules are being evaluated when the "call" is coming from outside. Then the VirtualBox filter has a chance of looking at the packet and handling it accordingly; forwarding it (according to the rules), or letting it go through. When the call is "from within the house", the filter doesn't even have a chance of seeing it.

[xnoreq]

socratis, no, that makes no sense to me.

Given a port forwarding TCP 9092 host to 9092 guest, VirtualBox listens on all host interfaces (in case of IPv4 the socket binds to INADDR_ANY). So, the host could have several NICs with several IP addresses and a connection to any of them on TCP 9092 will be forwarded to the guest.

Now if you entered one IP for the host, you'd limit it to one interface/address, e.g. 192.168.0.1 for a LAN. So now only others in the same subnet can access the service.

And finally, if I enter 127.0.0.1, I'd expect the service only to be accessible from the host itself. I.e. this would prevent people from the "outside" accessing the service.

Nothing changes technically from the previous case. VirtualBox binds to the given IP, and any connection to it on port 9092 will be forwarded to the guest.

Btw, SSH does exactly the same in port forwarding, just through an SSH tunnel. It even defaults to binding to loopback.

[Socratis]

VirtualBox installs a filter for every NIC. So, if a request comes at a NIC with an IP of 192.168.0.1, you'd have VirtualBox process and filter that request and act according to the rules. The "problem" with 127.0.0.1 (localhost) is that it requires no NIC whatsoever. You can have a physical/virtual computer with no NICs and localhost will definitely work. Now, since there are no NICs required for localhost => there's no VirtualBox filter installed at any NIC level that can process this => there's no way to evaluate any rule.

SSH does not work the same way as VirtualBox does (SSH does not install filters nor it cares, VirtualBox does and relies on them), so I'm not sure a comparison between the two makes sense.

If your end goal is to have access to that guest's port from the host only, I suggest you do exactly that; add a HostOnly mode network adapter in your guest. No external communications can/will occur.

[xnoreq]

For the NAT I can understand why there is a need for a NIC filter which apparently does not work on the loopback device, but I don't see that requirement for manual port forwarding.

If this worked by filtering too, then why would VirtualBox.exe bind a LISTENing TCP socket onto port 9092, and why would the bind address change with the configured host address for the forwarded port?

Maybe this is done solely to "block" the port from being used by another application? So this socket basically does nothing, and incoming connections are instead also handled by that NIC filter?

If that is not the case then I can only see it working exactly like SSH port forwarding, which is the only reason I mentioned it.

[Valery Ushakov]

Please, at the very least provide the VBox.log file from the run that demonstrates the problem.

Ideally, please provide also the VM's .vbox file (with the non-working port-forwarding rules for localhost) and the packet capture of the failed connection attempt captured on the guest side.

[xnoreq]

socratis, the information you posted in comment 3 is wrong.

In NAT mode, there is no network filter. VirtualBox.exe opens a UDP or TCP socket on the host with the host port.

Assuming that the host has 1 NIC with IP 192.168.0.2, if no host IP is specified then VirtualBox.exe binds to 0.0.0.0 and 192.168.0.2.

If 192.168.0.2 is specified then it just binds to that IP.

In version 5.1.14 it didn't bind to 127.0.0.1, but I've just checked again and this bug was fixed within the past 14 months. It now correctly binds to loopback.

[xnoreq]

So you can close this ticket with FIXED.