TCP Reset

[christophe.fernandes]

Hello,

Is it possible to send a tcp reset with only one interface sensing to multiple Vlan ?

The switching device is a catalyst 3550.

Thanks

[bphan]

Hello Christophe:

TCP Reset is done by the Command & Command interface or a dedicated interface for TCP Reset (such as interface 0 on a 4250-XL). This is regardless of how your sniffing interfaces are configured.

Best regards,

Binh

[marcabal]

This is dependant on your sensor and switch.

The first thing to understand is that the majority of sensor appliances will send the tcp resets back out the same interface that was being monitored.

So for tcp resets to work the switch has to allow packets to come in from a span port (not all switches allow this).

There are a few exceptions:

The IDSM-2 and 4250-XL (running version 4.1) use a separate interface for sending tcp resets (with version 5.0 the 4250-XL now sends resets back out the sniffing interface).

In version any sensor with more than 2 interfaces can be configured so that other ports can be configured as the alternate tcp reset interface. In other words if I am sensing on port 1/1 then I can configure the sensor to use port 1/2 as the tcp reset interface for packets seen from port 1/1.

The command and control port is never used for tcp resets. The command and control port is used for sending block/shun commands to routers and firewalls, but not tcp resets.

I am not familiar with the Cat 3550, but I can give some examples using the Cat 6500.

With the Catalyst 6500 the switch can send packets to a promiscuous sensor using either Span or VACL Capture. The sensor appliance is connected to the switch with it's sniffing interface.

If Span is used for monitoring of multiple vlans, then the use of tcp reset is dependant on the configuration of the switch port where the sensor is attached, and the configuration of the span command.

The span command on the Cat 6500 has an option "inpkts enable". Without this option the span will not allow incoming packets from the sensor (i.e. it won't allow the incoming tcp resets).

If the switchport is configured as an access port for a single vlan, and the span is configured to monitor multiple vlans; all of the packets will be seen by the sensor, but there will not be any vlan headers. The sensor won't know from which vlan the packets originated, so it will assume they are all from the same vlan. So the sensor will not be able to reset connections from different vlans.

However, if the port was configured as an 802.1q trunk port, and the span configured to monitor multiple vlans; then the packets going to the sensor WILL have vlan headers. If a tcp reset is necessary, then the sensor will generate the tcp resets with corresponding vlan headers. So in this case the sensor IS capable of reseting connections on multiple vlans when the port is configured as an 802.1q trunk port (and the "inpkts enable" option is used).

NOTE: In the past there were some switches that could not be configured to send the packets with 802.1q headers so the sensor would never know from which vlan the packets originated.

VACL Capture is similar. If the port is configured as an 802.1q trunk port, then the sensor will know the vlan headers and be able to send tcp resets on multiple vlans.

NOTE: There is not a "inpkts enable" option on VACL Capture ports. VACL Capture ports will always allow the incoming packets, unlike span ports.

So for your situation you will need to read up on the 3550 to see if it allows incoming packets on it's span port (or see if a specific option is needed).

And determine if the switch will send the packets with 802.1q headers.

If it does, then your sensor should be able to tcp reset on multiple vlans.

[bgrove2913]

Hi Marcabal,

You said: "If the switchport is configured as an access port for a single vlan, and the span is configured to monitor multiple vlans; all of the packets will be seen by the sensor, but there will not be any vlan headers. The sensor won't know from which vlan the packets originated, so it will assume they are all from the same vlan. So the sensor will not be able to reset connections from different vlans."

Does the sensor understand dot1q tagging? If it does, does it need any special configuration, or it recognizes it automatically?

Thanks

[marcabal]

The sensor understands dot1q trunk headers.

No special configuration is needed on the sensor, it recognizes the headers automatically.

And when TCP Resets are needed, it will check to see if the triggering packet had a dot1q header. If the trigger packet did not have dot1q header then none will be added to the TCP Resets. If the trigger packet did contain a dot1q header, then the same header will be applied to the TCP Resets.

This happens automatically and there are no configuration commands needed to enable it.

So the only configuration to send dot1q packets to the sensor would have to be done on the switch where the sensor is connected.

Some switches can use a single span session to monitor multiple vlans, but sends the packets without dot1q headers. In these situations the sensor won't know the vlan, because the switch is not sending the dot1q headers.

Some switches can use a single span session to monitor multiple vlans, and do send the dot1q headers on the packets. Sometimes this configuration is in the span commands, and sometimes it is the switchport configuration that tells the switch whether or not to use dot1q headers.

You will need to refer to the specific documentation for your switch to see what your switch is capable of sending to the sensor.