Cisco ASA Security Levels

Lessons Discussion
43

How to open and block ports in a firewall? and why do we do that ?

44

Hello Zahid

It depends on what you mean. If you mean the actual physical ports on the device, then there are several ways to do this.

  1. You can use the security levels that are described in this lesson allowing traffic from a higher security level port to a lower security level port but not the opposite.
  2. You can use access lists to indicate what traffic you want to allow and deny on particular physical ports.
  3. You can add policies on the ASA that say what traffic is allowed on which ports and what is not.

If you mean the ports of the Transport layer, such as TCP or UDP ports, then this can also be achieved using access lists and/or policies on the device. Take a detailed look at the various lessons in the ASA Firewall course below for more information:

I hope this has been helpful!

Laz

45

Hi!

Have two ā€œinsideā€ intefaces that i want to communicate with each other.
My current config:

interface GigabitEthernet0/0
 description "INSIDE NETWORK GATEWAY (LAN)"
 nameif inside
 security-level 100
 ip address 192.168.20.1 255.255.255.0


interface GigabitEthernet0/4
 nameif inside_30
 security-level 100
 ip address 192.168.30.1 255.255.255.0

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface

So the routing from inside & inside_30 works fine to outside.
And i can PING from inside_30 to inside, but not from inside to inside_30

So 192.168.30.16 can communicate with 192.168.20.11 but not the other way around.

When I look at the routing table it looks like this:

C    192.168.30.0 255.255.255.0 is directly connected, inside_30
C    XXX.XXX.XXX.XXX 255.255.255.248 is directly connected, outside_2
C    192.168.55.0 255.255.255.0 is directly connected, guest-lan
C    192.168.20.0 255.255.255.0 is directly connected, inside
S    192.168.118.8 255.255.255.255 [1/0] via XXX.XXX.XXX.XXX, outside
S    192.168.118.7 255.255.255.255 [1/0] via XXX.XXX.XXX.XXX, outside
S    192.168.118.3 255.255.255.255 [1/0] via XXX.XXX.XXX.XXX, outside
C    XXX.XXX.XXX.XXX 255.255.255.192 is directly connected, outside
S*   0.0.0.0 0.0.0.0 [1/0] via XXX.XXX.XXX.XXX, outside

When I debug icmp traffic from 192.168.20.0 ā†’ 192.168.30.0 I see that it tries to use the outside interface.

ICMP echo request from inside:192.168.20.11 to outside:192.168.30.16 ID=1 seq=23441 len=32

But from 192.168.30.0-> 192.168.20.0 it manages to find the correct interface.

Any ideas or suggestions are appriecated.

As from what I have understood I donā€™t need to add NAT or ACL since they are both Connected networks ā€œCā€ in routing table.
And I have already implemented the
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
commands.

But I gladly accept any ideas you can give me! :slight_smile:

Thanks in advance.

46

Hello Ali

By default, if you have two interfaces with the same security level, they should NOT be able to communicate. The same-security-traffic permit inter-interface command resolves this issue and allows you to achieve such communication, so thatā€™s done correctly. (The intra-interface command allows you to route traffic to the same interface i.e. to itself. In your case this is unnecessary but has no impact on the behavior.)

Now you state that:

This sounds like a firewall rules setting. Remember, a ping has two components: one echo request outbound, and an echo reply inbound. If a ping is successful, it means that routing is successful in BOTH DIRECTIONS. So routing is not the problem.

Now when it comes to a firewall, if pinging from host A to host B works, but the opposite does not, this has to do with firewall rules. In the first case, the response is allowed because it is recognized as part of the original communication. However, the opposite will not work.

For your particular case, you shouldnā€™t need to add any ACLs or NAT. Check to see if any ACLs or NAT is configured, and make sure that theyā€™re not. The fact that the debugged ICMP traffic seems to go to the outside interface is somewhat strangeā€¦ Since the problem is not routing (we checked the routing table) the only other thing I can think of is that there is some NAT configuration there that is directing the traffic out the outside interface. Check the config for NAT statementsā€¦

Another thing you can do to troubleshoot is to use the ASA Packet Tracer feature. Itā€™s a powerful tool that lets you see the order of operation that an ASA performs on each incoming and outgoing packet, and the resulting routing and/or filtering decisions. Let us know how you get along in your troubleshooting and if we can be of any further helpā€¦

I hope this has been helpful!

Laz

47

Hi Laz!

Thanks for the response!
I reconfigured the 192.168.30.0 to another subnet (192.168.97.0).
I did exactly the same configuration (maybe the order of things I did was different)
And it worked as it was suppose to this time.

Maybe there was something lingering with the 30 subnet in the configuration but I checked and tripple checked and couldnā€™t see anything.

Oh well. It works now anyways.

Thanks for you help and for the advice on ASA Packet Tracer.

Ali

48

Hello Kurt

Yeah, sometimes there are these little gremlins that are in the devices that can wreak havoc with your configsā€¦ :rofl: It happens!

Itā€™s good to know that it has been resolved, and thanks so much for letting us know!

Laz