VirtualBox

Ticket #15256 (new defect)

Opened 5 years ago

Last modified 5 years ago

virtualbox nat doesn't obey mss parameter

Reported by: aojea Owned by:
Component: network/NAT Version: VirtualBox 5.0.16
Keywords: nat, mss, mtu Cc:
Guest type: all Host type: all

Description

Versions 4.X and 5.X of Virtualbox, when using the NAT interface, doesn't obey the mss of the VM and change tthe MSS in the TCP handshake.

To reproduce you only need to modify the MTU of the interface in the VM and do a curl or start other TCP connection:

root@vagrant-ubuntu-trusty-64:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:19:c3:bf brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever

As you can see in the capture inside the VM the SYN has an MSS of 960 meanwhile the answer has 1460

21:25:08.128132 08:00:27:19:c3:bf > 52:54:00:12:35:02, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 36522, offset 0, flags [DF], proto TCP
(6), length 60)
    10.0.2.15.48438 > 216.58.201.131.80: Flags [S], cksum 0xadfb (incorrect -> 0xba07), seq 1793847297, win 19200, options [mss 960,sackOK,TS val 32427
 ecr 0,nop,wscale 7], length 0
21:25:08.138613 52:54:00:12:35:02 > 08:00:27:19:c3:bf, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 796, offset 0, flags [none], proto TCP
(6), length 44)
    216.58.201.131.80 > 10.0.2.15.48438: Flags [S.], cksum 0xb496 (correct), seq 54336001, ack 1793847298, win 65535, options [mss 1460], length 0
21:25:08.138644 08:00:27:19:c3:bf > 52:54:00:12:35:02, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 36523, offset 0, flags [DF], proto TCP
(6), length 40)

The capture from the host reveals that the output packet has MSS 1460 in both connections, thus the most probable is that Virtualbox NAT is modifying the MSS. (the capture has different times, but is the same behaviour always)

17:48:42.795919 Out fc:aa:14:93:94:b0 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 64, id 51370, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.30.31.39163 > 216.58.201.131.80: Flags [S], cksum 0x80b4 (incorrect -> 0x77f4), seq 3898897121, win 29200, options [mss 1460,sackOK,TS val
781761099 ecr 0,nop,wscale 7], length 0
17:48:42.806111  In 84:18:88:78:9a:42 ethertype IPv4 (0x0800), length 76: (tos 0x0, ttl 54, id 62615, offset 0, flags [none], proto TCP (6), length 60)
    216.58.201.131.80 > 192.168.30.31.39163: Flags [S.], cksum 0xa1e9 (correct), seq 4238402083, ack 3898897122, win 42540, options [mss 1430,sackOK,TS
 val 172144884 ecr 781761099,nop,wscale 7], length 0

This is not a problem with one VM, but if you use more complex topologies, we are using to emulate an openstack cloud, you have problems because the packets are bigger than the mtu and are dropped in the vms

Change History

comment:1 Changed 5 years ago by vushakov

A bit of nitpicking first:

As you can see in the capture inside the VM the SYN has an MSS of 960 meanwhile the answer has 1460.

This sentence (taken in isolation for the sake of argument) seems to imply that 1460 is incorrect. However Stevens begins discussion of this option with:

Some texts refer to this as a "negotiated" option. It is not negotiated in any way. When a connection is established, each end has the option of announcing the MSS it expects to receive.

and  RFC879:

The MSS can be used completely independently in each direction of data flow.

While MTU is usually the primary factor, nothing in principle precludes an implementation from using MSS to e.g. advertise a smaller-than-MTU internal buffer it is capable of handling (e.g. a 1K-page sized packet buffers used by a 16-bit implementation).

The next thing that I think needs to be mentioned explicitly is that "NAT" is an unfortunate misnomer (historical reasons). It's not a real NAT, it's better described as automagic socks-like proxy. It uses host sockets. Now, there is TCP_MAXSEG socket option that can be set for outgoing connections to the value advertised by the guest in its SYN packet. However there is, as far as I know, no way to retrieve the MSS option advertised by the peer, so it cannot be propagated to the guest.

In any case the point is moot as the guest is not actually talking to the tcp stack of its peer, but to the tcp stack of the "NAT". Host should take care of never sending larger packets to the peer if peer advertises small MSS. Slirp too - it shouldn't send large packets to the guest that advertises small MSS. If that doesn't happen, it's a bug, but in that case I'd like to see the packet captures.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use