Real World Problem: Wierd ICMP
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Using a PIX 515, 6.3(5) feeding to a Syslog server. In the last 2 days I started seeing the following:
"......305005: No Translation group found for ICP src inside: 12.x.x.166 dst outside 12.x.x.165 (type 11, code 0)
I've done some googling around and this is usually due to no translation existing for the addresses (duh). The wierd part is these addresses are both public IPs that are nowhere near our range. Plus it claims to be coming in on the inside interface. There's no reference to the source address in any of the ARP caches I've tried. We have a parallel connection between our US sites using an AT&T eVPN service and these IPs are AT&T owned which is the only thing I can think of. ICMP is allowed purely for echo-replies from 3 of our servers Public IPs, otherwise restricted (And that policy has been in place for about a month). The only recent change I made was to add an IDS policy to drop packets instead of the global alert policy but I'm not sure exactly when this kicked off (had issues with the Syslog server for 2 days).
Any ideas?
"......305005: No Translation group found for ICP src inside: 12.x.x.166 dst outside 12.x.x.165 (type 11, code 0)
I've done some googling around and this is usually due to no translation existing for the addresses (duh). The wierd part is these addresses are both public IPs that are nowhere near our range. Plus it claims to be coming in on the inside interface. There's no reference to the source address in any of the ARP caches I've tried. We have a parallel connection between our US sites using an AT&T eVPN service and these IPs are AT&T owned which is the only thing I can think of. ICMP is allowed purely for echo-replies from 3 of our servers Public IPs, otherwise restricted (And that policy has been in place for about a month). The only recent change I made was to add an IDS policy to drop packets instead of the global alert policy but I'm not sure exactly when this kicked off (had issues with the Syslog server for 2 days).
Any ideas?
We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
Comments
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Not that it's rousing too much interest but I finally got around to mirroring the PIX switch port to a monitor port and letting ethereal loose on the connection. Absolutely no sign of this ICMP source or anything to do with these IPs. Just to be sure it wasn't some weird conflict from the outside interface being mislabeled I applied a specific block for ICMP to/from these hosts (they were failing due to translation anyway but I wanted to see if they really did bounce off the inside interface) the ACL shows hits every few minutes.
Beeeezzzaaaaarrrreeeee.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Yeah the post that won't go away
. Anyway fixed it. I couldn't trace the traffic down on any of our devices and our Managed Service provider were sure it was't coming in via their router either (it's not in their service IP range) - I asked them to put an ACL outbound from their to our network anywa to deny the source IP and voila, no more hits on our side of the fence.
That's all, only updating this in case anyone runs into something similar (personally I kinda hate googling, finding a similar issue and then just seeing something like "Its fixed...(the end)".We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?