RST not sent across via ASA

Unanswered Question
Jun 22nd, 2010
User Badges:

hi halijenn / experts

Hi i have a query related to IDS sending RST from inside interface of the Firewall . Please let me know if my understanding is correct

ASA is having Inside , DMZ and Outside interface , IDS is in Inside interface , user is in DMZ.

1) When a TCP Connection is intiated from DMZ interface to Outside , IDS sniffs that and sends RST

2) Switch port (say fa0/5) which is configured for Spanning and connected to the IDS Sensor sniffing interface should have following features

# Disabling “ learning” on the SPAN port, as Sensor is going to spoof the source IP and MAC address of the destination of the original packet as switch has to allow this through

# Allow input on the SPAN port so the switch will accept the RST packet, since normally they are only one way.


monitor session 1 source vlan 20 rx
monitor session 1 destination int fa0/5 ingress vlan 20

Please let me know if my understanding over here is correct

Now my query is that

a) when user send TCP Packet to the Outside , IDS sniffs and discards that packet due to its configuration .Hence , to whom IDS sends RST ideally ? (whether to source or destn ?).What will be the Source IP and Destination IP of that RST .According to me it will send RST to the destination .If it sends RST to the destination , what it will intimate to the User (DMZ) ?
b) Do we need to have access rules configured in firewall to allow that RST to be sent across to the destination (Considering it sends RST to the destination)
c) Will firewall check its state table and will try to deny that RST packet in any case . The reason is that i am getting the following error when user is sending a packet outside , IDS is not able to send RST and user is able to send and receive the web page correctly (which ideally should not happen)

1.Jun 19 2010 19:07:11 COLASA : %ASA-6-106015: Deny TCP (no connection) from to flags FIN PSH ACK  on interface inside

This log says that IDS (after intercepting the packet received from source) is trying to build new conn frm Inside to DMZ to reply to the user and in this process it makes it source to (that of destn) but somehow getting denied.

2.Jun 19 2010 19:07:11 COLASA1 : %ASA-6-106015: Deny TCP (no connection) from to flags RST ACK  on interface inside

This log says that IDS is trying to send RST to the destination (with source as now) however something in firewall is preventing to do so

Please guide me how to proceed

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jennifer Halim Tue, 06/22/2010 - 04:20
User Badges:
  • Cisco Employee,

First of all, base on the configuration, it seems that your IDS is configured in promiscuous mode, not inline mode, hence normally it should not be capable of sending TCP RST packet. Please let me know if the IDS mode is correct.

Secondly, if your IDS is placed in the inside, how will it sniff traffic from DMZ towards Outside? What is VLAN 20? that is what is being monitored by the IDS, assuming that your IDS is connected to switch port fa0/5.

The following syslog messages that you are seeing:

1.Jun 19 2010 19:07:11 COLASA :  %ASA-6-106015: Deny TCP (no connection) from to flags FIN PSH ACK  on interface inside

2.Jun 19 2010 19:07:11 COLASA1 :  %ASA-6-106015: Deny TCP (no connection) from to flags RST ACK  on interface inside

basically means that the actual TCP connection has been closed/tornn down, therefore no more subsequent TCP packets can pass through. The above is TCP packet with FIN Push ACK, and TCP packet with RST ACK.

If the TCP connection has actually been torn down, that means the connection has actually been closed, therefore no more PSH packet can be sent through the same TCP connection.

ankurs2008 Tue, 06/22/2010 - 05:55
User Badges:

Hi ,

I believe if the IDS is in Promiscous mode it can send the RST packet . VLAN 20 belongs to the machines which are sending the web traffic .The switch has the user ports connected belonging to VLAN 20 which are mirrored to the Fa0/5 (CONNECTED TO IDS).i.e only 1 switch is being used over here for inside and DMZ and segregated by VLANS.

Jennifer Halim Tue, 06/22/2010 - 06:02
User Badges:
  • Cisco Employee,

If the IDS is in promiscuous mode, and is capable of sending TCP RST, then normally it will be delayed, and providing some time for the traffic to pass through prior to the RST. In comparison to IPS in inline mode, where every single packet needs to be passed through and inspected by the IPS first prior to being sent towards the destination, and RST sent would be in real time, hence dropping the actual TCP session in time before some PSH packet can go through. Further to that, if VLAN 20 is users VLAN, I don't quite understand your original post about Question 1 (When a TCP Connection is intiated from DMZ interface to Outside , IDS  sniffs that and sends RST). If the IDS is only sniffing user vlan 20, how would TCP connection initiated from DMZ be relevant?

ankurs2008 Tue, 06/22/2010 - 06:29
User Badges:


1) OK , so even if it is delayed  dont you think the RST should be sent ideally after the TCP connection is built [between user and outside webserver] and before user receives a web page successfully  ?

2) Regarding the statement "When a TCP Connection is intiated from DMZ interface to Outside , IDS  sniffs that and sends RST "

Users are sitting in DMZ but physcially they are connected to the same switch with which the Inside interface is also connected .Hence , according to that users are in VLAN 20 . Now when IDS Sniffs the user packet (as per switch config) , it will intercept the packet and will read the MAC and IP Address of destination . Then it will send the RST packet to the destination (with source as user IP kept in DMZ) via ASA which ASA denies.

ankurs2008 Tue, 06/22/2010 - 19:11
User Badges:

hi halijenn

can you please throw some light on this . thanks !

Jennifer Halim Wed, 06/23/2010 - 05:50
User Badges:
  • Cisco Employee,

1) Reset will only be sent when the IDS triggered an event that has an action of resetting the TCP connection. Do you see an event on your IDS that trigger a TCP reset?

2) I would suggest that you first check if the IDS actually triggers a TCP reset. If it does, then you would be able to set a packet capture on the ASA interface and follow the TCP stream. If the IDS sends a TCP RST packet, you will see that on the ASA packet capture as capture is taken from the wire before the packet is being processed by the ASA. From the packet capture, you will be able to see in which sequence the RST packet is actually being sent, ie: whether it is after the TCP 3 way hand shake, or after the web server is displaying its website (PSH packets), hence confirming your doubt.

ankurs2008 Thu, 06/24/2010 - 03:14
User Badges:

hi halijenn

I have taken the captures (attached) .I dont have control of IDS box , hence i wont be able to figure out .But my actual ques over here is why the Firewall will block the IDS RST to pass through it .Even if we consider that IDS is generating an alert for the RST , we will never be sure though that the RST has reached destination or not as RST packet doesnot have any reply .In addition to that IDS will be unaware if the firewall is blocking RST due to some reasons .

1) - Client(Testing interface)

2) - Destn server (Outside interface)

3) Public IP of client  - (in real scenario is natted to external interface IP , however i have taken static NAT for client for this scenario )

4) IDS (behind Inside interface)

Jennifer Halim Thu, 06/24/2010 - 04:13
User Badges:
  • Cisco Employee,

How do you know that the ASA is blocking the RST packet? From the syslog messages provided earlier, the FW is blocking the FIN PSH ACK, and the RST ACK packet which is normal as FW is proxying the TCP connection. FW would have normally forward the actual RST or FIN packet towards the host, and tear down the connection straight away, and when the end host send ACK (RST ACK) packet, as the FW has torn down the connection, that particular ACK packet is dropped. However, as advised earlier, RST ACK or FIN ACK being dropped by FW is normal as FW is proxying the TCP connection.

Those 2 packets which are being blocked are the ACK packets, not the actual RST or FIN packets.

BTW, the packet capture is not attached yet.

ankurs2008 Thu, 06/24/2010 - 05:56
User Badges:

iam not sure why the attachments are not getting attached . size is also less

ankurs2008 Mon, 06/28/2010 - 22:52
User Badges:

hi halijenn

did u had a chance to look at the captures . thanks !

Jennifer Halim Tue, 06/29/2010 - 04:12
User Badges:
  • Cisco Employee,

Yes, looked through the packet capture, and yes, there is RST packet from inside towards outside which torn down the TCP session. However, the RST packet is only sent after the HTTP data packets are flowing across. If you grab the very first packet on inside capture (packet# 3), right click, and choose follow TCP stream, and you will see that the last packet will be the RST packet. Same goes for the outside capture, right click on packet# 3, and follow TCP stream.

ankurs2008 Wed, 06/30/2010 - 03:06
User Badges:

hi halijenn

thanks a lot for looking into capture . Does that mean that the RST is going across the firewall and firewall is denying the same as the URL page of the website has already been accessed by the user sitting in the Testing zone ( and as the RST sent is delayed [as data (webpage) already been received by the user] , firewall will not entertain it as by the time RST is sent the connection is already built and torn down gracefully .Please correct me if am wrong . Also did you saw the retrun reply from the web server outside coming towards the user in the capture ?

Jennifer Halim Wed, 06/30/2010 - 03:40
User Badges:
  • Cisco Employee,

ASA will only tear down the TCP session when it actually receives the RST packet, and that is what it did. If you take a look at the capture, all the PSH packets are seen back and forth between the web server and client, and at the end of TCP session, you would see the RST packet.

ASA will not tear down the TCP connection unless it receives the RST or FIN packet to tear down the TCP connection, and/or if the connection has been idle and the idle timeout expires.

RST is the last packet that i see in the packet capture. Once the web server receives the RST packet, it will also tear down the TCP session at its end.

ankurs2008 Thu, 07/01/2010 - 00:18
User Badges:

hi halijenn,

thanks for the reply . i have few queries, they may be incorrect questions but that is what running into my mind .

1) Is the RST seen in packet capture , the same one which is sent from the Inside interface (i.e from the IDS) with the spoofed IP towards the destination ?

2) I agree that one seeing RST , firewall is tearing down the connection but is there any signifcance of tearing down that connection , now when the user has already received the webpage now ?

3) I dont think that the web server is receving the RST packet .If yes , can we see that RST packet passing through IDS in packet captures or syslogs ? We defintely do see the "Deny TCP no connection " with RST as the reason but i cannt see the RST packet passing through the firewall to reach web server outside

ankurs2008 Fri, 07/02/2010 - 02:18
User Badges:

hi halijenn

request you to please reply to my below queries

Jennifer Halim Fri, 07/02/2010 - 05:39
User Badges:
  • Cisco Employee,

1) I am not sure who sends the RST packet, but the RST is definitely being sent from the Inside towards the Outside.

2) in regards to this question, as far as the ASA is concern, it doesn't know when the RST supposed to be sent. Whether it's after or before the data has been sent, because as far as ASA is concern, it's just a TCP session. The RST is sent by the IPS because it is matching a specific signature, however, ASA does not have the knowledge of that.

3) The web server should be receiving the RST packet because I saw that same packet on the outside packet capture. Packet# 237 on the outside capture is exactly the same as packet# 261 on the inside capture. Packet# 237 is the RST that is being forwarded out the ASA outside interface towards the web server.


This Discussion