<?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 hairpinning, tcp bypass and service policy questions in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248407#M357439</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Diego,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A policy-map can be composed of several class-maps (the default-one, the one for the tcp_state_bypass,etc.)so you could have more than one, no issue at all,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Now what will happen to the traffic, well it will not go over the inspections defined there but traffic will still flow through the box with no harm,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Just make sure that if somehow you need an inspection for certain traffic (ftp,icmp,SIP) you add a class-map for that traffic,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Sat, 25 May 2013 21:29:32 GMT</pubDate>
    <dc:creator>Julio Carvajal</dc:creator>
    <dc:date>2013-05-25T21:29:32Z</dc:date>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248406#M357438</link>
      <description>&lt;P&gt;I am using an ASA as the default gateway for my network and I need it to to route traffic to other non-ASA gateways located on the inside interface of the box.&amp;nbsp; Seems like hairpinning and tcp bypass is a must have for my setup.&amp;nbsp; It also seems that I need to define the traffic that goes to these other gateways so I&amp;nbsp; can apply the tcp-bypass feature.&amp;nbsp; In my case I will be creating an ACL that matches source subnet of 192.168.0.0/16 to destination subnets 192.168.0.0/16 and then applying it to inside interface of ASA.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My question is, what will happen when inside traffic hits the inside interface and is destined for outside, public IPs?&amp;nbsp; This traffic usually would be taken care of by the global-policy, but this policy has been replaced with the tcp_bypass policy. Furthermore this traffic does not match the acl for the tcp_bypass policy. It seems like this traffic would not have any service-policy applied to it.&amp;nbsp; So I would have inside to outside traffic crossing the ASA with no service-policy applied.&amp;nbsp; Would this work?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;BR /&gt;Diego&lt;/P&gt;</description>
      <pubDate>Tue, 12 Mar 2019 01:49:13 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248406#M357438</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2019-03-12T01:49:13Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248407#M357439</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Diego,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A policy-map can be composed of several class-maps (the default-one, the one for the tcp_state_bypass,etc.)so you could have more than one, no issue at all,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Now what will happen to the traffic, well it will not go over the inspections defined there but traffic will still flow through the box with no harm,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Just make sure that if somehow you need an inspection for certain traffic (ftp,icmp,SIP) you add a class-map for that traffic,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 25 May 2013 21:29:32 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248407#M357439</guid>
      <dc:creator>Julio Carvajal</dc:creator>
      <dc:date>2013-05-25T21:29:32Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248408#M357440</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Another way to approach your problem: Change your network-design. In my opinion, the users should never use an ASA as a default-gateway (the only exception is the home-office where you'll never have a second gateway). If you place a L3-switch with a transit-link between your users and your ASA, then all these problems you have are gone and it's a more clean and easier design.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;--&amp;nbsp; &lt;BR /&gt;Don't stop after you've improved your network! Improve the world by lending money to the working poor: &lt;BR /&gt;&lt;A class="jive-link-external-small" href="http://www.kiva.org/invitedby/karsteni"&gt;http://www.kiva.org/invitedby/karsteni&lt;/A&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 26 May 2013 07:05:36 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248408#M357440</guid>
      <dc:creator>Karsten Iwen</dc:creator>
      <dc:date>2013-05-26T07:05:36Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248409#M357441</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Karsten:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I agree it would be nice to do as you suggest but quality L3 switches are quite costly.&amp;nbsp; Thanks for your input.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Rgds,&lt;/P&gt;&lt;P&gt;Diego&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 26 May 2013 17:46:15 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248409#M357441</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2013-05-26T17:46:15Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248410#M357442</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt; J:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;service-policy doesn't seem to have the permit xx structure found in route-maps that I am familiar with.&amp;nbsp; What would happen to my traffic if I implented the policy as shown below?&amp;nbsp; The idea would be to use tcp bypass for traffic that is being routed internally but apply different policy to traffic destined for outside the firewall.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Rgds,&lt;/P&gt;&lt;P&gt;Diego&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;access-list acl_TCPbypass extended permit ip object net_priv192 object net_priv192 log disable&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;P&gt;class-map tcp_bypass&lt;/P&gt;&lt;P&gt; match access-list acl_TCPbypass&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;P&gt;policy-map my-policy&lt;/P&gt;&lt;P&gt; class tcp_bypass&lt;/P&gt;&lt;P&gt;&amp;nbsp; set connection advanced-options tcp-state-bypass&lt;/P&gt;&lt;P&gt; class class-default&lt;/P&gt;&lt;P&gt;&amp;nbsp; user-statistics accounting&lt;/P&gt;&lt;P&gt;&amp;nbsp; set connection per-client-max 200 per-client-embryonic-max 200&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;P&gt;service-policy my-policy interface inside&lt;/P&gt;&lt;P&gt;!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 26 May 2013 17:49:37 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248410#M357442</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2013-05-26T17:49:37Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248411#M357443</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Diego,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Why don't you use the default global policy (do you have the default policy the global one)?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P style="background-color: #ffffff; border-collapse: collapse; font-size: 11.818181991577148px; list-style: none; font-family: Arial, verdana, sans-serif;"&gt;class-map tcp_bypass&lt;/P&gt;&lt;P style="background-color: #ffffff; border-collapse: collapse; font-size: 11.818181991577148px; list-style: none; font-family: Arial, verdana, sans-serif;"&gt;match access-list acl_TCPbypass&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;policy-map global_policy&lt;/P&gt;&lt;P style="background-color: #ffffff; border-collapse: collapse; font-size: 11.818181991577148px; list-style: none; font-family: Arial, verdana, sans-serif;"&gt;class tcp_bypass&lt;/P&gt;&lt;P style="background-color: #ffffff; border-collapse: collapse; font-size: 11.818181991577148px; list-style: none; font-family: Arial, verdana, sans-serif;"&gt;&amp;nbsp; set connection advanced-options tcp-state-bypass&lt;/P&gt;&lt;P&gt;class class-default&lt;/P&gt;&lt;P&gt;inspect xxx.&lt;/P&gt;&lt;P&gt;inspect x&amp;nbsp; &lt;/P&gt;&lt;P&gt;inspect x&lt;/P&gt;&lt;P&gt;inspect x&lt;/P&gt;&lt;P&gt;inspect x&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With that in place you will be doing the TCP state-bypass for the traffic match with that ACL and then leave the rest of the traffic for the other inspection engines,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 26 May 2013 19:39:00 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248411#M357443</guid>
      <dc:creator>Julio Carvajal</dc:creator>
      <dc:date>2013-05-26T19:39:00Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248412#M357444</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt; I was just trying to leave the global policy alone just in case I had to switch back to it for whatever reason.&amp;nbsp; But you are right, I can just tack on my stuff to the global.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 26 May 2013 21:28:20 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248412#M357444</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2013-05-26T21:28:20Z</dc:date>
    </item>
    <item>
      <title>hairpinning, tcp bypass and service policy questions</title>
      <link>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248413#M357445</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Glad to help,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 26 May 2013 21:36:49 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/hairpinning-tcp-bypass-and-service-policy-questions/m-p/2248413#M357445</guid>
      <dc:creator>Julio Carvajal</dc:creator>
      <dc:date>2013-05-26T21:36:49Z</dc:date>
    </item>
  </channel>
</rss>

