Opened 15 years ago
Closed 11 years ago
#6403 closed defect (obsolete)
BindIP does not work for inbound NAT port-forwarded connections
| Reported by: | Jason Roysdon | Owned by: | |
|---|---|---|---|
| Component: | network/NAT | Version: | VirtualBox 3.1.4 |
| Keywords: | bindip | Cc: | vbox.20100320@… |
| Guest type: | other | Host type: | other |
Description (last modified by )
Linux HostOS with multiple secondary IPs bound.
1.1.1.x are public/outside addresses in this example.
eth0 - primary hostos IP 1.1.1.1
eth0:2 - secondary hostos IP 1.1.1.2
eth0:3 - secondary hostos IP 1.1.1.3
Hostos has tcp/22 bound specifically to 1.1.1.1 with sshd using the "ListenAddress 1.1.1.1" directive in sshd_config.
Now setting the guestos to bind to 1.1.1.2:
VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/BindIP" "1.1.1.2" VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22 VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 22
Then when trying to connect to ssh -p 22 1.1.1.2 connection is refused, and wireshark dump on the hostos shows it is being reset.
Testing this by binding to tcp/23 for the guestos on the outside of the NAT:
VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22 VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 23
Now, ssh -p 23 1.1.1.2 works. However, ssh -23 1.1.1.1 is also being forwarded to the guestos, but is not what is expected due to the BindIP of 1.1.1.2.
Hostos netstat reports guestos is binding ALL (0.0.0.0) tcp/23 connections. This should not be.
For instance, should I want to bind 1.1.1.2:80 to guestosA and 1.1.1.3:80 to guestosB, you cannot, as the first guestos that starts will bind to all 0.0.0.0:80. The BindIP should limit what IP address the NAT's are bound to.
Attachments (4)
Change History (12)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
| Description: | modified (diff) |
|---|
follow-up: 4 comment:3 by , 15 years ago
Using with or without the guestos-servicename/BindIP, UDP services do not stay bound during guest os boot:
VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/BindIP" "1.1.1.2" VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guest-udp53/Protocol" UDP VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guest-udp53/GuestPort" 53 VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guest-udp53/HostPort" 53 VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guest-udp53/BindIP" "1.1.1.2"
(I also have TCP-53 bound as well with guest-tcp53)
Starting this guest will show the following for a time:
# netstat -nap | grep 53 tcp 0 0 1.1.1.2:53 0.0.0.0:* LISTEN 2862/VBoxHeadless udp 0 0 1.1.1.2:53 0.0.0.0:* 2862/VBoxHeadless
However, once the guestos begins to boot (perhaps when named binds to udp/53 on the guest os? I'm not sure about the timing) then udp/53 will no longer be listening on the HostOS with the same netstat grep, and NAT port forwards for udp/53 won't work.
As a work-around, I can save the guest os and start it back (to the saved state) and then udp/53 will stay bound on the HostOS.
Stopping and starting named or vboxadd* services on the guest os does not break udp/53 listening and forwarding on the HostOS, so it is not as simple as the GuestOS binding to udp/53 causing it to drop on the HostOS.
An additional item (perhaps a new bug should be opened), outbound NAT connections are not affected by:
VBoxManage setextradata "guest os" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/BindIP" "1.1.1.2"
I have an eth0 (1.1.1.1) and eth0:2 (1.1.1.2). The guest os is to use 1.1.1.2 for outbound NAT'd connections. It uses 1.1.1.1 even with the above outbound NAT binding configured. Naturally this causes dns transfers to fail since it bind to the wrong IP address. For now, as yet another work-around, I have bound 1.1.1.2 as eth0 and delete eth0:2 and created eth0:1 for 1.1.1.1, but now my hostos uses the wrong source-address for outbound initiated traffic (which is fine for now). However, this would not work should more than 2 guestos need to be bound with different outbound NAT'd IPs.
follow-up: 6 comment:5 by , 15 years ago
comment:6 by , 15 years ago
by , 15 years ago
| Attachment: | VBox.log.1 added |
|---|
Previous bootup log, most likely had UDP/53 NAT go away after boot
comment:8 by , 11 years ago
| Description: | modified (diff) |
|---|---|
| Resolution: | → obsolete |
| Status: | new → closed |
Since port-forwarding configuration changed, any bugs that were there are probably no longer relevant. There are new ones of course :), and #11925 looks similar. Please, use it for further updates, if still relevant.
For binding outbound connections to specific IP (comment:3), please see VBoxManage modifyvm "VM name" --natbindip1 "IP" in the manual (Binding NAT sockets to a specific interface).
Replying to jroysdon:
This parameter bind your outgoing connections to 1.1.1.2 interface.
To bind port-forwarding to interface you need
please see http://www.virtualbox.org/manual/ch09.html#id2548533 for more details.