﻿id	summary	reporter	owner	description	type	status	component	version	resolution	keywords	cc	guest	host
15256	virtualbox nat doesn't obey mss parameter	aojea		"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"	defect	closed	network/NAT	VirtualBox 5.0.16	fixed	nat, mss, mtu		all	all
