08-03-2018 07:24 AM - edited 03-05-2019 10:49 AM
Cisco 2951, Version 15.5(3)M5
*The public IP is NAT'd.
Production router in use for years. I received the below message from my syslog server today.
*Aug 3 05:12:11.048: %IP_VFR-3-OVERLAP_FRAGMENTS: GigabitEthernet0/0: from the host xx.xx.xx.xx destined to %my publicIP%
Here is my ACL (*thought this would stop fragments)
ip access-list extended inbound
deny tcp any any fragments
deny udp any any fragments
deny icmp any any fragments
deny ip any any fragments
deny icmp any any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip host 0.0.0.0 any
permit ip any any
Here is Virtual-reassembly for G0/0
GigabitEthernet0/0:
Virtual Fragment Reassembly (VFR) is ENABLED [in]
Concurrent reassemblies (max-reassemblies): 1000
Fragments per reassembly (max-fragments): 32
Reassembly timeout (timeout): 3 seconds
Drop fragments: OFF
Current reassembly count:0
Current fragment count:0
Total reassembly count:54428
Total reassembly timeout count:104873
Would it be advisable for "Drop Fragments" to be ON (with command below on intG0/0?)
ip virtual-reassebly in max-reassemblies 1000 max-fragments 32 timeout 3 drop-fragments
What are the causes of this? (as at first I added IP to DENY in ACL, but I have removed that as I found out it the IP belonged to a remote worker. I did check MTU size and it was 1500)
08-18-2018 10:41 AM
i have the exact same issue here.. it looks like buffer overflow attack from what i have read so far. i am still looking for a remedy.
08-18-2018 11:00 AM - edited 08-18-2018 11:03 AM
ip virtual-reassebly in max-reassemblies 1000 max-fragments 32 timeout 3 drop-fragments
I wish someone with experience would provide some insight.
The issue has not returned, although not like it was happening often, as it happened 1 time in the last few years. I have had no issues with adding the command above, and hope its stopped the fragments completely.
08-18-2018 03:17 PM
08-18-2018 07:05 PM
This interface is my public interface, and I don't want fragments anyway. I thought my ACL handled that.
Anyway, like I said, the IP that caused this was from an employee, on VPN. I am not sure how it happened, I just want to stop fragments. If this command "fixed" it, I will make sure to implement on all public interfaces.
08-18-2018 07:16 PM
08-18-2018 07:26 PM
Again, as originally stated, I checked the MTU size.
*All employees are remote, and this was the first case of this, and the same Router with same config, for years. This employee was with company before I started 3 years ago, so again not sure of what "really" caused it, but I am hoping the new command stops fragments, as my ACL did not completely stop them.
Anything other than MTU size that could of caused this error?
08-18-2018 07:44 PM
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: