ACL Syntax

[markgramlich]

We have more than one ACL defined.

access-list 120 deny ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255

access-list 120 deny ip 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 120 permit ip any any

access-list 130 deny tcp 192.168.1.0 0.0.0.255 any eq 25

access-list 130 deny tcp 192.168.1.0 0.0.0.255 any eq 587

access-list 130 permit ip any any

What is the correct syntax to apply both of these ACL's to one interface?

-or-

Do the two ACLs need rewritten as a single ACL?

[Richard Burts]

It is not possible to assign two access lists to the same interface in the same direction. It is possible to assign one access list inbound on the interface and assign the other access list as outbound on the same interface.

There is something strange about access list 120. One line specifies 192.168.1.0 as the source and the next line specifies exactly the same network as the destination. It seems like on a given interface the network can either be the source or can be the destination. How can it be both?

If you want to accomplish that 192.168.1.0 and 192.168.0.0 can not communicate with each other and you also wish to deny 192.168.1.0 tcp ports 25 and 587 then you will need to combine both access lists into one.

HTH

Rick

[markgramlich]

We modified access list 120 to include the deny for the port from access list 130. It seems to be working like a charm.

We have two subnets on our campus. A production network on 192.168.0.x. And a guest network on 192.168.1.x. Our router has a primary address on the 192.168.0.x network and a secondary address on the 192.168.1.x network. We wanted a ACL to prevent traffic between the two networks.

We also wanted to deny any guest traffic from using port 25 and 587. We have one IP address and don't want a guest machine to generate mail using our IP address. As this could get our production mail server blacklisted.

[Richard Burts]

The situation where the interface has primary and secondary address does explain using the same address as both source and destination.

It is also perhaps worth noting that in situations like that it is quite possible for a machine in 192.168.1.0 to talk to a machine in 192.168.0.0 without going through the router. Both machines are in the same broadcast domain and if one machine ARPs for the other address the other machine will hear the ARP and respond. Once both machines know each others MAC address they communicate directly without needing the router. So if your organization really wants to separate the guest subnet from the production subnet you may want to reconsider your implementation. While direct communication is not likely it is quite possible.

HTH

Rick

[markgramlich]

I'm working within the constraints of the environment. We have a campus environment with older hubs and a single fiber connection between the buildings. I'm trying to get a budget amount to at least replace the hubs with VLAN capable switches. I would really like to pull enough fiber to build a seperate network for our production and guest users. I'm trying to do what I can to eliminate the casual hacker attempts.

Thanks for the help. It gives me some outside validation for the need to improve the network environment.

Sincerely,

Mark

[Richard Burts]

Mark

I certainly understand and sympathesize about working within the constraints of the existing situation. I thought it was worth pointing out the exposure that existed -perhaps not so much for you as for your management. Lots of people believe that separate subnets means separation and that means protection. In this case it looks good on the surface but does not provide as much protection as your management may think.

Good luck in getting approval to upgrade your network.

HTH

Rick