Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

While configuring NAT, I will sometimes see “ip virtual-reassembly” added to the NAT interfaces’ configurations:

ip nat inside source list 99 interface Serial0/0 overload
!
access-list 99 permit 10.0.0.0 0.0.0.255
!
interface FastEthernet0/0
description ->sw1 fa0/1
ip address 10.0.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
 duplex auto
speed auto
!
interface Serial0/0
ip address 100.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
encapsulation frame-relay
frame-relay map ip 100.0.0.2 102 broadcast
no frame-relay inverse-arp

IOS throws that on automatically.  Here’s what it does:

A buffer overflow attack can occur when an attacker continuously sends a large number of incomplete IP fragments, causing the firewall to lose time and memory while trying to reassemble the fake packets.

The max-reassemblies number option and the max-fragments number option allow you to configure maximum threshold values to avoid a buffer overflow attack and to control memory usage.

In addition to configuring the maximum threshold values, each IP datagram is associated with a managed timer. If the IP datagram does not receive all of the fragments within the specified time (which can be configured via the timeout seconds option), the timer will expire and the IP datagram (and all of its fragments) will be dropped.

Here’s why it does it:

VFR is designed to work with any feature that requires fragment reassembly (such as Cisco IOS Firewall and NAT). Currently, NAT enables and disables VFR internally; that is, when NAT is enabled on an interface, VFR is automatically enabled on that interface.