Two ACL from outside to Inside (NATed , Private)

[Ali Koussan]

Hi,

I have  ASA5550 ruuning Version 8.3(1) with inside and outside interfaces as below

interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 10.20.250.1 255.255.255.0

interface GigabitEthernet1/2
nameif outside

security-level 0
ip address X.X.52.53 255.255.255.224

On the inside : I have a server (10.20.10.36) that need to be accessed from an outside host (Y.Y.131.34) , so I have the below NAT/ACL  rules

object network obj-10.20.10.36
host 10.20.10.36

object network obj-10.20.10.36
nat (inside,outside) static X.X.52.50

access-list acloutside extended permit ip host Y.Y.131.34 host X.X.52.50

access-list aclinside extended permit tcp host 10.20.10.36 host Y.Y.131.34

The problem is : this will not work untill I add :

access-list acloutside extended permit ip host Y.Y.131.34 host 10.20.10.36

My question : is it right that I have to add two ACL entry for outside host to the NATed IP of the inside server , then again add another ACL entry from the same outside host to the private IP of my inside server o get this communication done??

Thanks

Ali

[varrao]

Hi Ali,

In 8.3 or above , you only use the private ip (real ip's) of server in ACL's, so you would only require this ACL:

access-list acloutside extended permit ip host Y.Y.131.34 host 10.20.10.36

This is the right ACL to be used, the above two are not correct.

Let me know if you have any questions.

Thanks,

Varun

[Ali Koussan]

Thanks Vrun for  your quick reply.

This is what I though also ,

access-list aclinside extended permit tcp host 10.20.10.36 host Y.Y.131.34

is used to allow access from the inside server to the outside host (because we have other rules also from inside to outside), so It is required.

but 

access-list aclinside extended permit tcp host 10.20.10.36 host Y.Y.131.34

was my doubt , The connection fails if I did not add this rule !!

I may have an issue somewhere else, I'm attaching the configurtion of the ASA for your review please.

Note : I have removed unrelated configuration , because the configuration file is big.

Mean while I will check if I'm running into any software bug

Thanks

[varrao]

Ali,

You don,t need an access-list if you want to allow internet access to all the users on the inside. Because from higher interafce tio lower interafce all the traffic is implicitly allowed, which means you don't need any ACL. But if you do add an ACL on the interface then it adds an implicit deny ACL at the bottom, whihc means now, from higher to lower security as well you would need an ACL otherwise traffic would be dropped, that is the reason why you've had to add the follwoing ACL:

access-list aclinside extended permit tcp host 10.20.10.36 host Y.Y.131.34

This is the default behavior of the firewall. so dont worry its not a bug,

Moreover to verify it, remove the above ACL from the config and then run the packet-tracer:

packet-tracer input inside tcp 10.20.10.36 2345 Y.Y.131.34 443 detailed

This would let you know where the packet is being dropped.

Hope this helps

P.S.-rate posts which are helpful.

Thanks,

Varun

[Ali Koussan]

Hi Varun,

Ya forget about the rule from inside to outside , as I told you I have other rules from inside to outside , and therefore , there will be implicit deny from inside to outside , thats why I have to add the rule

access-list aclinside extended permit tcp host 10.20.10.36 host Y.Y.131.34

The main issue is that I have to add the rule from outside to the NATed IP of the inside , not only the private IP.

when I keep only the rule to the private IP and do a packet trace it fail on NATing.

I was wondering if the keyword " unidirectional" in the below NAT rule is causeing this problem , this keywork was added automatically by the ASA 8.3 when I add the NAT rule...

nat (inside,any) after-auto source static 10.20.0.0 10.20.0.0 unidirectional

What do you think..

Ali

[varrao · Accepted solution]

Hi Ali

Yes, this is a known issue in ASA 8.3, when ever you upgrade the softwrae to version 8.3.1, it automatically adds the unidirectional keyword in the Nat Exempt staterments, so you would ned to delete undirectional keyword from the NAT statement your self. In ther packet tracer also you would see the packlet being dropped on this particular NAT. Thanks for letting me know, here is the defect - CSCti36048. You might also be hitting into this as well -

CSCtf89372.

Delete the undirectional keyword and aslso after-auto keyword.

Hope this helps.

Thanks,

Varun

[Ali Koussan]

Thanks Varun,

I will give it a try this coming thursday , and I will let you know.

Ali

[Ali Koussan]

That's right , I have to remove the unidirectional word in the ACL

Thanks guys

Sent from Cisco Technical Support iPhone App