<?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 Re: ASA - Subinterface ACL's, how do they work? in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/asa-subinterface-acl-s-how-do-they-work/m-p/3175147#M1066745</link>
    <description>&lt;P&gt;Hi Eric,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If you think of sub-interfaces the same way you would if they were seperate physical interfaces, it should help visualise the traffic flows.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1 - PC1 will send data 'inbound' to Gi0/0.10.&lt;/P&gt;&lt;P&gt;2 - ASA will send data 'outbound' via Gi0/0.20 (where PC2 is located)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;You could permit or deny ICMP traffic for your example using the direction listed above. When PC2 does an ICMP reply to PC1, the opposite flow comes in to effect.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1 - PC2 sends traffic 'inbound' to Gi0/0.20&lt;/P&gt;&lt;P&gt;2 - ASA sends traffic 'outbound' via Gi0/0.10 (where PC1 is located)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So if you ICMP traffic was being denied from PC1 to PC2, you would have to check both the INBOUND and OUTBOUND ACLs on both interfaces.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Check out the image below. Uses a router and it's SVIs as an example but the concept is the same.&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-center" image-alt="index.png" style="width: 294px;"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/241i25591932FADA106E/image-size/medium?v=v2&amp;amp;px=400" role="button" title="index.png" alt="index.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;Also remember there is an order of operations, so if you have NAT, application inspection etc, you will have to take this in to consideration too.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope this helps&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;-Brett&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Thu, 24 Aug 2017 11:50:53 GMT</pubDate>
    <dc:creator>Brett Verney</dc:creator>
    <dc:date>2017-08-24T11:50:53Z</dc:date>
    <item>
      <title>ASA - Subinterface ACL's, how do they work?</title>
      <link>https://community.cisco.com/t5/network-security/asa-subinterface-acl-s-how-do-they-work/m-p/3175103#M1066744</link>
      <description>&lt;P&gt;I'm having a hard time "tracing" how ACL's on subinterfaces on a Cisco ASA work.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Let's create a simple scenario:&lt;/P&gt;&lt;P&gt;- ASA Gi0/0: trunk to SW01 Gi0/0&lt;/P&gt;&lt;P&gt;- ASA Gi0/0.10: VLAN10 subinterface&lt;/P&gt;&lt;P&gt;- ASA Gi0/0.20: VLAN20 subinterface&lt;/P&gt;&lt;P&gt;- SW01 has both VLAN's and Gi0/0 configured as trunk without any pruning/acl's or whatsoever&lt;/P&gt;&lt;P&gt;- PC1 in VLAN10 connected to SW01&lt;/P&gt;&lt;P&gt;- PC2 in VLAN20 connected to SW01&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Now the question: how should i interpret this ACL-wise when i ping from PC1 to PC2. If you look at the ASA, is it only&amp;nbsp;&lt;STRONG&gt;incommin&lt;/STRONG&gt;&lt;STRONG&gt;g&lt;/STRONG&gt; in VLAN10? Or is it also incomming in VLAN20 since the ping needs to go back also...&lt;/P&gt;</description>
      <pubDate>Fri, 21 Feb 2020 14:14:15 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/asa-subinterface-acl-s-how-do-they-work/m-p/3175103#M1066744</guid>
      <dc:creator>Eric Snijders</dc:creator>
      <dc:date>2020-02-21T14:14:15Z</dc:date>
    </item>
    <item>
      <title>Re: ASA - Subinterface ACL's, how do they work?</title>
      <link>https://community.cisco.com/t5/network-security/asa-subinterface-acl-s-how-do-they-work/m-p/3175147#M1066745</link>
      <description>&lt;P&gt;Hi Eric,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If you think of sub-interfaces the same way you would if they were seperate physical interfaces, it should help visualise the traffic flows.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1 - PC1 will send data 'inbound' to Gi0/0.10.&lt;/P&gt;&lt;P&gt;2 - ASA will send data 'outbound' via Gi0/0.20 (where PC2 is located)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;You could permit or deny ICMP traffic for your example using the direction listed above. When PC2 does an ICMP reply to PC1, the opposite flow comes in to effect.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;1 - PC2 sends traffic 'inbound' to Gi0/0.20&lt;/P&gt;&lt;P&gt;2 - ASA sends traffic 'outbound' via Gi0/0.10 (where PC1 is located)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So if you ICMP traffic was being denied from PC1 to PC2, you would have to check both the INBOUND and OUTBOUND ACLs on both interfaces.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Check out the image below. Uses a router and it's SVIs as an example but the concept is the same.&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-center" image-alt="index.png" style="width: 294px;"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/241i25591932FADA106E/image-size/medium?v=v2&amp;amp;px=400" role="button" title="index.png" alt="index.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;Also remember there is an order of operations, so if you have NAT, application inspection etc, you will have to take this in to consideration too.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope this helps&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;-Brett&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 24 Aug 2017 11:50:53 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/asa-subinterface-acl-s-how-do-they-work/m-p/3175147#M1066745</guid>
      <dc:creator>Brett Verney</dc:creator>
      <dc:date>2017-08-24T11:50:53Z</dc:date>
    </item>
  </channel>
</rss>

