These packets were catured in our inside interface, and came in because have SIP open to the world for some bizarre reason. The host 184.108.40.206 did not have a SIP service running on it, I don't know why it was chosen as a target. What was actually killing our ASA was not the packets themselves, but that it was setting up a connection for each incoming packet. Output from "show conn":
UDP out 127.0.0.1:5066 in 220.127.116.11:0 idle 0:00:05 flags ti UDP out 18.104.22.168:5066 in 22.214.171.124:0 idle 0:00:05 flags ti
There were actually many more connections to 127.0.0.1 than to 126.96.36.199. Anyway, we took the 188.8.131.52 host down, cleared the arp table and put in a block for 184.108.40.206 and that took care of it.
What is strange though, is that even though 220.127.116.11 is gone and cleared from the arp table, if a remove the acces-list rule blocking 18.104.22.168 and let it start spewing SIP packets at the now-nonexistent host 22.214.171.124, it still DoSes the ASA with bogus connections:
UDP out 127.0.0.1:5066 in 126.96.36.199:0 idle 0:00:19 flags ti UDP out 127.0.0.1:5066 in 188.8.131.52:0 idle 0:00:19 flags ti UDP out 127.0.0.1:5066 in 184.108.40.206:0 idle 0:00:19 flags ti
There is still no arp entry for 220.127.116.11 and as far as I can tell these connections are "internal" to the ASA.
Is there a way to get the ASA to not attempt to create these connections? So far, I have been unable to capture any packets now that host 18.104.22.168 is gone. Also, I am mystified by what "22.214.171.124:0" (port 0?) could mean.
The port 0 connections are created bye the SIP inspection as secondary connections to the initial SIP connection. These connections are usually for some voice traffic and are build with a port of 0 indicating that they are the half-open inspection generated connections. Outside of blocking this traffic (which yout should so if that host has no SIP functionality), there isn't much we can do to prevent this at this time. I would highly suggest opening a Service-request for this one so that we can investigate the issue a bit more thoroughly. Once you open that case, please message me the SR number so I can track it.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...