Sure this can be done with object groups:
Sure this can be done with object groups:
hi renee ; thanks for the respond for object group .I have another question from this access list example above you mention.in the global access list example be love ;
ASA1(config)# access-list SMTP extended permit tcp host 192.168.3.3 eq 25 any
I couldn’t get this access list statement since you put the "any " after specifying the port number .can you please explain it for me ?
In the extended access-list you can match things like this:
So in that example, we use:
protocol = tcp
source ip = 192.168.3.3
source port = 25
destination ip = any
port = any
I am confused about the section “Permit Traffic to DMZ”
How were you able to telnet the interface on the DMZ router,192.168.3.3, from the outside, R2? I think you should telnet the NATTED IP instead.
I had a default route on R2 pointing to the ASA.
I have that too, R2 points to the ASA, but the lab did not work for me. I think it is a static NAT issue because the ASA drops the packet due to rpf-check. Here is a packet tracer from the ASA
ciscoasa# packet-tracer input OUTSIDE tcp 192.168.2.2 23 192.168.3.3 23 Phase: 1 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 2 Type: ROUTE-LOOKUP Subtype: input Result: ALLOW Config: Additional Information: in 192.168.3.0 255.255.255.0 DMZ Phase: 3 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group OUTSIDE_INBOUND in interface OUTSIDE access-list OUTSIDE_INBOUND extended permit tcp any host 192.168.3.3 eq telnet Additional Information: Phase: 4 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 5 Type: NAT Subtype: rpf-check Result: DROP Config: object network WEB_SERVER nat (DMZ,OUTSIDE) static 192.168.2.200 Additional Information: Result: input-interface: OUTSIDE input-status: up input-line-status: up output-interface: DMZ output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule
That makes sense In my example I didn’t have NAT configured…just the IP addresses and security levels on the ASA, that’s it.
perfect, thank you!!
Hi Rene !
Dont you need nat , when you are using accesslist all security level will diminish ? or am i wrong ?
If this was a real network with Internet connectivity and public/private addresses then yes, you would need NAT. In this example however it’s just an ASA with three interfaces. Nothing has to be translated.
What’s the order on a given INT -Is this ACL evaluated first and then NAT is applied.
ASA1(config)# access-group OUTSIDE_INBOUND in interface OUTSIDE– Referencing to this line what operation is performed first NAT OR ACL and
if it is NAT then this change the source IP to given public IP and overriding the ACL condition which defines what host/subnet to be permitted or denied source IP.
-Thanks in advance
Here’s a good document from Cisco that explains the “order of operation” for the ASA:
The packet tracer tool on the ASA is also great to answer this question. For example:
ASA# packet-tracer input INSIDE tcp 192.168.1.1 50001 18.104.22.168 80
This will show us the packet flow for a host that is using IP address 192.168.1.1 and who wants to connect to TCP port 80 on 22.214.171.124. Here’s the result:
Phase: 1 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: MAC Access list Phase: 2 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 10.10.10.1 using egress ifc OUTSIDE Phase: 3 Type: NAT Subtype: Result: ALLOW Config: object network INSIDE nat (INSIDE,OUTSIDE) dynamic interface Additional Information: Dynamic translate 192.168.1.1/50001 to 10.10.10.254/50001 Phase: 4 Type: NAT Subtype: per-session Result: ALLOW Config: Additional Information: Phase: 5 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 6 Type: SFR Subtype: Result: ALLOW Config: class-map SFR match access-list SFR_REDIRECT policy-map global_policy class SFR sfr fail-open service-policy global_policy global Additional Information: Phase: 7 Type: NAT Subtype: per-session Result: ALLOW Config: Additional Information: Phase: 8 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Phase: 9 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 1017213, packet dispatched to next module
You can see that the access-list is checked BEFORE NAT is applied. If your packet doesn’t match the access-list then it will be dropped before NAT translation occurs.
Hope this helps.
I have a basic question as am just getting to know about ASA firewalls. Doesn’t Standard and named access-lists work on ASA? I haven’t been able to see that configuration.
If you’re familiar with access lists on a Cisco router IOS then most of what you know can be transferred to the ASA. However, there are some differences that you have to keep in mind:
Otherwise, for the most part, they are configured in the same manner as on a router. Use the Cisco context sensitive help (using the ? in the CLI) to help you out concerning the syntax of the commands. Try it out, as actually configuring ACLs, as with all CLI commands, helps the most in learning the proper method of applying commands.
I hope this helps!
Quick question I come from cisco IOS routing and switching background and had a question about the ACL Processing, how does it process the ACLs in terms of do i need to enter a permit ip any any at the end of each ACL Name?
In this lab i noticed after each ACL you created an ip any any why not just create one at the very end.?
ACL processing works pretty much the same as on Cisco IOS. In these examples I added some specific permit and deny statements, which is why I added a permit ip any any at the bottom to accept everything else.
19 posts were merged into an existing topic: Cisco ASA Access-List
one question regarding the “Restrict Outbound Traffic” scenario.
If the ASA would NAT here and we would work with src ip in the ACL statement, we would have to specify the NAT IP address in the SRC part, right?
As the packet is routed and NAT´d first before the ACL is applied, right? If we go from “inside” to “outside”.
a question regarding those statements:
•When you create an ACL statement for inbound traffic (lower to higher security level) then the destination IP address has to be: ◦The translated address for any ASA version before 8.3.
◦The real address for ASA 8.3 and newer.
•The access-list is always checked before NAT translation.
If the ACL is checked first, does the dest IP not have to be the NAT´d IP then?
Cause the ASA looks at the packet and compares it to the ACL. In the packet we still have the NAT´d IP and therefore we would need to specify the NAT´d IP in the ACL, or not?
Cause otherwise the ACL wouldn’t match the packet!?