In this case, however, what's being seen is simply valid traffic which was most likely erroneously redirected through an internal encryption device.
I would hazard a guess the folks involved have already jumped on checking the redirector rules to fix the leakage which allowed external IPs to be passed through the internal encryption pathway. I helped build the system that's causing those messages, so I have a bit of a guess as to what the issue is. I'm no longer an employee, however, so I can't fix the issue. But in this case, those boxes really aren't trying to attack you--they just aren't supposed to be sending traffic externally like that. So, it actually is good to speak up about this traffic--because it's a fixable issue, and one that should be addressed at the source. Thanks! Matt #notspeakingofficiallyforanyoneoranything On Fri, Dec 18, 2020 at 9:05 PM Dobbins, Roland <roland.dobb...@netscout.com> wrote: > > > On Dec 19, 2020, at 01:19, Frank Bulk <frnk...@iname.com> wrote: > > Curious if someone can point me in the right direction. In the last three > days our core router (Cisco 7609) has logged the following events: > > Dec 16 19:04:59.027 CST: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC > packet has invalid spi for destaddr=<redacted>, prot=50, > spi=0xEF7ED795(4018067349), srcaddr=68.180.160.18, input interface=Vlan20 > > > It should be noted that attackers will sometimes generate > non-TCP/-UDP/-ICMP DDoS attack traffic which is intended to bypass ACLs, > firewall rules, etc. which only take the more common protocols into > account. They'll often pick ESP (protocol 50, AH (protocol 51), or GRE > (protocol 47) in order to try & masquerade the attack traffic as legitimate > VPN or tunneled traffic. > > And the source IPs of this attack traffic are frequently spoofed, as well. > > -------------------------------------------- > > Roland Dobbins <roland.dobb...@netscout.com> > > >
