A SOCKS service inside a VirtualBox guest has two separate reachability requirements: VirtualBox must deliver the connection to the guest, and the guest service must accept it.

For a VM whose first adapter uses ordinary NAT, VirtualBox 7.1 documents a port-forwarding rule in this form. With the VM stopped:

VBoxManage modifyvm "Proxy VM" --nat-pf1 "socks,tcp,127.0.0.1,1080,,1080"

Replace the VM name and ports as needed. The host application then selects SOCKS at 127.0.0.1:1080. Binding the host side to 127.0.0.1 limits this entry point to the host itself.

The empty guest-address field assumes the guest uses the NAT engine’s built-in DHCP assignment. If the guest uses a static address instead, supply that address in the rule. The final 1080 is the guest service port; it need not equal the host port.

The guest listener is still a network service

A proxy bound only to 127.0.0.1 inside the guest accepts guest-local connections. NAT forwarding does not make that loopback listener accept traffic arriving on the guest’s virtual interface. Configure the service to listen on an appropriate guest interface and allow the intended traffic through the guest firewall and proxy access rules. Check the listener’s permitted and denied access after changing that boundary.

Inspect these boundaries separately when it fails: the host port and rule, the selected guest address, and the guest listener. Switching to bridged networking cannot repair a service that still listens only on guest loopback.

This TCP rule covers a SOCKS TCP connection. It does not, by itself, provide the additional UDP path needed by a SOCKS5 UDP relay.

Erthyglow kevrennek