Access lists on secondary addresses

How do access lists apply to secondary addressed interfaces? For eg:

int f0/0
ip add
ip add secondary
ip access-group 100 out

access-list 100 permit
access-list 100 deny ip any any (I know it's explicit but put it in anyways)

Q: Would this achieve the desired result? Would be denied access to ?
LVL 11
Who is Participating?

Improve company productivity with a Business Account.Sign Up

PennGwynConnect With a Mentor Commented:
The access-group applies to the whole interface, not just one address.  However, you're correct that extended access lists can specify the source address, so it's possible to achieve the results you want.

That said, your access list above doesn't appear to do what you want, and is arguably applied in the wrong direction.

It's permitting packets from 10.3.3.x to 10.4.4.x, but not return traffic from those packets.

My recommendation:

access-list 100 permit tcp established
access-list 100 permit icmp echo-reply
<here permit any UDP services that need to deliver replies from 10.4.4.x to 10.3.3.x>
access-list 100 deny ip
access-list 100 permit ip any any

int f0/0
 ip access-group 100 in

The "established" allows TCP connections initiated from 10.3.3.x to 10.4.4.x.  (Attempts to initiate sessions in the other direction will be blocked at the second-last line.)

Applying the access-group to the inbound direction means that packets get filtered before they get routed, which saves some router CPU effort.  The sooner you filter out blocked traffic, the less resources get wasted  handling it.

NOTE:  Secondary addresses are on the same physical network as the primary address.  So anybody whose machine has a 10.4.4.x address can get full access to 10.3.3.x machines simply by changing their IP address to a static 10.3.3.x address.  So the security that this access-list buys you will be extremely brittle.

ACLs are applied to INTERFACES, not addresses. An interface can have, as you've noted, multiple IP addresses, but that doesn't change how ACLs are applied.
billwhartonAuthor Commented:
Can you look at my configuration example again and answer the concluding question:

Q: Would this achieve the desired result? Would be denied access to ?
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

"Q: Would this achieve the desired result? Would be denied access to ?"

A: Depends on how the host on is configured. Because and evidently exist on the same physical subnet, it could be possible (barring the use of VLANs) to  change the subnetting of a host so that it would not go to the router interface when trying to reach the net. If that were done, any ACL would be immaterial - the host could so whatever it wanted with respect to

The point here is that if you are trying to enhance the security of your environment, this is NOT the way to do it, at least not without VLAN support and enforcement of IP configuration on the hosts.

However, assuming that the hosts are subnetting properly or otherwise forced to use to talk outside of their network/VLAN, then yes, my understanding of how ACLs work tells me your ACL should prevent hosts on from being able to talk to those on (or pretty much anywhere else). Note that this is fairly absolutel - even if a host on sent a packet to a host on, the target host could not reply to the sender.
I think PennGwyn and I are saying the same thing, just differently.
I think Bill is looking for theoretical application, rather than a critique of the chosen subnets or the overall validity of the config or is there is a better way...

>Q: Would this achieve the desired result? Would be denied access to ?

Short answer: I don't think so. As PennGwyn mentioned, it is applied in the wrong direction. It should be applied "IN" as a packet enters the physical interface, since it won't really exit back "through" the interface.

Easy enough to test. Apply it "out" as you have it and try it. Use "show access-list" to see the increasing hit counts one way or the other. If you ping a host, both the permit acl line and the deny acl line should increase the same number of packets. If you can succesfully ping, and there are no hits on either acl line, then reverse the direction to "in" and try again. This time, I'd bet lunch that you won't get a successful ping, and that both lines will increment counters.

>I'd bet lunch
On the condition that the hosts pinging and pinged are set up correctly with the appropriate class C mask, and gateway setting correct....
billwhartonAuthor Commented:
Everybody, excellent answers. However,  PennGwyn's fell in the sweet spot.

Everytime I post something in here, I get more than I asked for.
lrmoore, I'd love to try that out once I get my lab.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.