09-28-2010 08:45 AM - edited 03-11-2019 11:46 AM
I have a ridiculous problem, this 8.3 version is throwing suprises one by one...
I have 2 interfaces Corp (142.63.52.221 / 27) and Collab (10.137.136.240 / 24) with the same securrity level 100. No NAT.
I want to access from Corp to RDPSvr (10.137.136.10) server on Collab.
Access rules don't work. Then I added just wide open rule allow IP in Corp - the same problem.
When I allow traffic passing between interfaces with the same security level - success (which means there are no other reasons of packets dropped that firewall rules), but I don't want it, I need to open only particular port to that server!
Even if I put
access-list global_access line 1 extended permit ip any any
access-group global_access global
it's not working!!!
Ping failed with Error 10614:Deny inbound icmp src Corp:142.63.52.200 dst Collab:10.137.136.10 (type 8, code 0)
Here's a fraction of running config:
interface Ethernet0/1
description Corporate network connection
nameif Corp
security-level 100
ip address 142.63.52.221 255.255.255.224 standby 142.63.52.222
!
interface Redundant1
member-interface Ethernet0/0
member-interface Ethernet0/2
no nameif
no security-level
no ip address
!
interface Redundant1.300
description Collab network connection
vlan 300
nameif Collab
security-level 100
ip address 10.137.136.240 255.255.255.0 standby 10.137.136.241
!
class-map inspection_default
match default-inspection-traffic
!
access-list Corp_access extended permit ip any any
access-group Corp_access in interface Corp
!
class-map inspection_default
match default-inspection-traffic
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect ip-options
inspect http
inspect icmp
inspect icmp error
inspect pptp
class class-default
set connection decrement-ttl
!
service-policy global_policy global
Solved! Go to Solution.
09-28-2010 09:19 AM
Hi,
This has always been the behavior of ASAs. I am not sure what you are looking for. Assuming you want to allow Corp hosts to access the host 10.137.136.10 on TCP/3389 that is the RDP port and not anything else between those 2 interfaces but still want to allow Corp hosts to be able to access the internet, here is waht you will need:
same-security-traffic permit inter-interface
access-list Corp_access permit tcp any host 10.137.136.10 eq 3389
access-list Corp_access deny ip any 10.137.136.0 255.255.255.0
access-list Corp_access permit ip any any
The command same-security-traffic permit inter-interface does not bypass ACL check. The traffic will still pass thorugh all the ACLs configured.
Please correct me if i am getting your requirement wrong.
Regards,
Prapanch
09-28-2010 09:01 AM
Hi,
ASA by default does not allow traffic to floe between interfaces with the same security level as is in your case. So you need to have the command "same-security-traffic permit inter-interface".
In addition to this, you can still control what traffic you would like to allow using ACLs on the Corp interface. The above command does not bypass all firewall rules. Instead, the packets still pass through all processing steps that might be involved.
Let me know if this helps!!
Thanks and Regards,
Prapanch
09-28-2010 09:12 AM
Sorry, it doesn't help.
I know that by default traffic is not allowed, and don't want to change that.
BUT it should be allowed be explicit access-list/access-group commands. I don't want to open everything (this's want happens when you issue
Never seen that ASA's behavior before, is it some "new technique" for v.8.3? Hope not, don't want to fall back to previous version, too much to be reconfigured. It should be something simple which I'm missing ...
09-28-2010 09:19 AM
Hi,
This has always been the behavior of ASAs. I am not sure what you are looking for. Assuming you want to allow Corp hosts to access the host 10.137.136.10 on TCP/3389 that is the RDP port and not anything else between those 2 interfaces but still want to allow Corp hosts to be able to access the internet, here is waht you will need:
same-security-traffic permit inter-interface
access-list Corp_access permit tcp any host 10.137.136.10 eq 3389
access-list Corp_access deny ip any 10.137.136.0 255.255.255.0
access-list Corp_access permit ip any any
The command same-security-traffic permit inter-interface does not bypass ACL check. The traffic will still pass thorugh all the ACLs configured.
Please correct me if i am getting your requirement wrong.
Regards,
Prapanch
09-28-2010 09:47 AM
Thank you, that works through I have no idea what the logic it is - if permit same-security-traffic permit inter-interface wthout ANY other access rules ALL IP traffic is allowed in both directions!!!
So much of security...
And why in this case implicit deny rule is not working?
Why should I apply ANY PERMISIVE rule to block all other traffic?
09-28-2010 12:30 PM
Stan,
What Prapanch said in his last post is correct. This has always been the behavior of the ASA when using 'same-security-traffic inter-interface' without an access-list configured. This is stated in the command reference:
http://www.cisco.com/en/US/docs/security/asa/asa83/command/reference/s1.html#wp1444448
Allowing communication between same security interfaces (enabled by the same-security-traffic inter-interface command) provides the following benefits:
•You can configure more than 101 communicating interfaces. If you use different levels for each interface, you can configure only one interface per level (0 to 100).
•You can allow traffic to flow freely between all same security interfaces without access lists.
This is documented in the command references all the way back to ASA 7.0. Also, if you do explicitly configure an access-list it will still be enforced.
Hope that helps.
-Mike
09-28-2010 12:47 PM
I understood what was said, the only thing I'm wondering is WHY while all the traffic is allowed between interfaces putting one PERMISSIVE rule for a particular service block all other services.
In other words if there are no rules ALL the traffic is allowed and implicit global deny rule is not working and once at least one rule apprears in a list (no matter which one - permit or deny) all the traffic blocked exept that from the rule definition.
Isn't it out of regular logic? Cannot see how this behaviour follows from the command reference.
09-28-2010 12:56 PM
Hi Stan,
What you describe is normal behavior.
In the case where there is no access-group command configured for the interface (i.e. there are no access rules applied to the interface) and traffic passes between interfaces with identical security-levels, all traffic will be implictly permitted when you configure the 'same-security-traffic inter-interface' command. This is what is explained in the command reference I posted previously:
You can allow traffic to flow freely between all same security interfaces without access lists.
In the case where there is an access-group command configured for the interface (i.e. there is at least one access rule applied to the interface), any traffic that does not explicitly match one of the access rules configured will be denied. This is because there is an implicit deny rule at the end of every access list, and this behavior is the same regardless of the security-level. This is why only the service you permit is allowed, and all other traffic is blocked.
In short:
If there is an access-list applied the traffic must match an explicit rule or else it will be denied.
If there is no access-list applied, traffic will be permitted in cases where it passes from a) a high security interface to a low security interface, or b) interfaces with identical security-levels when the 'same-security-traffic inter-interface' command is applied.
This is the behavior that the ASA has always had, as noted in the documentation from my last post.
Hope that helps.
-Mike
09-28-2010 01:08 PM
Ok. thank you for explanation.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: