policy based acl

[jvardhan29]

hi experts

i am confused as to whether i need to specify a real ip or a mapped ip in the acl in policy nat . in this scenario destinationIP is also getting translated .currently iam using a mapped ip and not able to reach the destination . will static matching happens first in this case ?i think i should be using the real ip

asa config

clients ----[IN139] ASA [OUT114] ----remote end

source : 172.16.9.4

Actual destination : 199.12.12.1

mapped ip of destination :10.10.40.4

static (OUT114,IN139) 10.10.40.4 199.12.12.1

where IN139 is the inside subnet with the high security and OUT114 on the lower security

access-list POLICYACL extended permit ip host 172.16.9.4 host 10.10.40.4

nat (IN139) 1 access-list POLICYACL

global (OUT114) 1 interface

[Jennifer Halim]

Yes, you are correct, it should be the mapped ip address (10.10.40.4).

Do you also have any access-list configured on IN139 interface? if you do, then you also need to allow that traffic to go through.

Further to that, double check is proxy arp is enabled on IN139 interface. You should have: no sysopt noproxyarp IN139.

And remember to "clear xlate" after adding/modifying the translation statement.

[jvardhan29]

hi jennifer

thanks for answring this

so as per you mapped ip 10.10.40.4 is required . so static matching or untranslation doesnot happens first in this case ? why i thought this is that after untranslation , when policy based nat for source translation will be looked it should be configured with real ip in the destination of the acl ,then only packet will be allowed .Not sure if i am correct

access-list POLICYACL extended permit ip host 172.16.9.4 host 10.10.40.4

also as you have mentioned to let the proxy arp enabled in this scenario ,is there any reason for the same .what if i have hairpinning also enabled and that too from inside to inside , i think we have to disable proxy arp in that case

i was also thinking whether nonat acl also requires the mapped or actual ip in the destination of the acl ? considering we have destination translation configured along with nonat acl.

[Jennifer Halim]

Hmm, you got me thinking whether source NAT happens first of destination NAT.

You can try to add both addresses into your policy nat acl, and see which has the hitcount. I don't have a lab setup that i can test for you unfortunately.

Try to add both:

access-list POLICYACL extended permit ip host 172.16.9.4 host 10.10.40.4

access-list POLICYACL extended permit ip host 172.16.9.4 host 199.12.12.1

and see which one work will be the quickest way to test it.

Yes, proxy ARP is definitely required because you are NATing 199.12.12.1 to 10.10.40.4 on the inside interface, so the ASA inside interface needs to be ARPing for that IP Address as 10.10.40.4 is a virtual address, ie: does not belong to any physical NIC.

[jvardhan29]

thanks again for answering this

may be i will test in a lab first or else if you get a chance just let me know .

as you mention that proxy arp is required so if you can let me know your view what to do if hairpinning also configured as mentioned previously as in my client firewall , hairpinning is configured 

[Jennifer Halim]

I don't think enabling proxy arp will break hairpinning. Why do you think it will break hair pinning? ASA should only proxy arp for ip address that is configured virtually on its configuration, not for other hosts.

[jvardhan29]

hi

if on the inside of the ASA , 2 different subnets are defined and they both want to communicate to each other via firewall then static (inside,inside) will be used which will break hairpinning in the sense that local users will have intermittent reachability issue to each other .

[Jennifer Halim]

Well, that is a completely different issue, and has nothing to do with proxy arp.

In your case, you mention there is 2 subnets and want to communicate with each other, and believe one of the subnet's default gateway is the ASA, and you probably have another router internally to route that other subnet. Is this correct?

If it's correct, this is a common issue that breaks TCP traffic for hair pinning on ASA because ASA keeps the TCP state for security reason and will drop the connection if it doesn't comply to TCP 3 way handshake.

Example:

TCP SYN: inside host --> ASA inside --> hairpin towards destination host

TCP SYN-ACK: destination host --> directly route towards the inside host (bypassing ASA inside) because ASA inside and the router that routes the inside host subnet as well as the inside host is in the same subnet, hence will not use routing.

TCP ACK: inside host --> ASA inside and at this point, ASA will drop the connection because it never saw the SYN-ACK packet.

This issue can be resolved by pointing the inside host default gateway towards the router instead of ASA, therefore hairpin happens on the router. Router does not check TCP state, so the above issue will not happen when hairpin on router.

Or, you can disable TCP state checking on the ASA, however, this defeats the purpose of having an ASA as firewall is a security device.