Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

TCP Resets from behind a firewall.

Sorry if this is somewhere in the documentation but we can't find anything helpful.

We have put out Netranger sensors behind a firewall doing NAT and have set the default gateway on the sensors to be the Firewall. The sensors can ping out and telnet out but for some reason they are not sending Resets. They are running version 2.5(1)S3. The Firewall is "currently" set to allow all internal/trusted connections out. Any documentation on how the Senors perform TCP Resets would be very helpful.

Thanks,

Geoff

5 REPLIES
Cisco Employee

Re: TCP Resets from behind a firewall.

Geoff, is the problem that the sensor in not sending resets (have you sniffed the line?), or is it that the resets are not working (to reset the connection)?

New Member

Re: TCP Resets from behind a firewall.

We have sniffed the line between the firewall and the switch the sensors are connected to and the resets do not seem to be leaving the sensor and going to the firewall. We have not placed a sniffer between the sensor and the switch yet. We will try that nest but my guess is that we will see the same thing. No TCP resets.

thanks,

Geoff

New Member

Re: TCP Resets from behind a firewall.

Ran the sniffer and still not seeing TCP resets. Should I open a TAC Case?

Cisco Employee

Re: TCP Resets from behind a firewall.

First thing is to understand that the appliance will send the TCP Reset packets back out of the same interface that it is sniffing on, and not out of it's command and control interface (the interface with an IP Address).

So if you are going to sniff for TCP Reset packets be sure you are connecting to the network with the monitoring port and not the network where the sensor is communicating with it's director.

Also the TCP Resets may not be going back out the firewall; they may going to the server on your internal network to reset the connection.

As I understand it, you have a firweall connected to your switch and the switch is sending packets to the sniffing interface of the sensor. If you are using "span" on the switch to send the packets then you may need to make some changes on your switch. The sensor will be sending the TCP Reset pakets out of it's sniffing interface into the span port of the switch. For some switches this can cause a problem with it's cam tables (table mapping mac addresses to ports) because the TCP Reset will spoof the mac addresses in order to work. So in some switches they have the spam ports setup so that NO traffic can come in on those ports. So the switch may be dropping the TCP Resets. The Cat 6000 running Cat OS has solved this problem with the following two configuration parameters "inpkts enable" and "learning disable" which allows the TCP Reset packets to come in from the span port with out affecting the cam tables. By default the inpkts it set to disable which will drop the TCP Resets.

Example:

set span 100 3/1 rx inpkts enable learning disable

I am not sure if other Cisco switches have this same functionality.

New Member

Re: TCP Resets from behind a firewall.

Ok... we have tried every type of test we can think of. We sniffed the traffic coming from the monitor port of the sensor and DID see resets when we plugged the monitor port into the hub with a sniffer. However, we did not see them leaving the router when we put the sniffer 1 hop higher in the network. We verified our span config.. I believe it is right but... does this look right?

Here is the span port config on our 6509:

set span XXX Y/Z rx inpkts enable multicast enable learning disable create

Also when we did a sh mac Y/Z and did not see any traffic on the Rc side of the interface

Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast

-------- -------------------- -------------------- --------------------

Y/Z 0 0 0

Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast

-------- -------------------- -------------------- --------------------

Y/Z 25769175111 54737345 591

Port Rcv-Octet Xmit-Octet

-------- -------------------- --------------------

Y/Z 1264037 13457076139325

MAC Dely-Exced MTU-Exced In-Discard Out-Discard

-------- ---------- ---------- ---------- -----------

Y/Z 0 0 0 12829578

I'm stumped!?! Why are we not getting resets onto the network?

thanks,

Geoff

124
Views
0
Helpful
5
Replies
CreatePlease to create content