I have already tried asp-drop

rakesh24csco · ‎03-26-2015

Hey,

I captured the traffic on ASA but I am not clear about the output of the capture. I want to understand what this capture result is conveying. Is this a successful connection or what? Please share your thoughts on this, below are the capture results:

6 packets captured

1: 17:59:19.873871 146.27.92.181.63898 > 144.5.15.33.135: S 4202284294:4202284294(0) win 5840 <mss 1380,sackOK,timestamp 2547149993 0,nop,wscale 5,opt-76:0101921b6e4e0005,opt-76:0c05,nop,eol>

2: 17:59:19.873993 144.5.15.33.135 > 146.27.92.181.63898: S 20020520:20020520(0) ack 4202284295 win 5840 <opt-76:0c01,nop,nop,nop,eol>

3: 17:59:19.874435 144.5.15.33.135 > 146.27.92.181.63898: S 20020520:20020520(0) ack 4202284295 win 5840 <opt-76:1111921b6e4e90050eee1e78,opt-76:0e3d,nop,eol>

4: 18:05:59.747153 146.27.92.181.63910 > 144.5.15.33.135: S 3717049106:3717049106(0) win 5840 <mss 1380,sackOK,timestamp 2547549900 0,nop,wscale 5,opt-76:0101921b6e4e0005,opt-76:0c05,nop,eol>

5: 18:05:59.747275 144.5.15.33.135 > 146.27.92.181.63910: S 20020520:20020520(0) ack 3717049107 win 5840 <opt-76:0c01,nop,nop,nop,eol>

6: 18:05:59.747794 144.5.15.33.135 > 146.27.92.181.63910: S 20020520:20020520(0) ack 3717049107 win 5840 <opt-76:1111921b6e4e90050eee1e78,opt-76:0e3d,nop,eol>

6 packets shown

12 packets captured

   1: 17:59:19.873734 146.27.92.181.63898 > 144.5.15.33.135: S 3197328989:3197328989(0) win 5840 <mss 1460,sackOK,timestamp 2547149993 0,nop,wscale 5,opt-76:0101921b6e4e0005,opt-76:0c05,nop,eol>

   2: 17:59:19.874008 144.5.15.33.135 > 146.27.92.181.63898: S 88662358:88662358(0) ack 3197328990 win 5840 <opt-76:0c01,nop,nop,nop,eol>

   3: 17:59:19.874451 144.5.15.33.135 > 146.27.92.181.63898: S 88662358:88662358(0) ack 3197328990 win 5840 <opt-76:1111921b6e4e90050eee1e78,opt-76:0e3d,nop,eol>

   4: 17:59:20.207173 146.27.92.181.63898 > 144.5.15.33.135: S 841867948:841867948(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>

   5: 17:59:22.861527 146.27.92.181.63898 > 144.5.15.33.135: S 841867948:841867948(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>

   6: 17:59:28.861954 146.27.92.181.63898 > 144.5.15.33.135: S 841867948:841867948(0) win 8192 <mss 1380,nop,nop,sackOK>

   7: 18:05:59.747046 146.27.92.181.63910 > 144.5.15.33.135: S 3618974044:3618974044(0) win 5840 <mss 1460,sackOK,timestamp 2547549900 0,nop,wscale 5,opt-76:0101921b6e4e0005,opt-76:0c05,nop,eol>

   8: 18:05:59.747291 144.5.15.33.135 > 146.27.92.181.63910: S 2125093855:2125093855(0) ack 3618974045 win 5840 <opt-76:0c01,nop,nop,nop,eol>

   9: 18:05:59.747825 144.5.15.33.135 > 146.27.92.181.63910: S 2125093855:2125093855(0) ack 3618974045 win 5840 <opt-76:1111921b6e4e90050eee1e78,opt-76:0e3d,nop,eol>

  10: 18:06:00.153434 146.27.92.181.63910 > 144.5.15.33.135: S 1355577233:1355577233(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>

  11: 18:06:02.745414 146.27.92.181.63910 > 144.5.15.33.135: S 1355577233:1355577233(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>

  12: 18:06:08.747230 146.27.92.181.63910 > 144.5.15.33.135: S 1355577233:1355577233(0) win 8192 <mss 1380,nop,nop,sackOK>

12 packets shown

Vibhor Amrodia · ‎03-26-2015

Hi,

Checking the captures , i don't see the TCP handshake even completing on the ASA device.

Also , I see option 76 enabled which is riverbed device and you are using DCERPC traffic.

This is not a successful transfer.

Refer:-

https://supportforums.cisco.com/document/9876636/cisco-asa-riverbed-tcp-option

Thanks and Regards,

Vibhor Amrodia

rakesh24csco · ‎03-30-2015

Hi Vibhor,

Thanks for the reply.

So you mean to say that ASA is dropping the packet having TCP Opt 76.

I have gone through some Riverbed docs also and there its recommended to allow TCP Opt range 76-78 on ASA. However, I just want to clarify a bit more on this. First, In the capture results the SYN packet is also having the TCP-76 then why ASA is letting it pass through and making the other end to respond with SYN-ACK.

Second, the default behaviour of ASA is to clear the packets having TCP Opt range 9 - 255 and that means to clear the relevant option and allows the packet, then what's causing ASA to drop the packet even it is not configured to drop.

Third, help me to understand your comment "This is not a successful transfer".

Thanks,

Rakesh Kumar

Vibhor Amrodia · ‎03-31-2015

Hi,

By default , the ASA should clear the option in the TCP header as you pointed out. You need to use the "allow" keyword in the TCP MAP specifically to allow these options through the ASA device.

Refer:-

http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/T-Z/cmdref4/t1.html#pgfId-1561309

I am not sure if the ASA is letting this through as i am not sure on which interface were the above capture taken on ?

What i meant by successful transfer was that this connection failed on the Control connection itself i.e. TCP 3-way handshake. Data did not even start to transfer.

Thanks and Regards,

Vibhor Amrodia

rakesh24csco · ‎04-02-2015

Hi Vibhor,

146.27.92.178 ---> Int_core---ASA1--Int_share----> Internet--->ASA2----> 144.5.15.33

Below are the traffic captures on Interface share of ASA1:

6 packets captured

1: 14:29:11.751792 146.27.92.178.51571 > 144.5.15.33.135: S 2448573496:2448573496(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK,opt-76:0101921b6e4e0005,opt-76:0c01,nop,eol>
2: 14:29:11.751868 144.5.15.33.135 > 146.27.92.178.51571: S 20020520:20020520(0) ack 2448573497 win 8192 <opt-76:0c01,nop,nop,nop,eol>
3: 14:29:11.758215 144.5.15.33.135 > 146.27.92.178.51571: S 20020520:20020520(0) ack 2448573497 win 8192 <opt-76:1111921b6e4e90050eee1e78,opt-76:0e3d,nop,eol>
4: 14:29:12.160132 146.27.92.178.51571 > 144.5.15.33.135: S 2448573496:2448573496(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>
5: 14:29:14.746757 146.27.92.178.51571 > 144.5.15.33.135: S 2448573496:2448573496(0) win 8192 <mss 1380,nop,wscale 8,nop,nop,sackOK>
6: 14:29:20.746787 146.27.92.178.51571 > 144.5.15.33.135: S 2448573496:2448573496(0) win 8192 <mss 1380,nop,nop,sackOK>
6 packets shown

As we see that the host 144.5.15.33.135 is responding with SYN-ACK, it means that the ASA1 is letting the SYN pass through with TCP option 76.

On both of the ASAs, TCP options 76 and 78 are allowed, however, still the TCP handshake is not completed. We tried by allowing the TCP option 77 also but it's not working.

Vibhor Amrodia · ‎04-02-2015

Hi,

To be honest , i don't think this might be something that might be caused due to the ASA device. You can also apply the ASP captures and see if you see any packets from the test traffic in there as that would mean the traffic is being dropped on this ASA device:-

capture asp type asp-drop all buffer 3333333

Also , did you try to check the debugging syslog for this traffic and see what you see in there ?

Thanks and Regards,

Vibhor Amrodia

rakesh24csco · ‎04-02-2015

I have already tried asp-drop but I didn't get any relevant output. I can't enable the console logging because it would generate a numerous messages on the console that might result in higher cpu utilization.

I tried by monitoring the real time traffic with a tool, however, didn't see any traffic coming to firewall, don't know why? or might be because I am not familiar with the tool. But using that tool doesn't require much expertise, it's quite simple. It's showing a lot of logs at the end device but nothing on the ASA. Even logging is already enabled on ASA.

Vibhor Amrodia · ‎04-03-2015

Hi,

I was pointing at ASDM logging and checking the logs on the ASDM using a filter.

Enable this command:-

logging asdm debugging

Then open ASDM , go to monitoring >> Logging and then click on show logs..

Apply the filter with the IP address and check the logs.

Thanks and Regards,

Vibhor Amrodia

rakesh24csco · ‎05-01-2015

Hi Vibhor,

Thanks for the reply.

We don't have ASDM login configured on ASAs.

Regards,

Rakesh Kumar

Vibhor Amrodia · ‎05-02-2015

Hi,

I think it would be easier if you can check the logs from ASDM.

Also , if you have a logging server , You cans end the logs there as well.

Thanks and Regards,

Vibhor Amrodia

dustin.burke1 · ‎04-27-2015

Hi,

Did you ever find out if your options 76 were getting through? It seems from the capture it was getting through, but something was prohibiting the 3-way handshake.

rakesh24csco · ‎05-01-2015

Hi Dustin,

As I commented before in my previous replies:

"As we see that the host 144.5.15.33.135 is responding with SYN-ACK, it means that the ASA1 is letting the SYN pass through with TCP option 76.

On both of the ASAs, TCP options 76 and 78 are allowed, however, still the TCP handshake is not completed. We tried by allowing the TCP option 77 also but it's not working."

I didn't find what's causing the traffic drop, however, from the capture output its clear that ASA is letting the traffic pass through and something else in the path is prohibiting the 3-way handshake. We will continue with finding the issue and involve the NA team (who handles the routers/switches) in the troubleshooting.

Thanks,

Rakesh Kumar

dustin.burke1 · ‎04-27-2015

Hi,

Did you ever find out if your options 76 were getting through? It seems from the capture it was getting through, but something was prohibiting the 3-way handshake.

dustin.burke1 · ‎04-27-2015

Hello,

Did you find out if your TCP options were getting through? It seems from the capture they were indeed getting through from the "SACK" but something else was prohibiting the connection from completing the 3-way handshake.

Need help to understand the ASA traffic capture results