<?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 Traffic initiated from ASA inside interface is blocked on return through VPN ACL in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513811#M622597</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I am trying to control the access of 'Remote Access VPN' users to our internal network, by applying filters to the various Group Policies we have configured on our ASA. The idea being that User Group A can access one set of servers, and User Group B can access a different set of servers, allowing us to control where 3rd party users and suppliers can go within our network.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So far, this works for traffic that is initiated from the remote client, and is destined for the internal network. But it fails for traffic that is initiated within the internal network, and is destined to the remote vpn client. For example, if I try to initiate a Remote Desktop session (TCP/3389) from the internal network to the Remote VPN Client, the connection just times out, or if i try to browse the C$ of the remote system, the connection never establishes.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have managed to get the traffic to return from the Remote VPN Client by adding an 'any any ip' rule to the ACL filter assigned to the Group Policy. Obvioulsy I don't want to use an 'any any ip' because it negates the use of filtering the traffic in the first place.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does anyone have any ideas about what is preventing the traffic from getting back into the internal network?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I would have thought that traffic that was outbound from the inside&amp;nbsp; interface, would be able to return by default, and wouldn't need any holes&amp;nbsp; punching on the return ACL.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Paul&lt;/P&gt;</description>
    <pubDate>Mon, 11 Mar 2019 18:54:10 GMT</pubDate>
    <dc:creator>paulstone80</dc:creator>
    <dc:date>2019-03-11T18:54:10Z</dc:date>
    <item>
      <title>Traffic initiated from ASA inside interface is blocked on return through VPN ACL</title>
      <link>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513811#M622597</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I am trying to control the access of 'Remote Access VPN' users to our internal network, by applying filters to the various Group Policies we have configured on our ASA. The idea being that User Group A can access one set of servers, and User Group B can access a different set of servers, allowing us to control where 3rd party users and suppliers can go within our network.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So far, this works for traffic that is initiated from the remote client, and is destined for the internal network. But it fails for traffic that is initiated within the internal network, and is destined to the remote vpn client. For example, if I try to initiate a Remote Desktop session (TCP/3389) from the internal network to the Remote VPN Client, the connection just times out, or if i try to browse the C$ of the remote system, the connection never establishes.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have managed to get the traffic to return from the Remote VPN Client by adding an 'any any ip' rule to the ACL filter assigned to the Group Policy. Obvioulsy I don't want to use an 'any any ip' because it negates the use of filtering the traffic in the first place.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does anyone have any ideas about what is preventing the traffic from getting back into the internal network?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I would have thought that traffic that was outbound from the inside&amp;nbsp; interface, would be able to return by default, and wouldn't need any holes&amp;nbsp; punching on the return ACL.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Paul&lt;/P&gt;</description>
      <pubDate>Mon, 11 Mar 2019 18:54:10 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513811#M622597</guid>
      <dc:creator>paulstone80</dc:creator>
      <dc:date>2019-03-11T18:54:10Z</dc:date>
    </item>
    <item>
      <title>Re: Traffic initiated from ASA inside interface is blocked on re</title>
      <link>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513812#M622622</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;so what is happening here if i undersatnd you right is you have applied vpn filter in the group policy, you want restricted access f&lt;/P&gt;&lt;P&gt;rom remote clients to internal network, but from internal to remote clients when initiate from inter&lt;/P&gt;&lt;P&gt;nal you want it to go through&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;this aint gonna happen currently with the way vpn filters are designed, they will not look at any connection entries&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;so what you can do is probabaly say permit ip any any on filter or actually remove them and put an acl on the internal interface in outbound direction restrict access from that, that way you achieve what you are trying to do about punching holes for return traffic depening on connection entries&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;hope it helps&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 14 Oct 2010 16:38:38 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513812#M622622</guid>
      <dc:creator>Jitendriya Athavale</dc:creator>
      <dc:date>2010-10-14T16:38:38Z</dc:date>
    </item>
    <item>
      <title>Re: Traffic initiated from ASA inside interface is blocked on re</title>
      <link>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513813#M622639</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Jathaval,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your response.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If the reason this doesn't work is by design, then I will try a different approach, probably restricting access from the internal to the remote vpn network as suggested.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Paul&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 16 Oct 2010 11:52:07 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513813#M622639</guid>
      <dc:creator>paulstone80</dc:creator>
      <dc:date>2010-10-16T11:52:07Z</dc:date>
    </item>
    <item>
      <title>Re: Traffic initiated from ASA inside interface is blocked on re</title>
      <link>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513814#M622668</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi Paul,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;i am glad i could be of help...please let us know if this has helped you by rating the answer or marking this question as resolved/answered&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 17 Oct 2010 03:53:34 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/traffic-initiated-from-asa-inside-interface-is-blocked-on-return/m-p/1513814#M622668</guid>
      <dc:creator>Jitendriya Athavale</dc:creator>
      <dc:date>2010-10-17T03:53:34Z</dc:date>
    </item>
  </channel>
</rss>

