8

I have an issue where a Netscreen 25 is being flooded with IKE packets from an unrelated source, which at times is overloading the firewall's processing capacity. I see thousands of log entries indicating that the IKE messages are being rejected:

Rejected an IKE packet on ethernet1 from x.x.x.x:500 to y.y.y.y:500 with cookies c423bfd6ca96608b and 0000000000000000 because an initial Phase 1 packet arrived from an unrecognized peer gateway.

Is there a way to filter the control plane of the firewall so that these packets are dropped at the interface edge rather than processed and rejected? This would be done with a simple interface ACL on a Cisco router or ASA, but I'm not sure how to go about this on ScreenOS.

Jeremy Stretch
  • 4,718
  • 1
  • 31
  • 42
  • Thousands of entries over how much time? The "unrecognized peer gateway" means that sure, someone could be up to no good, but more likely it's that you have a manual gateway entry on your end that's wrong, or a VPN entry tied to the wrong interface, or it could very well be that someone randomly typed in your address for no reason than an accident happens sometimes. You're getting an IKE packet that looks malformed. This should not overload a firewall. Not by a long shot. However, back to question #1, how many entries over how much time -- and where from? – Thomas Cannon May 15 '13 at 07:46

3 Answers3

6

You could try terminating the VPN tunnels on the IP address of a loopback interface, and creating a policy rule to specify what sources are (not) allowed to contact this VPN endpoint. If the loopback interface is in the same zone as the interface receiving the traffic, enable "block intra-zone traffic" for this zone and specify a rule to permit your VPNs.

Gerben
  • 4,670
  • 20
  • 32
5

That should be caught by the default dos-protection-group. No? Do you have, perhaps, 'unset ike dos-protection' ?

What does 'show suspicious-control-flow-detection ike' show?

Craig Constantine
  • 4,972
  • 5
  • 36
  • 53
3

Short answer, no.

Long answer, no and..

Basically the netscreens will listen for any IKE packets coming to the device and attempt to process them. While it's a vector for attacks I haven't seen juniper change this behavior.

Short of filling up your event log it shouldn't do much assuming it's a single source attempting to stand up a VPN tunnel to you. If you think it's impacting your performance you can check 'get cpu perf all detail" and see the task/flow CPU usage.

Tim
  • 31
  • 2