Access lists on secondary addresses

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

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

access-list 100 permit 10.3.3.0 0.0.0.255 10.4.4.0 0.0.0.255
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 10.4.4.0 be denied access to
10.3.3.0 ?
LVL 11
billwhartonAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
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 10.4.4.0 0.0.0.255 10.3.3.0 0.0.0.255 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 10.4.4.0 0.0.0.255 10.3.3.0 0.0.0.255
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.


0
 
PsiCopCommented:
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.
0
 
billwhartonAuthor Commented:
Can you look at my configuration example again and answer the concluding question:

Q: Would this achieve the desired result? Would 10.4.4.0 be denied access to
10.3.3.0 ?
0
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.

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

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

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 10.4.4.0 hosts are subnetting properly or otherwise forced to use 10.4.4.1 to talk outside of their network/VLAN, then yes, my understanding of how ACLs work tells me your ACL should prevent hosts on 10.4.4.0 from being able to talk to those on 10.3.3.0 (or pretty much anywhere else). Note that this is fairly absolutel - even if a host on 10.3.3.0 sent a packet to a host on 10.4.4.0, the target host could not reply to the sender.
0
 
PsiCopCommented:
I think PennGwyn and I are saying the same thing, just differently.
0
 
lrmooreCommented:
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 10.4.4.0 be denied access to
10.3.3.0 ?

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.

0
 
lrmooreCommented:
>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....
0
 
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.
0
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.