06-13-2019 07:02 PM - edited 02-21-2020 09:13 AM
In understand order of operations are different. Let's say I wanted natted_host to reach ANY destination and ANY destination to reach natted_host which is on Inside interface. My ACL will still reference natted_hosts since they are being natted to outside interface? What if they were being natted to let's say another internal host such as 20.20.20.20?
Here are my configs.
object network Natted_Hosts
subnet 200.10.10.0 255.255.255.0
nat (any,outside) static interface
access-list inside extended permit ip object natted_Hosts any
access-group inside in interface inside
access-list outside extended permit ip any object Natted_Hosts
Solved! Go to Solution.
06-15-2019 12:33 AM
let walk though on your configuration
------------------------------------------------
object network Natted_Hosts
subnet 200.10.10.0 255.255.255.0
nat (any,outside) static interface
access-list inside extended permit ip object natted_Hosts any
access-group inside in interface inside
access-list outside extended permit ip any object Natted_Hosts
----------------------------------------------------------
first your object Natted_Hosts better use dynamic instead of static as you have a subnet behind outside with /24.
access-list inside extended permit ip object natted_Hosts any
access-group inside in interface inside
this above rule can be seen as a first line of defense, but depends how to play and what protocols you allow or deny.
Example now here if the initiator is subnet 200.10.10.0 255.255.255.0 and you want to allow only traffic ssh. you will write it as
access-list inside extended permit tcp object natted_Hosts any eq shh
access-list inside extended permit deny ip any any
access-group inside in interface inside.
now the ASA will narrow down the access at inside instead of doing it at outside. this is also classify as good practice to save your ASA cpu.
access-list outside extended permit ip any object Natted_Hosts
packet coming from outside interface is allow access to Natted_Hosts.
in you example (any,outside) with subnet 200.10.10.0 255.255.255.0. will be translated to asa outside ip address.
06-14-2019 01:44 PM
06-14-2019 05:43 PM - edited 06-14-2019 05:57 PM
Inbound traffic meaning for traffic returning from a host that was natted going outbound?
So if host 10.10.10.10 was natted to the Outside interface IP of 20.20.20.20, the ACL on the Outside interface IN should allow 10.10.10.10 correct?
This is the correct Syntax to do that right?
object network obj-10.10.10.10
nat (insde,outside) static interface
What about if I must NAT internal host so they can be reached from Outside/internet via let's say 3389:
nat (insde,outside) dynamic (mapped IP address) service tcp 3889 3889
access-list Outside-IN extended permit tcp any host (real IP) eq 3389
06-15-2019 01:06 AM
Hi,
@CiscoPurpleBelt wrote:
What about if I must NAT internal host so they can be reached from Outside/internet via let's say 3389:
nat (insde,outside) dynamic (mapped IP address) service tcp 3889 3889
access-list Outside-IN extended permit tcp any host (real IP) eq 3389
You will need to use static instead of dynamic.
nat (inside,outside) static (mapped IP address) service tcp 3889 3889
Also RDP isn't that secure, it would probably be more secure using a RAVPN to allow access to the server.
HTH
06-15-2019 09:42 AM
06-15-2019 11:27 AM
have a read on this link https://www.geeksforgeeks.org/computer-network-dynamic-nat-on-asa/
06-19-2019 05:12 AM
06-15-2019 12:33 AM
let walk though on your configuration
------------------------------------------------
object network Natted_Hosts
subnet 200.10.10.0 255.255.255.0
nat (any,outside) static interface
access-list inside extended permit ip object natted_Hosts any
access-group inside in interface inside
access-list outside extended permit ip any object Natted_Hosts
----------------------------------------------------------
first your object Natted_Hosts better use dynamic instead of static as you have a subnet behind outside with /24.
access-list inside extended permit ip object natted_Hosts any
access-group inside in interface inside
this above rule can be seen as a first line of defense, but depends how to play and what protocols you allow or deny.
Example now here if the initiator is subnet 200.10.10.0 255.255.255.0 and you want to allow only traffic ssh. you will write it as
access-list inside extended permit tcp object natted_Hosts any eq shh
access-list inside extended permit deny ip any any
access-group inside in interface inside.
now the ASA will narrow down the access at inside instead of doing it at outside. this is also classify as good practice to save your ASA cpu.
access-list outside extended permit ip any object Natted_Hosts
packet coming from outside interface is allow access to Natted_Hosts.
in you example (any,outside) with subnet 200.10.10.0 255.255.255.0. will be translated to asa outside ip address.
06-15-2019 09:33 AM - edited 06-15-2019 09:43 AM
When you say instead of doing it on the Outside you mean no longer needing "access-list outside extended permit ip any object Natted_Hosts"?
Also, so ASA proces ACL rules in the CPU all the time meaning I would not want humongous ACLs correct?
When would I really know to use "Static" vs "Dynamic"?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide