An alien packet from the switch shut down my ethernet card when using nessus?

Question

I'm stuck in between a very bad cocktail mix of two very desperate technologies. One is Nessus and other is a Juniper EX2200. When I'm running the two together, the NIC on my HP MiniTower 6200 Pro shuts down completely. This happens roughly 2-3 minutes into the Nessus scan.

My environment is that I have a Juniper switch set up along with SSG-5, which provides the gateway for the lab-test environment. Firewall is working in NAT mode.

Rough description of my problem environment is:

Juniper ---> uplink
|
SWITCH ---> vlan 20 > connected via trunk cable
|
PC - Gigbait Ethernet card (belongs to vlan20)

When the Ethernet card shuts down, the packet dump shows (if I remember correctly):

Juniper84:91:12  ........ 52 RST spanning tree

It is a link layer protocol message coming from the Juniper switch.

Also, if I run the scan using uplink direct connected into my NIC card I do not get a problem.

I'm thinking that there is some kind of update sent from switch to my access port which shuts down the NIC card, something like STP updates. Right now, I haven't disabled such updates because I really don't know what is causing it.

Also, please suggest any troubleshooting steps / commands I can run on switch device.

update

I just resolved the problem as I just found that VMWare networking service was sending in VTP updates through my machine access port, doing so resulted in core switch putting my port into blocking mode.

With this solved, is there a way I can prevent this from happening at the switch level instead of just disabling VMWare services?

Answer 1

What policies do you have enabled in the Nessus scan? If you have the Juniper and/or switch plugins enabled, you may be triggering an STP response from the switch.

Try disabling the plugins, to see if the problem persists.

Answer 2

I would suspect hardware issues with your HP mini tower. Suggestion: Try running the scan from a different machine with different hardware.

Trouble shooting these kind of hardware issues is probably not worth your time. It is a rats nest and you could spend days or weeks on it, and even then, maybe not reliably identify the cause of the problem.

If running the Nessus scan from a different machine works, then you have made great progress. You can either keep using the other machine, and now you've fulfilled your goals (successfully run the Nessus scan).

Or, if for some reason you really want to diagnose the root cause of the problem, you've made progress towards that, because now you have a case where the problem is known not to arise. In any case if you really want to diagnose the root cause, the first step will be to make sure you have an environment where it works reliably and an environment where it fails reliably, and then start minimizing the differences between the two until you have narrowed down the cause. So trying a different machine with different hardware is probably the first step no matter your end goal.

Answer 3

From the above, you're not able to run a scan using Nessus when you connect to the EX2200 (ssg as well?) but when you connect directly to the uplink, you can run/complete the scan - is that correct?

Assuming it is, when you say the interface "shuts down," can you confirm at what level the interface shuts down? For example, is it a physical port down (i.e. link lights go out) or is it logical (l2 or higher)? In either case, chances are you're on the right path. The ex220 (or perhaps even the ssg) could disable/shut-down a port if it detects certain policy violations. Depending on how the port is disabled/shut-down, you could figure out what's causing the behavior. Assuming you're running JUNOS 12.1, here's a link to a page with documentation for the EX series switch. EX can run as a UTM (and other security modules) so it's possible that physical shutdown or port disablement is initiated by some module on EX. In an enterprise, you'd be concerned if some port randomly started to initiate suspicious behavior (ip address spoofing, mac address spoofing, storm control, etc).

I'd recommend checking the security features on the ex2200 first to determine if (or which) security feature is kicking in. Otherwise, could it be the ssg (the above diagram wasn't clear whether you initiated the scan internal or external to the ssg).