Could someone let me know how to setup access to an inside host (I am not doing any NAT'ing - no RFC 1918 address), which uses all Public Addresses on the inside from the outside interface using ASA IOS v8.3. I tried (for testing only) using a "permit ip any any" access-list on the outside interface access-group (in/out), but that did not work. It seems like IOS 8.3 does NAT'ing and Static Routes differently, so any documentation with examples would be greatly appreciated.
If I'm not mistaken you still need to define a static NAT (for traffic coming from outside to inside).
Since you're not using private IPs, there's no need to actually NAT the traffic, but as a test you can define an identity static NAT like this:
object network obj-126.96.36.199
nat (inside,outside) static 188.8.131.52
Assuming 184.108.40.206 is your real public IP address on the inside.
Create the ACL permitting traffic to this IP and test again.
If you just want to use the public address assigned to these inside hosts and have them go out to the internet looking like themselves, then you do not need to configure any nat on the ASA when running 8.3 code.
the command nat-control does not exist any more.
Please correct me if I'm wrong.
To allow outbound access there's no need for NAT on 8.3 (no nat-control), but to allow inbound access there's still a need to create a static NAT like the example above?
Access from a lower security level interface to a higher security level interface is only permitted when explicitly allowed by an inbound ACL on the lower secrity level interface. This can be either an interface ACL or a global ACL.
No nat needed from low to high or high to low.
Think of it as (no nat-control) in 8.2 or 8.0. There is no need to configure any nat whether high to low or low to high right? Same here.
I have upgraded to V8.3 and your post was of interest. If there is no need for nat from low to high what is the purpose of the Security Level Interface command in V8.3?
My upgrade caused issues where users on the DMZ could access devices on the Inside (low to high) due to the configured access-lists. Pre 8.3 this was not an issue due to having no statics in place from Inside to DMZ.
Pls. read this documentation defect:
This Doc bug has been filed to clarify the action when NAT is not configured on the ASA platform in 8.3 or later code.
I propose to add the following line after at the bottom of the 'How NAT is Implemented' section in the configuration guide.
In the absence of traffic matching a configured nat rule, traffic will not be translated. The traffic will be further processed by the ASA and subject to access-rules, security policies, and routing.
Thanks for the prompt response. certainly different from 8.2 and below but it makes sense. However are the acl processed from top to bottom.
In my Guest acl, my aim is to deny access to the inside networks using object-group RFC_1918 Networks and allow HTTP-HTTPs access to the Internet.
Traffic sourced from Guest to the inside is never deneid by line 2 but processed by line 3?
access-list Guest_access_in extended permit object-group TCPUDP any object-group Internal_DNS_Servers object-group DNS
access-list Guest_access_in extended deny ip any object-group RFC_1918_Networks
access-list Guest_access_in extended permit tcp any any object-group HTTP-HTTPS
access-list Guest_access_in extended permit object-group IPSec any any
access-list Guest_access_in extended permit tcp any any eq ftp inactive
access-list Guest_access_in extended permit ip any any inactive
Got to the bottom of the above post.
When adding a new network object membet type = network, to an existing object group, eg 10.0.0.0 255.0.0.0, when saved this appears in the network object with a mask of 10.0.0.0 255.255.255.255.
Work around was to create a new network oject type = network then edit the object group and add the newly created object.