<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic TCP state bypass needs to be in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053053#M148345</link>
    <description>&lt;P&gt;TCP state bypass needs to be specific to the traffic rather than for all the traffic. If you identify the set of interested traffic through access-list, you can apply MPF using that access-list so that all other traffic is still inspected and doesn't fall under tcp-state-bypass.&lt;/P&gt;
&lt;P&gt;To identify the root cause, captures and syslogs would be an ideal way. If you have them from the time of issue, please feel free to attach to this post.&lt;/P&gt;
&lt;P&gt;-&lt;/P&gt;
&lt;P&gt;AJ&lt;/P&gt;</description>
    <pubDate>Wed, 25 Jan 2017 13:18:39 GMT</pubDate>
    <dc:creator>Ajay Saini</dc:creator>
    <dc:date>2017-01-25T13:18:39Z</dc:date>
    <item>
      <title>ASA 5510 randomly reset TCP connections</title>
      <link>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053052#M148343</link>
      <description>&lt;P&gt;Hello everyone.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;I have a problem with my Cisco ASA 5510 with Security Plus license.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Few days ago suddenly users in my network issued a problem with big file downloading - download was failed in random cases.&lt;/P&gt;
&lt;P&gt;After investigating this problem I figured out that ASA randomly sends TCP RST message to client and server and connection lost.&lt;/P&gt;
&lt;P&gt;There is no IPS or protocol inspection configured on device. Only NAT (PAT), ACL and Site-to-Site VPN.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;I've tried to mark a "TCP state bypass" in default global service policy - problem passed away, but I observed that number of connections and xlate translation grew up immediatly and stuck at 130k point (usual it about 30-40k). After it ASA stops accept new connection (there is a connection limit for my ASA). I turned off bypassing TCP state and all return to the previous state.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;There is no errors in ASA log when it resets TCP connection - only usual teardown messages like "teardown dynamic TCP connection..."&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Can anybody help me in this case?&lt;/P&gt;</description>
      <pubDate>Tue, 12 Mar 2019 08:49:57 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053052#M148343</guid>
      <dc:creator>Eugene.alekseev</dc:creator>
      <dc:date>2019-03-12T08:49:57Z</dc:date>
    </item>
    <item>
      <title>TCP state bypass needs to be</title>
      <link>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053053#M148345</link>
      <description>&lt;P&gt;TCP state bypass needs to be specific to the traffic rather than for all the traffic. If you identify the set of interested traffic through access-list, you can apply MPF using that access-list so that all other traffic is still inspected and doesn't fall under tcp-state-bypass.&lt;/P&gt;
&lt;P&gt;To identify the root cause, captures and syslogs would be an ideal way. If you have them from the time of issue, please feel free to attach to this post.&lt;/P&gt;
&lt;P&gt;-&lt;/P&gt;
&lt;P&gt;AJ&lt;/P&gt;</description>
      <pubDate>Wed, 25 Jan 2017 13:18:39 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053053#M148345</guid>
      <dc:creator>Ajay Saini</dc:creator>
      <dc:date>2017-01-25T13:18:39Z</dc:date>
    </item>
    <item>
      <title>ASA syslog looks like</title>
      <link>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053054#M148348</link>
      <description>&lt;P&gt;ASA syslog looks like&lt;/P&gt;
&lt;PRE class="prettyprint"&gt;6|Jan 25 2017|16:25:11|305012|192.168.1.10|14299|1.1.1.1|14299|Teardown dynamic TCP translation from Local-net-if:192.168.1.10/14299 to Router-GW-if:1.1.1.1/14299 duration 0:00:30&lt;BR /&gt;6|Jan 25 2017|16:25:03|305012|192.168.1.10|14265|1.1.1.1|14265|Teardown dynamic TCP translation from Local-net-if:192.168.1.10/14265 to Router-GW-if:1.1.1.1/14265 duration 0:00:46&lt;BR /&gt;6|Jan 25 2017|16:25:01|305012|192.168.1.10|14273|1.1.1.1|14273|Teardown dynamic TCP translation from Local-net-if:192.168.1.10/14273 to Router-GW-if:1.1.1.1/14273 duration 0:00:36&lt;BR /&gt;6|Jan 25 2017|16:24:55|305011|192.168.1.10|14338|1.1.1.1|14338|Built dynamic TCP translation from Local-net-if:192.168.1.10/14338 to Router-GW-if:1.1.1.1/14338&lt;BR /&gt;6|Jan 25 2017|16:24:55|305011|192.168.1.10|14337|1.1.1.1|14337|Built dynamic TCP translation from Local-net-if:192.168.1.10/14337 to Router-GW-if:1.1.1.1/14337&lt;BR /&gt;6|Jan 25 2017|16:24:54|305012|192.168.1.10|14272|1.1.1.1|14272|Teardown dynamic TCP translation from Local-net-if:192.168.1.10/14272 to Router-GW-if:1.1.1.1/14272 duration 0:00:30&lt;BR /&gt;6|Jan 25 2017|16:24:47|305012|192.168.1.10|14264|1.1.1.1|14264|Teardown dynamic TCP translation from Local-net-if:192.168.1.10/14264 to Router-GW-if:1.1.1.1/14264 duration 0:00:30&lt;BR /&gt;6|Jan 25 2017|16:24:41|305011|192.168.1.10|14300|1.1.1.1|14300|Built dynamic TCP translation from Local-net-if:192.168.1.10/14300 to Router-GW-if:1.1.1.1/14300&lt;BR /&gt;6|Jan 25 2017|16:24:41|305011|192.168.1.10|14299|1.1.1.1|14299|Built dynamic TCP translation from Local-net-if:192.168.1.10/14299 to Router-GW-if:1.1.1.1/14299&lt;BR /&gt;6|Jan 25 2017|16:24:39|305012|192.168.1.10|14205|1.1.1.1|14205|Teardown dynamic TCP translation from Local-net-if:192.168.1.10/14205 to Router-GW-if:1.1.1.1/14205 duration 0:00:53&lt;/PRE&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;where 192.168.1.10 - client IP&lt;/P&gt;
&lt;P&gt;1.1.1.1 - external ASA IP&lt;/P&gt;
&lt;P&gt;192.168.1.1 - internal ASA IP&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;I forgot to say - there is a lot of "TCP segment of a reassembled PDU" and "TCP Dup ACK 14901#XYZ" messages.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;In attach a capture from Wireshark at local host.&lt;/P&gt;</description>
      <pubDate>Wed, 25 Jan 2017 13:44:18 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053054#M148348</guid>
      <dc:creator>Eugene.alekseev</dc:creator>
      <dc:date>2017-01-25T13:44:18Z</dc:date>
    </item>
    <item>
      <title>These captures are in txt</title>
      <link>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053055#M148363</link>
      <description>&lt;P&gt;These captures are in txt format. Not really useful. Captures taken on ASA ingress and egress will be certainly useful. Another thing that we can check is if there are out-of-order packets coming to the ASA from either lan side or ISP side and if we have L7 inspection turned ON like http inspection, IPS etc.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;"TCP segment of a reassembled PDU" and "TCP Dup ACK 14901#XYZ" type messages are generic and a complete wireshark format capture from egress and ingress can throw more light.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;-&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;AJ&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 25 Jan 2017 16:39:05 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/asa-5510-randomly-reset-tcp-connections/m-p/3053055#M148363</guid>
      <dc:creator>Ajay Saini</dc:creator>
      <dc:date>2017-01-25T16:39:05Z</dc:date>
    </item>
  </channel>
</rss>

