asa 5505 adding new ace

[marypoppins]

Hi,

I'm new in cisco. I have an asa 5505 and I would like to adding a new rule for a network, however it was added, it seems it would be inactive. I have two inside network,

192.168.12.0/24 (name: lanA) and 192.168.99.0/24. (name: lanB) I have the following in the running-config:

access-list lanB_acl line 1 extended permit ip 192.168.99.0 255.255.255.0 any

access-group lanB_acl in interface lanB_interface

But when I tried to reach a host in the lanA, the packets are dropped. I configure the asdm, which shows this on the LanB interface:

1 lanB_network | any | ip | permit (hits 344)

2 any | any | ip | deny

and I checked the packet tracer with: tcp, source: 192.168.99.57:10460 dest: 192.168.12.2:443

and it shows that the packet has been dropped by the last 2. 'implicit any any ip deny' rule, in spite of my access-list rule (access-list lanB_acl line 1 extended permit ip 192.168.99.0 255.255.255.0 any) preceded it, and active.

The lanB and lanA interfaces are the same security level 100, and I can reach the outside/internet from 192.168.99.57

Is it possible that I have to reload the rules or something like in order to apply? Or I missconfigured something?

Could you give me some advices?

thank you very much

[Shrikant Sundaresh]

Hi  Chris,

Please try putting the following command in config mode:

same-security-traffic permit inter-interface

If it still doesn't work, then if possible, please put a sanitized version of your config here, and I will try to see if anything is missing.

-Shrikant

PS: Please mark the question as resolved if it is answered. Do rate helpful posts. Thanks.

[marypoppins]

THank you for your answer. I rather changed the security for the interface, because there are two other same security interface, which I don't want to bother. I use my computer in the management network with 192.168.99.50 and I would like to reach the mainoffice (192.168.12.0/24) and the other office lan (192.168.10.0/24) without any restriction. The interface I changed was the vlan12, its security was 100 just as the vlan99, and I lowered to 95.

The real story is the following:

I inherited an asa, which has an outside interface ppoe and vlan2, and an inside interface which sharing among vlan12, vlan10, vlan99, vlan11, and vlan20. The networks:

vlan10 => 192.168.10.0/24 security 90

vlan12 => 192.168.12.0/24 security 95

vlan99 => 192.168.99.0/24 security 100

the others are irrelevant. The running-config is:

interface Vlan2
description --Internet--
nameif outside
security-level 0
ip address pppoe setroute
!
interface Vlan10
description --otheroffice--
nameif otheroffice
security-level 90
ip address 192.168.10.1 255.255.255.0
!
interface Vlan11
description --otherlan--
nameif otherlan
security-level 90
ip address 192.168.11.1 255.255.255.0
!
interface Vlan12
description --mainoffice--
nameif mainoffice
security-level 95
ip address 192.168.12.1 255.255.255.0

!
interface Vlan99
description --Management--
nameif management
security-level 100
ip address 192.168.99.1 255.255.255.0
!

object-group service out_service
service-object tcp eq www
service-object tcp eq https
service-object tcp eq ssh
service-object tcp eq ftp
service-object udp eq domain
access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.99.0 255.255.255.0
access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.10.0 255.255.255.0 ( I added this in order to reach the other office lan)
access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0 ( I added this in order to reach the main office lan)

access-list nonat_otherlan extended permit ip 192.168.11.0 255.255.255.0 192.168.11.0 255.255.255.0
access-list nonat_otherlan extended permit ip 192.168.11.0 255.255.255.0 192.168.12.0 255.255.255.0

access-list acl_outside extended permit tcp any any eq 8080
access-list acl_outside extended permit tcp any any eq 3389
access-list acl_outside extended permit tcp any any eq 4080
access-list acl_outside extended permit tcp any any eq 4443
access-list acl_outside extended permit tcp any any eq 5080
access-list acl_outside extended permit tcp any any eq 5443
access-list acl_outside extended permit tcp any any eq 4800
access-list acl_outside extended permit tcp any any eq 5800
access-list acl_outside extended permit tcp any any eq 8888

access-list acl_otheroffice extended permit tcp host 192.168.10.199 host 192.168.12.11 eq 9100
access-list acl_otheroffice extended permit udp host 192.168.10.199 host 192.168.12.11 eq snmp
access-list acl_otheroffice extended deny ip 192.168.10.0 255.255.255.0 192.168.0.0 255.255.0.0
access-list acl_otheroffice extended permit object-group out_service 192.168.10.0 255.255.255.0 any
access-list nonat_mainofficeextended permit ip 192.168.12.0 255.255.255.0 192.168.10.0 255.255.255.0
access-list nonat_mainofficeextended permit ip 192.168.12.0 255.255.255.0 192.168.11.0 255.255.255.0
access-list nonat_mainofficeextended permit ip 192.168.12.0 255.255.255.0 192.168.99.0 255.255.255.0

nat-control
global (outside) 1 interface
nat (otheroffice) 1 192.168.10.0 255.255.255.0
nat (otherlan) 0 access-list nonat_otherlan
nat (mainoffice) 0 access-list nonat_buno
nat (mainoffice) 1 192.168.12.0 255.255.255.0
nat (management) 0 access-list nonat_management
nat (management) 1 192.168.99.10 255.255.255.255
nat (management) 1 192.168.99.0 255.255.255.0

static (otheroffice,outside) tcp interface 8080 192.168.10.200 8080 netmask 255.255.255.255
static (otheroffice,outside) tcp interface 3389 192.168.10.199 3389 netmask 255.255.255.255
static (office,outside) tcp interface 4080 192.168.12.14 www netmask 255.255.255.255
static (office,outside) tcp interface 4443 192.168.12.14 https netmask 255.255.255.255
static (office,outside) tcp interface 5080 192.168.12.15 www netmask 255.255.255.255
static (office,outside) tcp interface 5443 192.168.12.15 https netmask 255.255.255.255
static (office,outside) tcp interface 4800 192.168.12.14 8000 netmask 255.255.255.255
static (office,outside) tcp interface 5800 192.168.12.15 8000 netmask 255.255.255.255

access-group acl_outside in interface outside
access-group acl_otheroffice in interface ucs

There is not any rule attached to the management iterface with access-group.

I use my computer in the management network with 192.168.99.50 and I would like to reach the mainoffice (192.168.12.0/24) and the other office lan (192.168.10.0/24) without any restriction. So I added the following two lines to the config:

access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.10.0 255.255.255.0

access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0

Now it seems that some services work, but some not. For example I can reach the 192.168.10.199 pc via vnc, but I can't reach the shares for the the same pc. On the other network I can't reach the 192.168.12.12 printer, and I can't reach the computer shares, however I can reach shares of a freenas, which ip is 192.168.12.2.

I don't understand why.

In addition to this, is there any sense of the two lines? Or is it enough the second one?

nat (management) 1 192.168.99.10 255.255.255.255
nat (management) 1 192.168.99.0 255.255.255.0

Thank you very much

[Shrikant Sundaresh]

Hi Chris,

In the NAT order of operations NAT exempt (nat 0) has the highest priority.

Since you have nat (management) 0 access-list ____, the two nat (management) 1 will never be hit. So you could actually remove both. (unless of course you need to go to one of the subnets not mentioned in the no-nat access-list).

You could try to run the packet-tracer command on the ASA for everything that is failing and try to figure out why.

The command is like this:

(to test ping): packet-tracer input icmp 8 0 det

(to test connection): packet-tracer input tcp/udp det

interface-name is the interface on which the packet would first hit.

Please post the packet-tracers (or attach it if there are too many or too big) in case you need help in figuring them out.

-Shrikant

[marypoppins]

Sorry for the delay, and thank you very much for your kind.

The rule I added is fine, however I can't reach the windows shares, because of the client firewall onlly permit only the local lan. So I tried to reach the 192.168.12.x subnet from the 192.168.99.x subnet without nat. I tried to change temporarly the windows' rule, and it worked. I don't want to change the firewall rules on all my clients, which is not the best way I think. Rather I should use nat.

So I have to remove this lines:

access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0 ( I added this in order to reach the main office lan)

access-list nonat_management extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0 ( I added this in order to reach the main office lan)

And make tthese to reach the mainoffice and otheroffice

access-list nat_management_to_mainoffice extended permit ip 192.168.99.0 255.255.255.0 192.168.12.0 255.255.255.0

access-list nat_management_to_otheroffice  extended permit ip 192.168.99.0 255.255.255.0 192.168.10.0 255.255.255.0

global (mainoffice) 5 interface (<-this will use the mainoffice interface address)

global (otheroffice) 10 interface (<-this will use the otheroffice interface address)

nat (management) 5 access-list nat_management_to_mainoffice  (if packages travel from 99.x to 12.x then use global nat id 5)

nat (management) 10 access-list nat_management_to_otheroffice (if packages travel from 99.x to 10.x then use global nat id 10)

I don't know if I have to bind the access list to the management interface with the access-group command, because there are other rules that don't use access-group command.

Am I right?

Thank you

[Shrikant Sundaresh]

Hi Chris,

You are absolutely correct. I think on removing the access-list nonat_management, this nat rule would also be removed:

nat (management) 0 access-list nonat_management

Just verify that this nat rule does not exist. Other than that, the configuration you have done is absolutely correct, and should work fine.

-Shrikant

P.S.: Please mark the question resolved, if it has been answered. Do rate helpful posts. Thanks.

[marypoppins]

Thank you very much!

It works!

I have a question. I don't understand why don't I have to use access-group command to bind this access-list to an interface?

[Shrikant Sundaresh · Accepted solution]

Hey Chris,

The access-list we have created is used to match traffic that requires NAT exemption, rather than control traffic on the interface.

When we use the access-group command for an access-list, the purpose is to regulate flow of traffic on the interface.

Hope this clarifies your doubt.

-Shrikant

P.S.: Please mark the question as answered, if it has been resolved. Do rate helpful posts. Thanks.

[marypoppins]

I didn't understand how the packet can travel through the asa, if I don't use any rule binding to the interface. But I think this is because of the inner rules, which enable the travelling from higher sevurity interface to lower ones.

I am right?

Thank you very much again.

[Shrikant Sundaresh]

Hi Chris,

You are correct. By default, there are 2 access rules on the interface.

1. permit traffic to other interfaces which have lowere security level than this interface

2. deny ip any any

So when travelling from inside to outside, traffic matches the first rule and heads out. Thus you don't need any access list to be applied on the inside interface.

Hope this helps.

-Shrikant