ScreenOS Firewalls (NOT SRX)
Reply
Visitor
bklynfan
Posts: 7
Registered: ‎11-25-2008
0

Who sends the TCP RST in NSM ?

Looking at the log below:

+++++++++

2008-11-18T10:34:04+0900 161.144.5.13 <xxxxx>: NetScreen device_id=xxxx  [Root]system-notification-00257(traffic): start_time="2008-11-18 00:36:55" duration=3430 policy_id=30 service=tcp/port:28352 proto=6 src zone=Untrust dst zone=Untrust action=Permit sent=763055 rcvd=26644600 src=203.x.x.19 dst=205.x.x.14 src_port=27456 dst_port=28352 src-xlated ip=161.x.x.7 port=29832 dst-xlated ip=172.x.x.14 port=18352 session_id=63937 reason=Close - TCP RST

++++++++++

I am looking for a little confirmation:

  • The log entry is created at the time the error is flagged.
  • Policy_id shown is true:  S:203.x.x.19 D: 205.x.x.14 dst_port 28352 as defined on ACL
  • The FW logs the RST because the destination 172.x.x.14 has stopped responding.
  • IF the source S203.x.x.19 stops talking to D: 205.x.x.14 the reason=Close - TCP RST would show up the same way and there would not be a way to determine who sent the TCP RST
  • The NSM GUI would also show the same TCP RST but cannot identify the source of the TCP RST

 

So my underlying question is: What is the best way to determine who sends the TCP RST when looking at FW logs, either on the GUI or the CLI.

 

I have searched for a definitive answer like Cisco provides:

 

+++++++++

2008-11-26T15:39:07+1100 199.89.66.222 %PIX-6-302014: Teardown TCP connection 1986432 for
outside:192.153.79.12/445 to inside:172.21.154.71/1135 duration 0:00:57 bytes 1291 TCP Reset-I

+++++++++ 

 

Where the answer is: Reset was from the Inside (higher security level or the inside of the outbound connection) and we can point to the culprit.

Trusted Contributor
Trusted Contributor
CR
Posts: 89
Registered: ‎11-07-2007
0

Re: Who sends the TCP RST in NSM ?

Hi,

 

The traffic log closing reasons are described here: http://www.juniper.net/techpubs/software/screenos/screenos6.1.0/ce_v3.pdf on page 64, table 1 (Reason Codes for Session Close). 

 

This is the relevant one for your session:

 

Logged Reason      Meaning

TCP RST                TCP connection torn down due to RST packet.

 

It does not specify from which side of the connection the RST came. You could open an Enhancement Request (ER) to request it as a new feature :-)

 

Thanks,

Casper

 

Visitor
bklynfan
Posts: 7
Registered: ‎11-25-2008
0

Re: Who sends the TCP RST in NSM ?

Ghostrider,

 

When it comes to troubleshooting historical data in an industry when one side is looking to point and make the other responsible for dropped connections,  I cannot believe the Juniper does not provide more insight into this so critical of details.  One is left to decifer the output and see what is relevant and not.

 

No that I am blaming you, but " ... TCP RST - TCP commenction torn down due to RST packet - is not a real answer..." specially when it comes from techpubs.

 

How does one open an Enhancement Request. ?

 

 

 

 

 

Trusted Contributor
Trusted Contributor
CR
Posts: 89
Registered: ‎11-07-2007
0

Re: Who sends the TCP RST in NSM ?

You can open an ER through your local sales representative.

 

Rgrds,

Casper

Contributor
haas
Posts: 110
Registered: ‎06-27-2008
0

Re: Who sends the TCP RST in NSM ?

Any more good answers on this? I am seeing TCP-RST also and users are then dropping their application but have no idea where to start looking.

 

Thanks,

Jason

Jason J. Wald
Juniper Networks Certified
Internet Associate - FWV
Visitor
bklynfan
Posts: 7
Registered: ‎11-25-2008
0

Re: Who sends the TCP RST in NSM ?

Thanks for your insight.

 

I have raised the issue internally to my engineering group and they have initiated an enhancement request - going on 3 months now, but no responses just yet.

 

Perhaps teh new year will bring good news to those who troubleshoot live in my company.

 

:robotindifferent:

 

Trusted Contributor
Trusted Contributor
CR
Posts: 89
Registered: ‎11-07-2007

Re: Who sends the TCP RST in NSM ?

Hi guys, if you see this kind of problem a lot and you need to know the details about the traffic, then you can best take a packet capture of the traffic. This will allow you to see all the details about the traffic, including who sends the TCP Reset.

 

There is also a (limited) possibility to make packet capture using the firewall itself. To do that, follow these instructions:

 

 

- make sure to log all text output from the console/ssh/telnet window to a text file

set console page 0 (to not have the ---more--- lines anymore)

set db size 4096 (to set the debug buffer to the max size of 4 MB) snoop filter ip dst-port x snoop filter ip src-port x snoop detail snoop detail len 1514 snoop (answer 'y') snoop info (to check) clear db ...let the traffic flow untill the problem occurs... press 'Esc' to stop the debug and the snoop. get db stream (to display the debug buffer content, can be long, up to 4 MB, to redirect to tftp, add "> tftp x.x.x.x filename.txt) - open the resulting file in wireshark.

 

 

 The limitations are these:

- You can only capture up to the debug buffer size (4096 bytes), which results usually in a 2.5 MB pcap file after saving it in libpcap format.

- Only the packets that go through CPU can be captured. So if you use a high end device, like ISG / NS5000, traffic that goes through ASIC in stead of CPU will not be captured. For SSG devices you will see all traffic.

 

Hope it helps.

 

Casper

 

 

 

Contributor
haas
Posts: 110
Registered: ‎06-27-2008
0

Re: Who sends the TCP RST in NSM ?

Thank you ghostrider. I will give this a try!

 

 Kudos has been left...

Jason J. Wald
Juniper Networks Certified
Internet Associate - FWV
Super Contributor
oldtimer
Posts: 227
Registered: ‎11-06-2007
0

Re: Who sends the TCP RST in NSM ?

I did find a policy log entry in my firewall where the log reason was also close - tcp rst.  It turns out this was IMAP.  So I decided to do a test.  I put wireshark on the line, and determined that the mail server was sending a rst back to the firewall.

 

Topology:

 

PC --- FW ---- Mail Server

                <------ TCP RST

 

 

Visitor
bklynfan
Posts: 7
Registered: ‎11-25-2008
0

Re: Who sends the TCP RST in NSM ?

Hi ghostrider,

 

In your reply "... if you see this kind of problem a lot..."

 

I agree, a tcpdump and snoop and debug on the fw can provide one with a lot of insight, unfortunately in my case a single reset is cause for distress as financial application owners are not very forgiving and looking to find root cause for it (RST) as soon as possible after it occurs.  Generally, we do not have the luxury of waiting for it to happen again and use the overnight or COB to investigate historically.  Logs here are important.

 

Additionally, on the packet capture option, I would not want to risk fw performance degradation (I understand this does happen) performing dumps or debugs on a production box, and having so many of these puppies in production ... well you understand.

 

Thanks for your continuous feedback.

 

-Frank

 

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.