cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4032
Views
0
Helpful
18
Replies

RST not sent across via ASA

ankurs2008
Level 1
Level 1

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.

Eg:

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 172.16.10.9 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 63.196.22.110/80 to 172.16.10.9/1047 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 63.196.22.110 (that of destn) but somehow getting denied.


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

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


Please guide me how to proceed

18 Replies 18

Jennifer Halim
Cisco Employee
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 63.196.22.110/80 to  172.16.10.9/1047 flags FIN PSH ACK  on interface inside

2.Jun 19 2010 19:07:11 COLASA1 :  %ASA-6-106015: Deny TCP (no connection) from 172.16.10.9/1047 to  63.196.22.110/80 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.

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.

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?

Hi


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.

hi halijenn

can you please throw some light on this . thanks !

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.

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) 172.16.19.6 - Client(Testing interface)

2) 66.220.146.18 - Destn server (Outside interface)

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

4) IDS (behind Inside interface)

attached pcap files again .

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.

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

hi halijenn

i have tried a lot but am not able to attach anything on NetPro , dont know why .Meanwhile i have uploaded captures to the following link

http://www.4shared.com/get/327968329/4ebd4dde/captures.html

Please have a look at that and let me know regarding this .

hi halijenn

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

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.

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 (172.16.19.6) 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 ?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: