cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5377
Views
0
Helpful
8
Replies

ASA 8.3(2) firewall rules not working

stan.pushkin
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

8 Replies 8

praprama
Cisco Employee
Cisco Employee

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

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 command) and then block services one-by-one. In this case it's not a firewal but some mickey mouse device.

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 ...

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

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?

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

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.

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

Ok. thank you for explanation.

Getting Started

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: